This makes me thinking that relying on class initialization is not that robust may be lazy accessor (but this is boring to have to pay that price all the time). Lazy class var accessors are good when you have dependencies between classVar. So if somebody has some good idea to have robust and fast.... Stef On Feb 4, 2010, at 9:34 PM, Henrik Sperre Johansen wrote:
On 04.02.2010 21:11, Stéphane Ducasse wrote:
Nicolas nicely answered to the problem Thanks a lot.
Comment 1 by nicolas.cellier.aka.nice, Today (10 hours ago) I tested with this:
(TextConverter allSubclasses reject: [:e | e subclasses size> 0]) select: [:e | (e latin1Encodings copyFrom: 129 to: 256) anySatisfy: [:e2 | e2 isNil]] -> a Set(MacRomanTextConverter Latin1TextConverter)
Then this:
(TextConverter allSubclasses reject: [:e | e subclasses size> 0]) collect: [:e | e ->((129 to: 256) select: [:e2 | (e latin1Encodings at: e2) isNil])]
-> MacRomanTextConverter->#(163 164 170 178 182) -> Latin1TextConverter-> (129 to: 256)
All problems disappear if I do this: Latin1TextConverter initializeLatin1Encodings. MacRomanTextConverter initializeLatin1Encodings.
Don't know why something went wrong with lazy initialization leading to a class instance variables notNil, but not initialized correctly... Maybe the #initializeLatin1Encodings should be called in each text converter class initialize...
I will integrate that soon :)
Stef
That is strange... Classes were recompiled when I changed the method name from initializeLatin1MapAndEncodings to initializeLatin1Encodings, and removed the latin1Map (Now called nonAsciiMap, residing in ByteString. If there's a better suggestion of where to put it, please speak up). Not sure how the reinitialization could have failed though, especially seeing how calling them again works :/
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project