I R Woollard I.R.Woollard@bnr.co.uk writes:

Self Style Suggestion:

If I want to produce an instance of something, I believe it is better to ask the traits object for it.

I propose that most traits objects should respond to a 'new' invocation

• it allows the posibility of parameters to determine the contents.

I agree that currently prototypes have their contents ignored and have only their "format" used. But I think this will change in the future as we get more complex objects. We might then have many different prottypes that we might clone, all with the same traits but with different contents. The contents will come mainly from the prototype itself, not from a "new:" message's arguments.

• it doesn't preclude having globals as well
• a 'new' mixin is easily defined
• a lot of traits already have a prototype slot
• its less code in the clients, you don't have to use explicit "copy"'s
• it is closer to the smalltalk model, hence easier to learn

I am teaching some people Self, others Smalltalk, and don't find the Smalltalk model easier. The worst problem is learning to distinguish instance/class methods ( like new ). People naturally want to send everything to the objects themselves. Of course, this might be particular to this group of people.

p.p.s. Is there any kind of style guide anywhere? (I have read the User Manual)

Try the Reference Manual, pages 54 - 60.

When self has: multiuser capability, a better UI (it's _ok_ now, if only it was more virtual reality-like, and more ways to hide things without losing them from the screen entirely) it will be a real winner.

My suggestion for the "corrupted prototype problem" is to turn Self into a multiuser system. If the prototype belongs to another user, you can read it and clone it, but if you try to modify it you will get an error. You would have to divide the system into many pseudo users for this to work well. The idea is that the system should be "open" but safe from accidents.

I read a few years ago in IEEE Micro or IEEE Software ( sorry, I don't remember the reference ) an article about the authors' experience in learning Smalltalk. They wrote a simple program and started "inspecting" it when they came upon a bitmap. They called the editor on it and changed it only to discover that they had redefined the system's notion of the color Black! The screen became whiter and whiter so that they couldn't read anything and it was impossible to undo their blunder. There are many dangers lurking in a totally open system, and corrupted prototypes are just one of them.

David.Ungar@Eng.Sun.COM (David Ungar) writes:

One way to mitigate the prototype-corruption problem that I am seriously considering would be to make "globals" no longer be a parent and to change its name to something shorter, like "the". The drawback: every time you refer to a prototype, you would have to say "the point copy" instead of "point copy". The benefits: slightly harder to forget copy, and better for showing all of an object's inherited attributes in a single place. (Solves a problem that is facing Kevo).

As there really aren't "globals" in Self, we could have the following alternative:

traits graphics _AddSlotsIfAbsent: ( | point = () | )

traits point _Define: ( | ..... | )

_AddSlotsIfAbsent: ( | proto* = (). the = () | )

the _AddSlotsIfAbsent: ( | point = () | )

the point _Define: ( | parent* = traits point. x <- 0. y <- 0 | )

proto _AddSlots: ( | point = ( the point copy ) | )

Now we can just say "point" and get a copy of the prototype, but must write "the point" when we really want to refer to the original prototype itself.

- Jecel

P.S.: I don't really my last suggestion, but I think it is a good idea to make the "safest" operations the default.