[Pharo-project] Preference initialization
Hi all, while working on the sensor fix I ran across the problem that there is no initialization code for current preference settings, a typical side effect of working with an image. Problem is, that references, in my case to the class InputSensor, can't be found by the usual cross reference methods. IMHO we should come up with "something" so we can re-generate the current preferences from code if needed. That initialization code would also provide the necessary cross references. Not sure how that plays with the pragma preference stuff... Michael
Hehe, a lot of class initialization code could be removed once used... That would make the system even harder to understand/change. Among obvious reasons why this kind of code should be kept somewhere else than a doIt in a forgettable changeLog: - going toward a more modular system... - ...that can enable a change of UI, - making system easier to understand by making some object relationships explicit, - and being able to build an image ex-nihilo You gain a +(5 raisedToTheSuperPowerOf: 5) (Don't try and evaluate it) Integer>>#raisedToTheSuperPowerOf: anInteger anInteger < 0 ifTrue: [^self error: 'requires a positive integer argument']. anInteger = 0 ifTrue: [^1]. anInteger = 1 ifTrue: [^self]. ^self raisedTo: (self raisedToTheSuperPowerOf: anInteger - 1) Nicolas 2009/4/27 Michael Rueger <m.rueger@acm.org>:
Hi all,
while working on the sensor fix I ran across the problem that there is no initialization code for current preference settings, a typical side effect of working with an image.
Problem is, that references, in my case to the class InputSensor, can't be found by the usual cross reference methods.
IMHO we should come up with "something" so we can re-generate the current preferences from code if needed. That initialization code would also provide the necessary cross references.
Not sure how that plays with the pragma preference stuff...
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/4/27 Michael Rueger <m.rueger@acm.org>:
Hi all,
while working on the sensor fix I ran across the problem that there is no initialization code for current preference settings, a typical side effect of working with an image.
Problem is, that references, in my case to the class InputSensor, can't be found by the usual cross reference methods.
IMHO we should come up with "something" so we can re-generate the current preferences from code if needed. That initialization code would also provide the necessary cross references.
You're right. An image should not contain artifacts, which can be reproduced only by wizardry (manual doits).
Not sure how that plays with the pragma preference stuff...
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Michael Rueger a écrit :
Hi all,
while working on the sensor fix I ran across the problem that there is no initialization code for current preference settings, a typical side effect of working with an image.
Problem is, that references, in my case to the class InputSensor, can't be found by the usual cross reference methods.
IMHO we should come up with "something" so we can re-generate the current preferences from code if needed. That initialization code would also provide the necessary cross references.
Not sure how that plays with the pragma preference stuff...
If I well understand, the problem is as follow: You have a preference which value is a class (InputSensor). The problem is that the class InputSensor can be removed or changed, letting your preference value point to AnObsoleteInputSensor. You would like to be warned that InputSensor is used as a preference value when you're about to remove that class. Do I understand well ? For such a situation, the new setting package can provide the initialization code you would like with the help of a SettingStyle. A SettingStyle only responsibility is to provide a load method which, when evaluated, re-generates settings. We could have a "current" SettingStyle always up-to-date and which would be automatically changed (generating of the load method) every time a setting value is changed. Of course, then, a simple setting change would be time consuming but I guess this is not very important because settings are set rarely. what do you think ? alain
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Apr 28, 2009 at 9:15 AM, Alain Plantec <alain.plantec@free.fr> wrote:
If I well understand, the problem is as follow: You have a preference which value is a class (InputSensor). The problem is that the class InputSensor can be removed or changed, letting your preference value point to AnObsoleteInputSensor. You would like to be warned that InputSensor is used as a preference value when you're about to remove that class. Do I understand well ?
Yes and no. ;-) I don't think classes should be referenced directly as preference values, but that is a different discussion. In my case it was the changeInformee inst var that pointed to that class. And that inst var can only be set programmatically. But, there is no code in the system that does that anymore.
For such a situation, the new setting package can provide the initialization code you would like with the help of a SettingStyle. A SettingStyle only responsibility is to provide a load method which, when evaluated, re-generates settings. We could have a "current" SettingStyle always up-to-date and which would be automatically changed (generating of the load method) every time a setting value is changed. Of course, then, a simple setting change would be time consuming but I guess this is not very important because settings are set rarely.
what do you think ?
I think that would be overkill. Preference initialization code doesn't need to be able to create the current settings, only a default set of settings. But your proposal have me a different idea how to solve the problem for preference values: For references to objects or classes in the value entry it would help to have the class reference search also go through the preference values. That way you would get informed of references to a class from preferences before removing the class. There are probably other well known locations that should be checked (e.g. Object Dependents). Michael
still Don't you think that having a default can can be regenerated is not better and simple? May be I missed something.\
But your proposal have me a different idea how to solve the problem for preference values:
For references to objects or classes in the value entry it would help to have the class reference search also go through the preference values. That way you would get informed of references to a class from preferences before removing the class. There are probably other well known locations that should be checked (e.g. Object Dependents).
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
still Don't you think that having a default can can be regenerated is not better and simple?
Not sure what you are saying here. I'm proposing having "something" so we can regenerate the default setup. Alain proposed to be able to regenerate the current settings, which I don't think is what we want, especially as that would mean dirty packages every time you change a setting. Michael
But your proposal have me a different idea how to solve the problem for preference values:
For references to objects or classes in the value entry it would help to have the class reference search also go through the preference values. That way you would get informed of references to a class from preferences before removing the class. There are probably other well known locations that should be checked (e.g. Object Dependents).
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Apr 29, 2009, at 9:44 AM, Michael Rueger wrote:
Stéphane Ducasse wrote:
still Don't you think that having a default can can be regenerated is not better and simple?
Not sure what you are saying here. I'm proposing having "something" so we can regenerate the default setup.
OK
Alain proposed to be able to regenerate the current settings, which I don't think is what we want, especially as that would mean dirty packages every time you change a setting.
OK I understand and I agree with you.
Michael
But your proposal have me a different idea how to solve the problem for preference values:
For references to objects or classes in the value entry it would help to have the class reference search also go through the preference values. That way you would get informed of references to a class from preferences before removing the class. There are probably other well known locations that should be checked (e.g. Object Dependents).
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Alain Plantec -
Igor Stasenko -
Michael Rueger -
Nicolas Cellier -
Stéphane Ducasse