I use a lot of ancestor coding and almost never use me.pProp syntax.
If your properties are properly placed within their current class,
there is probably no reason to move or copy them to another class. If
you need to reference them from the subClass, you just the me.pProp
syntax there. But I rarely do this, but rather rely on methods to
communicate between the different levels in the ancestor hierarchy.
You may have to add a few accessor methods to your superClass.
Overriding methods of the superClass in the subClass is often used
when designing a specialized subClass. Many times you have complex
methods in the superClass, referencing lots of properties. Then you
want to have a slightly altered method in the subClass. So rather
than re-implementing the complete complex method in the subClass, you
isolate the parts of the complex method, that you need to override,
in separate "subRoutine" methods, to which you pass the required
properties as parameters. Then you only need to override the
"subMethod" in the subClass, and you don't need to access the
properties of the superClass.
Of course one needs to be careful not to start implementing the
specific needs of the subClass in the superClass. It's more like;
When you start using the superClass to serve the more specific needs
of the subClass, you identify certain patterns of flexibility, that
your superClass can be sub-divided into. Things that it might not
have been obvious to isolate until you expanded and changed the
functionality of the complete "metaObject" with the functionality of
the subClass.
Changing the implementation of a method, so that it's operations are
split into several subMethods, is not a violation of the existing
interface of the class, as long as the method's total functionality
is unaltered.
Generally I try to adhere to the principle, that a property should be
operated upon by methods at the same level. If you are excessively
referencing properties across levels, it could well indicate a skewed
structure.
Classes in a "metaObject" built of an ancestor string can be thought
of, as different levels of abstraction in your design. As such it
could be an indication of a healthy design, if the different levels
have the majority of their communication in the form of more abstract
method calls.
I think it would be a very clear indication of something unhealthy if
the same information is redundantly maintained at different locations
anywhere, but particularly within the same metaObject.
As you say yourself: Your toggles are probably never going to put any
significant performance burden on your system, so the generally
negligible contributions of method-calls relative to actual
operations, are probably never going to show in any perceptible way.
So why worry about some optimizations, that will be insignificant in
your whole design, when you can take the opportunity to wrestle with
some more "polite" design.
Hope that was thougth for food.
Cheers, Jakob
P.S.
This I posted on Direct-l, some of it seemed better addressed here. ;-)
>Roy, since you made this a cross post thread, what is you're advice to us now?
>I've posted a reply on Lingo-l, and if this thread takes on here,
>we'll probably either see a doubled thread or a diluted thread.
>I understand you want to harvest from the biggest field possible,
>but this situation is the bane of the virtually divided lingo
>community.
>
>I still don't see a purpose of the general Director community being
>split into two halves, discussing the exact same issues
>alternatingly, despite their different agendas. this is an old gripe
>of mine, and I air it knowing very well, that it will likely make no
>difference.
>
>At the very least Lingo-l could have an archive, so we don't loose
>half of the information.
>
>Regards, Jakob
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
