[Pharo-project] some thoughts on coding practices.
Today I was faced with trying to consolidate some overrides for the iPhone work and faced the following issues: Or perhaps it just wasn't my day to do software development on the EuroStar. (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. (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) (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. (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... These both seemed hurdles to getting somthing productive done so I'll welcome comments about how to make it easier. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
(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.
(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) (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. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
(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
On 6-Sep-09, at 8:54 AM, Stéphane Ducasse wrote:
(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.
So is there a Lint rule for this or someone thinking of doing that cleanup? Or a bug? report?
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.
Er well I thought the iPhone users would *like* to access the dev image? Is that wrong? -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
(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.
So is there a Lint rule for this or someone thinking of doing that cleanup? Or a bug? report?
I have to check for the smallLint rule. For now open a ticket
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.
Er well I thought the iPhone users would *like* to access the dev image? Is that wrong?
No but we got some glitches with the different browsers related to OB because code diverged and we would love to get it on track but david is working on papers :) Stef
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
John M McIntosh -
Lukas Renggli -
Stéphane Ducasse