I also like the idea since I always loose a few seconds to figure out  
where some method, like vmStatisticsReportString, is located. There  
are at least three different selectors used to access a singleton  
instance:

SmalltalkImage current
SystemNavigation default
SystemChangeNotifier uniqueInstance

I just can't remember them.

Adrian

On Jul 24, 2009, at 12:27 , Igor Stasenko wrote:

> I am currently using the Cuis, which doesn't having a 'SmalltalkImage
> current' refactoring..
> And this difference is a bit frustrating to me, especially when code
> which have to be ported from Squeak,
> i need to visit all the places and fix the references.
>
> I was not here when this change was introduced, and you maybe know ,
> that i'm a heated enemy of global state.
> But i understand the reasoning of dissection the Smalltalk dictionary
> of globals from the rest of service methods & additional state,
> which is needed and which were putted in SmalltalkImage class.
>
> But the more i thinking about it, the more i feel that this
> 'dissection' can be done in least intrusive way which is much
> friendlier to 'old ways'
> but also plays well with 'current ways'.
>
> So, what i'm proposing:
>
> - make a dictionary of globals a pure dictionary, without any extra
> unrelated methods.
> - completely move all fat stuff into SmalltalkImage from  
> SystemDictionary class
> - add 'globals' ivar to SmalltalkImage class , and add proxy methods
> for accessing the dictionary, like #at: #at:put: etc.
>
> then simply:
> Smalltalk at: #Smalltalk put: (SmalltalkImage current).
>
> Now, Smalltalk == SmalltalkImage current and everyone is happy:
> - dictionary lives in separate ivar,
> - fat & boring housekeeping stuff lives in SmalltalkImage instance.
>
> What you think?
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to