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 <[email protected]>:
> 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
> [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
