[self-interest] Self (and OOP) noob says Hi!

ungar at mac.com ungar at mac.com
Thu Feb 3 03:06:46 UTC 2011


If I were to tackle multiple inheritance today, I would go with "unordered up to join".
Given a diamond inheritance pattern, with a match, A,  found on one arm, and another match, B,  found above the join point,
I would let the lookup find A. Today in Self it's an ambiguous lookup error.

- David

On Feb 2, 2011, at 8:03 AM, Jim Wise wrote:

> Russell Allen <mail at russell-allen.com> writes:
>> Hi Duke,
>> The three main current sources of documentation are the tutorial as
>> Casey mentioned, the manual at docs.selflanguage.org and the various
>> papers on the website (though these can be out of date!).
>> Also the wiki: https://github.com/russellallen/self/wiki
> Is there a ps or pdf version of the handbook from docs.selflanguage.org
> (I see that the main website notes this is `coming soon')?  Also, I
> assume the Demo snapshot also serves as the best body of example code
> out there -- is there anywhere else I should be looking?  I've found the
> bibliography on selflanguage.org very helpful for `getting' self, but
> could use to look at a lot more code...
> One main question I had: I notice that `Parents are Shared Parts:
> Inheritance and Encapsulation in Self' (1991) gives an extensive
> description of the sender-path-tiebreaker rule, prioritized multiple
> inheritance, and some thoughts on backtracking in receiver finding, but
> by the time of `Programming as an Experience: The Inspiration for Self'
> (1995), these are described as a design mistake.  Were these mechanisms
> removed from the language, and if so, what is the current mechanism for
> resolution of same-named slots in parents inherited through different
> parent slots?
> From the point of view of 16 years further on, how do these design
> choices look, and what would you do about resends, if you were designing
> Self today?  I ask because in other languages supporting MI, the
> linearization (local or global) rules for method lookup often seem to
> require as much description as the entire rest of the inheritance model
> (Scala, C++), have extensive special-case features to control
> re-dispatch (CLOS) or are simply unresolved issues, perhaps even
> allowing programmers to switch between available models at program run
> time (Perl).
> Also, as a word of thanks, I'd like to say that, coming mainly from
> lisp, ml, and Objective-C and having dabbled with Smalltalk several
> times over the years, experimenting with Self has been quite pleasant
> for me.  At first glance, it feels in many ways like
>         Self : Smalltalk :: Scheme : Common Lisp
> -- similar language, but a reboot around a core set of principles,
> consistently carried through the language, and a couple of really neat
> ways to make things which would be a special-case feature of other
> languages fall out of this consistency.  The use of a very simple object
> model instead of elaborate systems of strongly-typed inheritance (ala
> Beta or Scala) or parallel (possibly class-aware) systems of generic
> programming (Scala, C++, Ada) to achieve the same goals probably
> contributes to this impression.
> But this may just be me trying to relate the experience to something I
> already know.
> It was also neat to see a mention of Kevo float by, as I wrote some
> small code with that under MacOS 7 when in college (sometime after the
> Sparcstation 1 boot monitor introduced me to Forth, and before the NeXT
> introduced me to Objective-C :-) ).  If anyone does find the Kevo
> sources, I'd also be interested to get a copy.
> Thanks,
> -- 
> 				Jim Wise
> 				jwise at draga.com

More information about the Self-interest mailing list