[Newbies] Re: Testing = and == in workspace

nicolas cellier nicolas.cellier.aka.nice at gmail.com
Sat Jan 7 14:50:09 UTC 2012


Ben Coman <btc <at> openInWorld.com> writes:
>   
> 
> Thanks Bert. Doing that is insightful.  Interestingly the result is
> different with numbers.  Where strings assigned in separate executions
> are not identical, numbers assigned in separate executions are
> identical - at lower values.  For example, number 12345678 has (x) and
> (y) identical but with 123456789 they are not.  I then expected those
> number literals to be a different class, but both numbers inspect as
> SmallIntegers.  btw this is with Pharo-1.3-13315-cog2522.  
> Anyway, my curiosity is satisfied for now.
> cheers, Ben
> 
> 

I was about to invite you to dig a bit deeper in the system in order to satisfy
your curiosity, but it's a bit harder than I imagined...

You could start your search with a method finder looking matches of *literal*
One should deserve your attention, Encoder>>encodeLiteral:
You will see it uses an inst. var. named litSet.
If you browse references to it, you'll see it is initialized with StdLiterals
class var. in Encoder>>#initScopeAndLiteralTables
You can inspect this class var and see it is a PluggableDictionary (not a set as
the litSet name did tell).
If you browse references to StdLiterals, it is indeed initialized in
VariableNode class>>initialize with
StdLiterals := PluggableDictionary new equalBlock: [ :x :y | x literalEqual: y ].

So finally, we get it, the method of interest is #literalEqual:
If two literals are literally equal, then only one is created.
I encourage you to understand why 2, 2.0s1, 2.00s2 and 2.0 are not literally
equal, though they arithmetically are

Of course, why is Encoder a subclass of ParseNode (an Encoder is not a ParseNode
!), why a class variable used exclusively in Encoder is initialized in
VariableNode, would be very good questions. The implementers did choose
inheritance just to share a few class variables, and this is not a very clean
design.
Even the indirection #name:key:class:type:set: is rather arguable, it factors
code of two senders at the price of a complex interface (5 parameters is way too
much), and thus at the price of readability. 
But hey, why do you think some people started to write a NewCompiler ;)
Also, anti-patterns are also a very good way to learn how to (not) code, so in
its way these are good lessons for noobs.

Nicolas



More information about the Beginners mailing list