bparsia at email.unc.edu
Tue Jun 20 16:17:59 UTC 2000
On Tue, 20 Jun 2000, Karl Ramberg wrote:
> I've been wondering why variables don't default to something meaningful
> in their context,
They do...nil. The context being "uninitialized" :)
> when they are not initialized. Smalltalk is a untyped
> language but it still requires types when the variables are uninitiated.
> If for example the variable recognizes it's context it could default
> to something like:
> a == nil == false == 0 == '' == empty collection or bag or what ever.
Er..because they are all different things?
> Then one could use these examples without telling the number value or
> Boolean .
> a + 2 => 2 "a defaults to 0"
But *why* default to *0*? #+ is a message send, so you don't *know* that
it *should* go to 0. Furthermore, it would make initializtion bugs
a := self valueFromSomeSourceAndIsUsuallyZero.
^a + 2
How could you (easily) tell between valueFromSomeSourceAndIsUsuallyZero
*correclty* returning 0 and *erroneously* returning nil?
(If you respond, "But there's an *assignment* up there", I'll respond, but
what if the "assignment" took place inside
valueFromSomeSourceAndIsUsuallyZero...it wouldn't be visible to this
If you want default *instance variables* that's easy enough with lazy
initialization (you, uh, *do* use access? :))
And if it's a *temporary*, then I don't see why this is an advantage at
> ifTrue: "a defaults to false"
Why is this good? Why not default to true?
> It is probably several reasons to not make the system like this, but
> from a beginners perspective it makes sense.
I think you'd want to distinguish between this for temps and this for
access object variables. You could, perhaps, have method context dependant
initializtion of ivars. But I think trying to infer from immediate
*lexical* context is a bad idea...
...aside from complicating things enormously to do at all, much less
"right" (if there *is* a right), I'm not sure what the advantages are?
Could you spell out what advantages you see with the scheme?
More information about the Squeak-dev