Capabilities in Squeak (attn: Lex Spoon and friends)

Lex Spoon wrote:
>>> Perhaps we should go all the way, though, and explore nested
>>> classes.

Michael van der Gulik wrote:
>> Nested classes? What do you mean? Are you talking about nested
>> Namespaces (org.squeak.kernel.numbers.SmallInteger)?

Matej Kosik wrote:
> Have you read papers about E? Have you read Mark Miller's dissertation?
> http://www.erights.org/talks/thesis/index.html
> <http://www.erights.org/talks/thesis/index.html>

Michael van der Gulik wrote:
> His dissertation does not contain the phrase "nested class". I've just
> searched through it.


 From section 6.4:
 > Any imperative language with lexically nested object definitions, including
 > Smalltalk's blocks, T [RA82], Beta [Mad00], Java's inner classes, and
 > Emerald [HRB+87] covered briefly in Related Work Section 24.6, supports the
 > easy definition of multiple facets sharing state.

In any case, the point in not inner/nested classes per se. The point is
lexically nested object definitions.

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

> > That's a very small .mcz :-). I've just had a look at your changes,
> > and while they'd work, they'd come with a speed penalty.
> > Essentially, you're just un-doing the optimisations on #== and
> > #class.
>
> Yes, I did it solely to achieve the functional benefits when working
> with SqueakElib.  Identity is an interesting issue when dealing with
> eventual refs.

Islands also required undoing some of these optimizations.  Especially
#class needed to do something non-trivial, because Squeak's normal
#class lets people redefine the class hierarchy and even the language!

I would not rush to assume there is a real performane hit, especially
for #class.  For #==, maybe, but remember that a sophisticated #== is
a fundamental part of Elib's design.


-Lex