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 <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> (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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> (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.

Yes which tells me that we should also iron pharo-dev.

Stef


_______________________________________________
Pharo-project mailing list
[hidden email]
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?


Er well I thought the iPhone users would *like* to access the dev  
image? Is that wrong?


--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I have to check for the smallLint rule.
For now open a ticket
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project