Re: [curl-email-news] foundation class update and request for comments

[<gh...@nc...>]

On 29 Oct 2001, at 6:21, Brent Young wrote:

> Hello all -
> 
>...
> Instead of having a package which you import which defines all of your
> MyVBox and MyCommandButton overrides, why not just define VBox and
> CommandButton to do what you want in the first place - this way you can
> actually have different "styles" in different packages.
> 
> Try this to see what I mean:
> 
> --------------------------------------------------------------
> {import * from CURL.GUI.BASE}
> 
> {define-class VBox {inherits CURL.GUI.BASE.VBox}
>   {constructor {default ...}
>     {construct-super ..., color = "blue"}
>   }
> }
> 
> {VBox "this is blue", "because it's my vbox"}
> -------------------------------------------------------------
> 
> So without changing any existing code, you can instantly redefine what
> the objects do simply by importing a package which contains the above
> definition.  (i think).
> 
> 
> Cheers,
> Brent
> 

This is very cool and definitely works as advertised.  Never woulda' 
thought you could create an object with the same name like that.

My thoughts are that if something is not a 100% true VBox it might 
be better if it had a different name.  If VBox acts different in different 
source files I would think it would be kinda' suprising at times.  
(Oh, THAT VBox!)  If you want to apply the same change to all 
VBoxes in your system and VBox is defined differently in different 
places you have to make the change in all those places.  If instead 
the VBoxes that are defined in various source files are derived from 
a single foundation class you would have the option of changing all 
VBoxes in the system or changing all VBoxes in any file by 
changing code in only one place.

Now if you had a few thousand lines of code and needed to change 
all your VBoxes Brent's idea would be extremely appealing.  But, if 
I'm planning ahead I still like the idea of a common superclass.

In practice (with PB) most foundation class objects are abstract 
classes and this is easily enforced in Curl if desired.  The general 
rule in PB was that all objects of type X should have a common 
ancestor that you can apply changes to.

There is no good reason to insist that because something was the 
best solution in PB it is also the best soution in Curl.  If there is a 
better way to do it in Curl let's find it.  I still think the foundation 
class paradigm is a good "first approach" for setting up our class 
libraries.

Best Regards,
Gene