On 19 Dec 2005, at 11:38, Oliver Steele wrote:
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.
I really like the Dylan solution, where classes and generic functions
(the analog of methods) are sealed by default, but sealing applies
only at the library level. (So, within a library everything is
effectively open, and outside the library everything is sealed by
default.)
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
