'The' Jakob Hede Madsen wrote
> Keeping in mind the "is a" test, which Brennan just refreshed.
> The man _has_ a pocket, he _is_ not a pocket.
> Therefore, making an aggregate object, as you are doing, is a
> suitable structure.
In XML there's an interesting distinction between 'attributes' and
'elements', which took me a while to grok into fullness. The same
distinction appears in Applescript.
An 'attribute' is a property which describes the object, such as a
colour, where an 'element' is a property which 'goes to make up' the
object, such as a pocket. It represents aggregation. I suppose an
ancestor is a very special kind of element.
Something as rigorous as Smalltalk, which has no primitive datatypes,
would probably see everything as elements, i.e. all objects are
aggregates (even 'colour' has structure in the form of red green and
blue values) but it can be convenient to have properties which are more
'flat' and purely descriptive, properties which do not have a structure
of their own.
It could be that Zac, that notorious XML enthusiast will have some
further insight here.
> While you are at the level of implementation:
> I never saw the use of 'pass' in this application, and in fact when I
> just tried it, I just got an error.
It's true! I didn't test it. 'pass' is (unfortunately) reserved for
Director's own system messaging hierarchy. It is only useful in mouse,
key and frame event handlers.
Additionally I often use 'pass' in runPropertyDialog. Usually like this:
on runPropertyDialog me, pdlist
if not the shiftdown then
pass -- i.e. call getpropertyDescriptionList
end if
-- here you can set behavior properties automatically
-- without the user messing around in the dialog box.
return pdlist
end
(I have a half-written article about this and related topics, which
should one day appear on DOUG. Now that I've finally got Director8, I
can ensure that things like 'scriptList' are covered properly.)
> This is how I usually implement overriding while still using the superMethod:
>
> on mMethod me
> --<specific subClass implementation>--
> return callAncestor(#mMethod, me)
> end
I've been doing something much the same:
return call (#mMethod, ancestor)
I'd like to see 'pass' fleshed out a bit more.
Alternatively, it would be nice if there was a function (like 'the
result') which always held the symbol and parameter list of the most
recent call. This would be very useful for debugging at runtime.
(There's an interesting related thread over at DirectL about the
alertHook and its limitations).
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:[EMAIL PROTECTED]
"I suppose if I'm honest, I use my penis as a sort of car substitute."
-Stephen Fry
[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!]
