[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: globals considered harmfull.
From: Brook Conner <email@example.com>
Date: Tue, 22 Mar 1994 12:11:31 +0500
Resent-Date: Tue, 22 Mar 94 9:13:06 PST
Resent-From: Urs Hoelzle <firstname.lastname@example.org>
I. R. Woollard 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.
Only if you're following the class-instance model. Suppose you have
objects that don't have a traits object? E.g. all the oddballs?
Yes, if an object has no trait that describes it, (e.g. most traits
objects themselves!) But you generally only want 1 of each of
those. In which case no copying/creating required. But if you want
more than one of a non trivial type of object, I claim it is bad style
*not* to have a traits object for it. (sorry but, oddballs usually do
have traits don't they?)
What's wrong with providing a prototype that understands a
Reuse is harder. Or, if you mean to put the copyWith... in a trait
then it effectively becomes no different to "new" with a different
> - a lot of traits already have a prototype slot
And _all_ the prototypes have traits slots. A prototype can't
function without a traits slot, whereas a traits _can_ function
without a prototype slot. Don't require unnecessary slots in traits
objects -- that's violating the "minimal but sufficient" design rule
(the minimal part).
Disagree. You don't need a globals slot to point to the prototype. You
only need a slot in the traits objects to point to or find the
prototypes. Self currently has both.
> - its less code in the clients, you don't have to use explicit "copy"'s
What's the difference between sending new to the traits object versus
copy to the prototype?
traits fooBar new.
prototypes fooBar copy.
I was wrong, same amount of code. However, it is possible to rearrange
the traits structure to allow: fooBar new. Turn traits into a parent
of lobby, and then each reference to a leaf object of traits back into
a normal reference.
> - accidently forgetting the copy is a real screw up, you end up
> modifying the prototype
Accidentally forgetting a new would be worse. When you modify the
traits object, everything that inherited from that traits object would
be modified. When you forget a copy, only the prototype is modified
-- a much smaller-scale change.
So using copy is actually _safer_ than using new.
Possibly, but, because the prototype has different slots to the traits
object, a walk-back is very likely. Prototypes always have the same
slots as the copy so with probability 1 you screw up.
Self *is* awesome, particularly the VM and compiler technology...