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