On Dec 27, 2010, at 11:03 AM, Jecel Assumpcao Jr. wrote:
> All of my least favorite Self features have the same cause - strings or
> numbers where objects would work better. Certainly annotations are a
> more "proper" way of doing what was a "pun" in Self 1 and 2 using parent
> priorities, but I would be happier if these annotations were full Self
> objects instead of strings that have to be parsed in wierd way to
> extract the information we need from them.
The string part was an easy implementation way to save space. Sure storing objects would have been nicer.
In fact they were changed back and forth to objects in a way that was transparent.
Annotations were meant to be functional, so you could replace them but not change them in place.
That saves a lot of space. Remember that every slot in every point object conceptually had its own annotation.
> Another place with this problem is the parameters of fail blocks. In
> fact, this made Ole Agesen's application extraction scheme a lot less
> useful since primitive handling code always had to include fancy string
> methods. Replacing this parsing with a small set of exception objects
> would be a huge improvement, in my opinion.
Not sure what you mean here about Ole's extractor.
IMNSO, exceptions were a botch invented in languages without blocks.
I never liked the fact that control could invisibly branch off.
For instance, in a long method with exceptions, containing A; B; C;, you cannot count on
B being executed if A is executed. At least with fail blocks you can see the branch in the return symbol in the block.
I know that others like exceptions. To me they are like iterators, both were workarounds for languages without blocks
that became enshrined in our culture. I prefer blocks. But that's just me.
> The layout stuff in Morphic used to (I haven't looked since 1995) encode
> stuff like left/middle/right as 1, 2 or 3. This required lots of tests
> that would go away if simple alignment objects were used instead.
> About the annotations, in my tinySelf 0 I just had a special constant
> slot with the value for the object annotation, but never did come up
> with a good scheme for the slot annotations.
That would allow object annotations to be accessed without reflection, a change from what I considered to
be the appropriate base-level semantics. It is simpler, though. It violates my preferred model of object encapsulation.
> -- Jecel