[Cuis] [Philosophy] Do we need pool dictionaries?

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jan 22 13:14:10 CST 2014


2014/1/22 Sean P. DeNigris <sean at clipperadams.com>

> Nicolas Cellier wrote
> > But then, what difference with class variables?
>
> It's just like class variables but more flexible because:
> - you import a specific group or groups instead of individual names
> - you don't "waste" committing to a superclass. Without multiple
> inheritance, this is important. For example, in NativeBoost, there are
> objects representing external entities, which will use C constant names,
> and
> must inherit from a particular NativeBoost class. Then, if you make a
> facade
> for the library functions themselves, which also need the constants
> defined,
> but will not be subclassed from the same object.
>
>
>
The first thing that I was trying to say, is that pool dictionaries are
much like class variables.
So saying that we want to eliminate pool dictionaries because they are
globals is like saying that we want to eliminate class variables...

Eliminating pool dictionaries because we do not need two different
implementations for these variables is another matter...
It seems that my remarks did apply more to this second POV maybe?.
I wanted to put alternatives in balance, but I was not suggesting to remove
shared pools, and I agree they can be convenient...
Anyway, we can observe that modern shared pools are implemented by way off
class vars, so we cannot say these are two different implementations ;)


>
> -----
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Philosophy-Do-we-need-pool-dictionaries-tp4701469p4738491.html
> Sent from the Cuis Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20140122/540a65f0/attachment-0004.html>


More information about the Cuis mailing list