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
|
