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

[Nicolas Cellier]

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

> Juan Vuletich-4 wrote
> > I don't like pooldictionaries. They look like "hidden globals" to me,
> > and they are as bad as regular globals. Maybe there were good reasons
> > for them 30 years ago, but I don't see any today, except for
> > compatibility.
>
> I agree that they should be avoided if possible, but they seem useful e.g.
> for NativeBoost in Pharo. There are many C constants, and you'd like to
> refer to them directly so you can copy/paste from documentation, and so
> that
> you don't have to context switch as much when writing C calls. With shared
> pools, you can import them into the namespace of all classes that directly
> access the library.
>
>
But then, what difference with class variables?
class vars also are  global, just with a bit more restrictive visibility
(subclasses)...

Usage of such globals for well known constants (like a C macro) is not that
problematic.
Of course, it's possible to replace such shared pool by message send:
Character cr rather than CR.
But note that you replace a global (CR) by another global (Character).
OK reducing the number of globals is already something...
Also, motherness is not always that trivial, is it Text centered or
TextAttribute centered?

Sure, some small optimization difference still exist:
- is a new instance created or a constant shared?
- is a message sent or not (note that Squeak 4.5 now send a message to
access the #value of a global)
That indeed might have influenced decisions in the 70s.

Usage as a shared mutable state is more problematic
It's hardly possible to avoid such states (like a registry of opened files
for example)
in this case, yes, it's better to restrict access (encapsulate) with a
class var.
But I think Pharo already cleaned out the ugliest examples in
TextConstants, no?



>
> -----
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/Philosophy-Do-we-need-pool-dictionaries-tp4701469p4738435.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/86612d92/attachment-0004.html>