Status: Accepted
Owner:
[hidden email]
Labels: Milestone-1.4 Difficulty-Easy
New issue 5142 by
[hidden email]: Color depends on Compiler while it
could just declare colors
http://code.google.com/p/pharo/issues/detail?id=5142The class Color is clever and compile accessor for classVar accesses on the
fly.
For example
black
^ Black
was defined using the following method.
named: newName put: aColor
"Add a new color to the list and create an access message and a class
variable for it. The name should start with a lowercase letter. (The
class variable will start with an uppercase letter.) (Color colorNames)
returns a list of all color names. "
| str cap sym accessor csym |
str := newName asString.
sym := str asSymbol.
cap := str capitalized.
csym := cap asSymbol.
(self class canUnderstand: sym) ifFalse:
[ "define access message"
accessor := str , (String
with: Character cr
with: Character tab) , '^' , cap.
self class
compile: accessor
classified: 'named colors' ].
(self classPool includesKey: csym) ifFalse: [ self addClassVarNamed: cap ].
(ColorNames includes: sym) ifFalse: [ ColorNames add: sym ].
^ self classPool
at: csym
put: aColor
While this is cool and probably fun to do. It links the Color class to the
compiler.
We should define by hand a nice initialization (quite stupid) and stop
relying on code generation.
_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker
Locked
