[General] A Few Questions

[Adam Spitz]

Chris,

I can't answer the Lively-Kernel-specific questions, but I've got a
couple of thoughts about the more general prototype-based-system ones.
(We could take this discussion over to
http://groups.yahoo.com/group/self-interest/ if it's not appropriate
here.)


> 3. You used classical inheritance with subclass() and extend() to implement
> Morphic, right? That means you're bringing Morphic to SVG is from Squeak and
> not from Self. Is that correct? For some reason I thought I'd see the true
> way to use prototypical inheritance in Lively Kernel, as I had it in my mind
> that Self + JavaScript = Lively Kernel.

Even in Self, we use a class-like pattern a lot of the time (see
http://selflanguage.org/documentation/published/organizing-programs.html).
I'm not very familiar with the Lively Kernel code base, but it doesn't
surprise me that it uses a lot of classes. And if I glance through LK,
it looks to me like there are a few objects that aren't class
instances, which is about what I'd expect.

The way I usually think about it, classes are a fine idea; it's just
the idea that "every object is an instance of a class" that causes
trouble. The value of prototypes isn't that you suddenly organize your
entire code base in this whole new completely-different way; it's that
the core of the system becomes simpler and more flexible and easier to
learn. That flexibility lets you use some fun new organizational
patterns, but the good old "class" pattern is still an important one.


> Learning about Self I see that the versatility of that language comes at a
> price. It's simple code. And I like the wholeness of it enough to explore it
> further, but it seems to use a smaller unit of composition than the class.
> The slot is a sort of mobile method, it seems to me. My point is that I
> think people find this language a bit confusing, Self and JS both,
> because the unit of construction, the granularity of the language, is
> much smaller than people are used to.

I'm not quite sure what you mean. Self's module system uses slot-level
granularity because when you're loading a module into the image it's
useful to be able to add stuff to existing objects. That's certainly
not unique to prototype-based systems - for example, open up a Squeak
image and look for method categories with an asterisk in front of
their names. (That's the mechanism that Squeak uses to indicate that
the methods in that category should belong to a different module than
the one the class belongs to.) Lively Kernel seems to be doing
something similar - occasionally using Object.extend to add slots to
existing objects.


Adam