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 _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners