[squeak-dev] [Question] nil, true, false in array literals

Igor Stasenko siguctua at gmail.com
Wed Dec 3 15:57:58 UTC 2008


2008/12/3 James Foster <Smalltalk at jgfoster.net>:
> Igor,
>
> What would you expect from the following: #(1)? Should it be (Array with: 1)
> or (Array with: #'1')?
>
> I think that the assumption is that you should be able to include any
> literal constant (including SmallIntegers) in a literal constant array. I
> think of #(foo) as a shortcut for #(#'foo'), where the second form is more
> explicit. If you want to avoid the ambiguity, then always be explicit when
> you want a symbol.
>

Well, the point is, that i look differently at such names. I don't
treat them as literal constants, but as names which globally bound to
some object.

And i can explain why.
Suppose i want to introduce a class(es) to work with ternary logic:
'true' 'false' 'unknown' .. or whatever.
Does it makes an 'unknown' name less privileged than 'true' or
'false'? So, what do you do in this case? Introduce a new 'literal
constant'? Otherwise you'll have an issue with #(true false unknown) .

Another variant and same question: Some of us using a Null class to
make use of message eating nulls.
Now, if i want to return null, can i introduce a 'literal constant'
named 'null' as well?
Or, what makes 'null' less important (for someone) than 'nil'. A
little bit of discrimination :)

Another guys can come and say: hey, i'm a matematician, and i want a
'literal constant' named 'epsilon' , so lets modify compiler to
resolve it as a sole instance of Epsilon class.

So, how many of such 'literal constants' we may need in future? Or
maybe, if we treat such names as globals, then we won't need to hack
the compiler every time?
And then, obviously #(true false nil) = (Array with: #true with:
#false with: #nil)

> James
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list