Re: Inheritance and Loaded Libraries
Re: Inheritance and Loaded Libraries
- Subject: Re: Inheritance and Loaded Libraries
- From: has <email@hidden>
- Date: Sun, 7 Aug 2005 16:05:27 +0100
Hi,
>Okay, I'm convinced. (Not only by Hamish's argument/explanation here, but
>also by some discussion with the original authors of AppleScript. Plus the
>facts kind of speak for themselves.)
>
>So for the second edition of the book, shall I just call this delegation
>(and "the delegation chain") and throw in a note saying that the ASLG
>wrongly calls it inheritance?
I would call it 'delegation-based inheritance', which is a standard term. You could define 'inheritance' in terms of behavioural composition, modification, extension and reuse (i.e. the theory side), since readers need to know why they'd want to use it in the first place. Then explain with lots of diagrams (it's a lot easier to show this stuff visually) how AS supports it using delegation chains, a distinct series of objects linked together via parent properties so that messages automatically propagate along the chain from object to object until handled. You could also explain how this is different to class-based inheritance, where everything gets squished together into a single object upon instantiation.
>Now that I've asked the question, I have to say I'm 99% sure the answer
>should be "yes". Plus it would mean I'd only be using the word "inherit"
>with regard to the way a class's properties are listed in the dictionary,
>thus getting rid of a big ambiguity.
Discussing dictionaries is a whole problem of its own, but as far as inheritance there goes, the theory's the same (only simpler, since you only need to discuss the compositional aspect) and it's effectively representing class-based inheritance so you're just dealing with a single object. Dictionaries are purely documentation anyway, so there's no guarantee that the underlying implementation bears and resemblance to what the dictionary says, but as long as it works as advertised it doesn't matter anyway. The only two things scripters consider inheritance for in this context are:
1. Working out all the properties and elements a particular object provides, which is a simple matter of adding everything together (with duplicate attributes in child classes replacing those of parent classes). That technique's easily demonstrated by showing a very simple pedagogical dictionary containing maybe three class definitions inheriting from one another, each with one or two properties and elements, explaining how to add them together when working out what behaviours the child classes contain, and showing how each sub-class definition 'looks' with its parent definitions collapsed into it. In this respect, 'inheritance' in dictionaries is purely a notational shorthand, though with the odd discrepancy that while most applications use it for property definitions they tend (stupidly) always to repeat element definitions. (My HTMLDictionary app automatically strips out these duplicates for conciseness, FWIW.) And a few apps (e.g. InDesign) don't use it for this at all, tediously re-listing all attributes for every class definition (part of the reason ID's dictionary is so horribly bloated; while it is a large and complex interface, ID's dictionary manages to make it look even bigger and more complex than it actually is).
2. Working out how different elements in a particular object are related in order to predict what a given reference will return, e.g. the difference between using 'get items of myFolder', 'get files of myFolder', 'get document files of myFolder'.
Mind you, the biggest problem with dictionaries is lousy viewing tools, unless you want to spring for a copy of Script Debugger, or are willing to use appscript's built-in help() system. It's very nice, for example, to view the entire dictionary in minimal form, but when inspecting individual class definitions to see all their attributes together, including those inherited from superclasses.
>I hate when I use the same word in two different senses in any book of mine.
Homonyms and synonyms are a perennial problem in programming. All you can do is warn readers about this up front, then try to be as clear as possible about a word's intended meaning in a particular context. But I think if you limit your use of the word 'inheritance' to the theory side, where its meaning is consistent, and avoid using it slap-dash when talking about the implementation side, I think you'll be ok.
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden