Nicolas asked me to move the #traceMessages preference to
SystemNavigation and implement it as a pragma. SystemNavigation is a Singleton, therefore the SystemNavigation #default instance uses instance-side methods to, for example, define its 'browserClass' and 'hierarchyBrowserClass'. After trying to add #traceMessages there, I quickly discovered that Preference pragmas were intended only to be for class-side methods. Noting in Preferences class>>#prefEvent:, it sets up the SystemChangeNotifier to only worry about classes that are #isMeta. I could refine that #isMeta guard to allow singletons, although to do that I'd want to introduce a Singleton class and move SystemNav there... Another thing we could do is remove the guard; if someone puts a preference pragma in an inst-method, any problem with that? Of course, we could just keep it as a standard old preference.. Anyone have any preferences? :) |
2010/3/7 Chris Muller <[hidden email]>:
> Nicolas asked me to move the #traceMessages preference to > SystemNavigation and implement it as a pragma. > I would say suggested... > SystemNavigation is a Singleton, therefore the SystemNavigation > #default instance uses instance-side methods to, for example, define > its 'browserClass' and 'hierarchyBrowserClass'. > > After trying to add #traceMessages there, I quickly discovered that > Preference pragmas were intended only to be for class-side methods. > Noting in Preferences class>>#prefEvent:, it sets up the > SystemChangeNotifier to only worry about classes that are #isMeta. > > I could refine that #isMeta guard to allow singletons, although to do > that I'd want to introduce a Singleton class and move SystemNav > there... > > Another thing we could do is remove the guard; if someone puts a > preference pragma in an inst-method, any problem with that? > > Of course, we could just keep it as a standard old preference.. > > Anyone have any preferences? :) > What an instance side preference would mean ? A different preference for every instance ? My opinion is that they belong to class only. Nicolas |
> What an instance side preference would mean ?
> A different preference for every instance ? There is only one instance of SystemNavigation. > My opinion is that they belong to class only. I suppose I could add the first class-var to SystemNavigation. However, SystemNavigation is a Singleton _instance_ which is where its other state and API are. So we would have this lone #traceMessages option on the SystemNavigation class-side just so we could use a pragma. It creates a dichotomy about which SystemNavigation is supposed to be used. Since you were only suggesting anyway, the easiest thing for now would probably be to just leave it in Preferences. - Chris |
On 3/7/2010 5:04 PM, Chris Muller wrote:
>> What an instance side preference would mean ? >> A different preference for every instance ? > > There is only one instance of SystemNavigation. > >> My opinion is that they belong to class only. > > I suppose I could add the first class-var to SystemNavigation. You don't have to. You can delegate the class-side method to the singleton instance, i.e., SystemNavigation>>traceMessages "Accessor for preference" <preference: ....> ^self default traceMessages etc. This requires the methods on the class but not the state. Cheers, - Andreas > However, SystemNavigation is a Singleton _instance_ which is where its > other state and API are. So we would have this lone #traceMessages > option on the SystemNavigation class-side just so we could use a > pragma. It creates a dichotomy about which SystemNavigation is > supposed to be used. Since you were only suggesting anyway, the > easiest thing for now would probably be to just leave it in > Preferences. > > - Chris > > |
Free forum by Nabble | Edit this page |