[question]types

Michael Lucas-Smith ich at driftwood.darktech.org
Thu Jun 22 04:40:16 UTC 2000


Karl Ramberg wrote:

> Bijan Parsia wrote:
> >
> > On Tue, 20 Jun 2000, Karl Ramberg wrote:
> >
> > > Hi,
> > >       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
> > invisible:
> >
> >         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
> > method.)
> >
> > If you want default *instance variables* that's easy enough with lazy
> > initialization (you, uh, *do* use access? :))
>
> I wanted to be more lazy :-)
> >
> > And if it's a *temporary*, then I don't see why this is an advantage at
> > all.
> >
> > >       a
> > >        ifTrue:[]              "a defaults to false"
> >
> > Why is this good? Why not default to true?
> >
> >         a
> >           ifFalse:[]
> > ???
> >
> > >       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?
>
> Thanks for all answers. I'm was aware of some of the thing you told me.
> My preferences in this context is that I as a user would like the computer
> to be smarter and take what I give it and use it to do something in the direction
> I was thinking. Nothing more. :-)
>
> Karl
> >
> > Cheers,
> > Bijan Parsia.

You know something like this could actually be implemented..

UndefinedObject>>#doesNotUnderstand: aMessage
| newInstance |
newInstance := aMessage argument class newWithDefaultValue.
aMessage sendTo: newInstance

of course.. something like this is.. well.. less than desirable. We'd have to
implement newWithDefaultValue... also, this kind of thing doesn't handle messages to
nil with non unary argument values. I mean.. how _do_ you choose which arguments
class to make the default from?
So.. I'd suggest no one actually does this :> But it's still possible either way.

Michael Lucas-Smith






More information about the Squeak-dev mailing list