On Dec 14, 2005, at 5:25 PM, Neil Mix wrote:
Part of the problem here is determining the reason for extending
the base class:
a) the base class was cleverly designed so that certain objects
were intended to be extended/replaced
b) the base class doesn't fit my needs and I need to tweak it a
little to make it useful for me
Making *everything* open is useful for option (b) and perhaps
necessary with swiss-army-knife objects like the view class, but
scary for option (a) because the stuff that's "public" is
indistinguishable from the stuff that's "private". OTOH, requiring
explicitly defined access points means that your base class
implementer needs to be clever enough to know what to open up.
This is probably a religious issue.
Being able to do (b) has an obvious analogy to "open classes" in
Python, Ruby, Smalltalk, and (effectively) CLOS and JavaScript 1.5.
There's also a parallel to virtual methods. In C++, methods are
static/final by default, unless you remember to add a 'virtual'
modifier. In Java, methods are overridable by default, unless you
add a 'final' modifier. (And in many of the OO scripting languages,
overridable methods is the only possiblity.) The C++ default makes
for faster programs, but inflexible classes --- I've often seen it
referred to as a mistake.
It's a classic chicken and egg with no perfect solution.
Personally, I like open access (solving problem b), but it's always
useful if there's some way for the clever base class implementers
out there to provide hints regarding the objects s/he *wants* you
to extend/replace. That is perhaps some reason for designing a
form of "typing" where the base class can declare what type of
object may replace specified children.
Or maybe the question answers itself: replacement is useful for
(a), while extension is useful for (b). And thus one would be
allowed to extend any child elements, but would only be allowed to
replace those that were declared as replaceable by the class
implementer.
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
