<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
nicolas cellier wrote:
<blockquote cite="mid:loom.20120107T153106-453@post.gmane.org"
type="cite">
<pre wrap="">Ben Coman <btc <at> openInWorld.com> writes:
</pre>
<blockquote type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<pre wrap=""><!---->
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
</pre>
</blockquote>
Wow thank you for that detailed reply. <br>
I can see the ScaledDecimal>>literalEqual add the requirement
"[self scale = other scale]"<br>
</body>
</html>