[Prev][Next][Index][Thread]
Re: simple method dispatch question
jt wrote:
...
> Hmm, no comments at all?
OK I'll speculate. :-)
I don't think it has to do with fancy multiprocessing memory
architectures. :-)
What about the situation where you say?
define method foo ( ... , arg2 == 1 )
....
define method bar ( ... , arg2 == 1 )
if this creates two singletons whose "object" is the number 1 would they
really be different? In other words, if you have objects with immutable
state and identity would it be faster to do the lookup and
return the "one" singleton object (across modules and dynamic
compilation contexts) or to just return an new singleton object
with an "object" that is "eq" (for just about any notion of equality)
with another.
Of course this means that == (the equality function, not the abbrev.
syntax for singleton) for this kind of singleton would have to
be defined to compare objects as opposed to the "pointers". Like the
old commerical says... you can pay me now or you can pay me later. :-)
And if == is defined this way how would you be able to tell the
difference??
(without passing both references into a FFI interface and playing
c hackery with the pointers).
From the DRM for the == function.
"Objects are considered identical if they are computationally
equivalent.
That is, there is no way for any possible Dylan program to
distinguish
them."
There is enough of loophole there (and with <singleton>'s def) to make
the above approach "legal".
The GOF singleton pattern is for objects that aren't immutable in
state and identity. Otherwise people wouldn't use it they'd just
assign the object to "global" var and just use it. Indeed in C++/Java
they'd just use the "value" and no "object" at all.
Dylan doesn't make a special case for such objects. Which is good
since you'd have to define some legal "hocus pocus" to deal with
methods specialized on such instances. The DRM leaves some
flexibility there for a implementation decision.
Lyman
Follow-Ups:
References: