[squeak-dev] some thoughts on coding practices.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] some thoughts on coding practices.

johnmci
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
=
=
=
========================================================================





Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] some thoughts on coding practices.

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

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] some thoughts on coding practices.

Bert Freudenberg
In reply to this post by johnmci
On 05.09.2009, at 22:46, John M McIntosh wrote:

> (a) I need really to extend or subclass InputEventSensor
> [...]
>
> These both seemed hurdles to getting somthing productive done so  
> I'll welcome comments about how to make it easier.


You could put a refactored InputEventSensor into the trunk that has  
hooks for your needs.

- Bert -