goran.hultgren at bluefish.se
goran.hultgren at bluefish.se
Mon Feb 3 14:59:53 UTC 2003
Niko Schwarz <niko.schwarz at gmx.net> wrote:
> Am Montag, 3. Februar 2003 14:16 schrieb goran.hultgren at bluefish.se:
> > I agree - both these aspects of Self are intriguing. I haven't worked in
> > self so I can't say anything from personal experience.
> Neither have I, unfortunately, but I found the idea very tempting.
Me too, but more from the perspective of simplification than for "making
cool solutions nobody groks". :-)
> > I bet that Self programs *have*
> > classes, they are just not called that.
> They have traits, and behaviour.
> If I understood it all correctly, the logic is this:
> When I want a car, why would I search for a concept for a car (the class)
> rather than for a car itself?
> So, what selfers do is write a proto-car, a fully blown car ready to rock,
> which you then copy if you want your "instances". objects inherit from one
> another (multiple ways, too. it complains when there would be two functions
> of that name), and it elegantly solves issues like globals: you simply
> inherit them from the Behaviour object, same as you find the other
> prototypes: they are in a tree which you can inherit, if you want it.
Yes, I have read about Self so this is in line with my limited
knowledge. You instantiate by "cloning" and you do inheritance by
delegation. But as you say there are so called "Behaviour objects" etc.
- in my ears this is still mimicking classes in some way.
In short - as a programmer I need to describe "types" and associate
behaviour with those types of objects. We can do this using many
different mechanisms (Traits, Self delegation, class inheritance etc)
but in the end we are still expressing the same thing - we are
describing objects with different sets of behaviours.
So in the end I assume Self has similar problems with modularization as
all the other OO languages, especially the dynamically typed ones. So
dropping classes is no silver bullet. I assume.
> > The idea of building UIs "by hand" and then simply keeping the instances
> > around has been tried several times and AFAIK it has been shown to have
> > its own problems.
> [short description]
> Yes, that sounds convincing.
> Another way would be to create a grammar that describes how the objects are
> organized. That would as well simplify the process of creating a UI-builder.
This has also been tested a lot. The GNOME people use XML (as do many
others), check out Glade for example. In the Smalltalk world VW has been
doing this as long as I can remember (Window specs that are Arrays of
literals) and the StableSqueak effort (that sortof died or froze) had
stuff doing this using XML in Squeak. See my article about that:
IMHO this is a very good way of doing UIs. Personally I like either
coding them by hand (total power, much easier to make components and
debug) or by using some form of declarative description and a builder as
they did it in StableSqueak/Glade etc.
> Please don't take me too serious, I'm just thinking aloud:
That is ok! :-)
> I suppose it is simpler to write a ui-builder that stores its information in a
> description format, rather than producing smalltalk code that builds this ui.
> (like: ud teach every morph to print itself into an xml-tag).
IIRC Michael Rueger has provided this capability earlier and did demo it
at OOPSLA 2001 I think. In essence all Morphs could represent themselves
as XML so you could construct your Morph by hand and then simply take a
snapshot of it in XML which a Builder then could use to reconstruct it.
Pretty nifty, don't know what happened to that code.
So I don't think either way is "simpler" than the other. There are UI
builders for Squeak btw, check the Swiki. Don't know their status
> With this approach, too, you would have an abstract ui description, which
> would be nice to store in the snapshot, and in your module, when you ship it.
> > But anyway - the issue of focusing on "objects" instead of "source code"
> > in the modularization effort has been discussed a lot on this list
> > previously. IMHO I think that "simplifying" the question by saying that
> > - hey, if we instead base the modules model on objects then "the rest
> > will follow" simply is an oversimplification.
> I guess. But pushing whole squeak more in this direction, not just modules,
> might be a useful approach.
Yes, and there are efforts in this direction too. Stephen Pair has been
doing intriguing stuff enabling Self-like delegation in Squeak and more
importantly (IMHO) has some really cool technology for doing remote
object memories. That last part can really change a lot in the Squeak
> Maybe we two should take a better look at self and if this whole stuff really
> simplifies work, there =)
I am not sure there are enough experience in the Self world to draw
from. I mean - what should we look at? Perhaps I have missed something
but to me Self has always seemed a bit "academic". I haven't seen any
major "day to day" work being done in it. But I may be totally wrong of
> > We all know "everything" in the image are objects, much like molecules
> > are in real life. Now, let's pretend that the image is the human body
> > and that the different modules are the organs - the heart, brain, lungs,
> > limbs etc.
> > If I told a surgeon that "Hey, if you just figure out how to keep track
> > of the dependencies between the molecules in the body - then you will
> > as, a sideeffect, have solved the problem of knowing the dependencies
> > between the organs!".
> =) Nice analogy.
> But I understand self much simpler. It doesnt claim that it can tell you the
> dependencies better, it just wants to say that splitting the body into two
> separate parts: organ-color and organ-form, you will not simplify the process
> of understanding. better would be to watch at the organs in both their
> aspects all the time: color and structure.
Well, to me it seems Self instead wants to generalize stuff even more
than Smalltalk does.
Sure, fine by me - generalization is cool. That is after all one of the
powers of Smalltalk - you know: five reserved words, everything is an
object, almost everything is a message send etc. etc.
But I can't see how the aspects of Self (compared to Smalltalk) would
help us in the field of Modules. But hey - I have been known to be
I like the way we approach the problem now. We do it step-by-step. First
we created a simple package registration mechanism (SqueakMap). Then Ned
created the SAR-format and Avi created DVS. The next logical steps are
enhancing SqueakMap with information about releases enabling us to
record dependencies between packages and evolving DVS into Monticello
for team development. When that is in place the final step is to try to
automate dependency detection and install/uninstallation to satisfy the
dependencies. These two things are HARD. But if we keep them for last it
doesn't matter if they take time. :-)
More information about the Squeak-dev