(a) I need really to extend or subclass InputEventSensor
(1) I'm not really sure how to best add instance variables to InputEventSensor via MC.
Monticello unfortunately doesn't support that.
I discussed with goran because deltastream supports that. And indeed in smalltalk there was always this asymtric situation where you could add method incrementally but not state.
(2) I wanted to make a subclass, but then discovered RFBServer which I need actually hard codes a reference to InputEventSensor versus saying InputEventHandler defaultClass (or something)
-> yes not hardcoding class is a good design and it should be reinforced.
(3) RFBEventSensor then cheefully subclasses InputEventSensor which defeats my proposed subclass, not sure how in MC I could change the class hierarcy of someone else.
http://source.lukas-renggli.ch/unsorted/RFB-lr.13.mcz works out of the box in any recent Pharo image. The package does not change the base system and thus loads/unloads cleanly.
(b) RBSpellChecker only picks between macintosh and other, so adding a subclass for iPhone means hacking startup for RBSpellChecker, versus having the more standard iteration over subclasses and having them choose who can do the work. Also if it's not macintosh that does not mean it's iPhone, or windows, risc, or unix...
I fixed this in Refactoring-Spelling-lr.7, so that the spell checker is only initialized when it is actually used.
It looks to me that you are using a Pharo-Dev image, but I guess you would rather use a Pharo-Core image? Maybe the Pharo-Core image should be placed more prominent on the download page, I've seen numerous experienced people at ESUG downloading the "wrong" image.
Yes which tells me that we should also iron pharo-dev. Stef
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project