[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: globals considered harmfull
- To: email@example.com
- Subject: Re: globals considered harmfull
- From: firstname.lastname@example.org (Jecel Mattos de Assumpcao Jr. (kofuji))
- Date: Wed, 23 Mar 94 14:38:02 EST
- Reply-to: <email@example.com>
- Resent-date: Wed, 23 Mar 94 10:36:59 PST
- Resent-from: Urs Hoelzle <urs@otis>
- Resent-message-id: <9403231837.AA10278@otis.Stanford.EDU>
- Resent-to: real-self-interest
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
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
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
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.
P.S.: I don't really my last suggestion, but I think it
is a good idea to make the "safest" operations the default.