OO: a paradigm question

Mike Matthews omnis at lineal.co.uk
Sun Jan 10 09:15:34 EST 2010

A very good answer, even I understood it.

The whole concept of OO and reusability is at the top of my thoughts  
this week as I explore several different Accounting systems for  
clients.  Some systems provide very good thick client software with a  
good copy for a web browser version, using the web version to leverage  
the web side advantage but not leaving the user in a different land.   
The business logic and the storage of that logic is vital.  Where and  
how to store it, then also the way both interfaces work, I hate the  
idea of writing controls twice.  This will of course raise questions  
on this list, but I'm off sledging now.  :-)



On 10 Jan 2010, at 12:09, Geir Fjærli wrote:

> Hi Franco.
> This unfortunately is a limitation, not of the OO paradigm, but of  
> the Studio implementation of it. You cannot set the properties of an  
> inherited window component via the Property Manager. I have asked  
> for that for a long time. You can as you observe do it by code, but  
> that is cumbersome.
> You can overcome this partly by putting all those settings in a  
> public method in the superclass, which you can then override in the  
> subclass. Now you will face another limitation, Studio - using the  
> American semantics - will not use the parent code in an overridden  
> method, so when you do override that method none of the code will  
> show. The solution to that is to comment out the code in the  
> superclass, because Omnis will show comments in the subclass. Then  
> override in the subclass, and now you can uncomment the lines in the  
> subclass.
> Another, possibly better, solution is to keep the code in the  
> superclass, but add instance variables for the property settings  
> rather than setting the values directly in the code. Now in you  
> subclass you can simply overload those variables and set their  
> default value to the desired number. Personally I do not believe in  
> overriding variables, because it quickly becomes messy to know which  
> version is being used, but in this case where it is a de facto  
> constant value you might do an exception to that rule. It might be  
> wise then to prefix the variables in the superclass method with  
> $cinst, to instruct Omnis explicitely to use the subclass one.
> Hope this helps a bit.
> Geir :)
> Den 10. jan. 2010 kl. 12.48 skrev Franco Maregotto:
>> Ciao Community!
>> As someone said (JeanMarc) this is a real community, made not only  
>> by email
>> addresses, but also by brains, ideas, friendship, and (when in  
>> EurOmnis) by
>> hands, bier glasses, smiles and fun.
>> For this reason I want first to wish you all, but expecially the  
>> EurOmnis
>> fellow, a great 2010!
>> Let's go further, and discuss about some OO concepts.
>> During these months (since EurOmnis) I did not code a single line  
>> with
>> Studio, mainly for two reasons:
>> The first is that my Hotel was full and a lot of work to do. Even  
>> after
>> Christmas holidays I have a quite busy day to deal with..
>> The second is that I'm still dealing with the "damned" paradigm  
>> shift, so I
>> read, study, and read again the books suggested in this list.
>> Ideas are coming more clear now, but a "concept" about OO is not  
>> immediately
>> understandable:
>> Let me make an example with Omnis Studio:
>> For a group of windows classes, the code in $construct (and some  
>> other
>> "general" methods) became blue code.. (Hey Doug, I've got it!!)
>> Then I realized that NOT ONLY methods, but also buttons and lists  
>> could be
>> more "general". Great, I said..
>> I can code a button to be "polymorphic", pass to it some parameters  
>> and use
>> its blue code without worring about..
>> Now my need is to inherit the methods behind a parent list, but  
>> also change
>> the appearance of the list, or the position of a button inside the
>> subwindow.
>> If everything works great in a parent windows with buttons and one  
>> list,
>> what could I do to have this list wider, or to add a field (column)  
>> in it,
>> or to have my button in a different position?
>> What if a window have to display my customers list and behave  
>> always in the
>> same way (methods) but the data have to be displayed in a different  
>> way?
>> Please don't tell me I have to redraw it assigning every property  
>> via $cinst
>> commands (maybe with a ton parameters to change on-the-fly obj  
>> properties in
>> the instance).
>> Oh well, you could say it.. if it is the only available practice!
>> My answer would be: cut the buttons (or Window objs) you want to  
>> change, and
>> paste them in the subwindow. You'll have to check every button in  
>> every
>> child window, and you'll never be able to inherit the methods you  
>> wanted to
>> be executed.
>> Please guys: I just want to know if I'm approaching the right  
>> runway, or if
>> I'm landing over a forest. In other words: should I reset and start  
>> to read
>> again from 101 my Object Oriented literature?
>> Finally a wish for the 2010:
>> Fred, a specific 101 OO course for the next EurOmnis would be greatly
>> appreciated.
>> I have some names to suggest you...
>> Cheers
>> Franco
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com

More information about the omnisdev-en mailing list