This time I can explain in clear term with an abstract example, so I hope that answers came, because is linked to the core of my Spring backgarden entry.
I have a custom class, mainly for scoring (NOT in that sense, eh !) sundries (as in “finding sundry items”) thru a dobjFor whose award the points, then inherits the standard dobjFor.
all fine, but I need also a custom dobjFor of the very same action for some of these sundries, whose sets important narrative elements.
That is, there’s three dobjFor layers:
dobjFor in (some) sundries objects,
dobjFor in the sundries class,
the library’s dobjFor
that is, the dobjFor of the object in the sundries class do his specific, then inherits into the class dobjFor whose in turn inherits into library’s dobjFor
is possible this recursive inheritance ? and if yes, in what order are inherited ?
the really fine manuals don’t say about this specific thing; normally I have experimented in detail the behavior of recursive inheritance, but with no more than a fortnight prior of a deadline, I can’t proceed with my usual slow & ponderate pace…
I’m not sure I entirely understand the issue here, but in brief you can inherit the behaviour of a superclass’s definition of a method by using the inherited keyword (which is part of the TADS 3 language), The dobjFor syntax is just a convenient way of grouping certain method definitions together, so that, for example dobjFor(Foo) { verify() {...} action() {...}} produces two methods in fact called verifyDobjFoo and actionDobjFoo which can inherit from their superclasses in the normal way using inherited.
So in any object or class definition you can write stuff like:
dobjFor(Foo)
{
verify()
{
inherited();
if(whatever)
illogical(whateverMsg);
}
action()
{
/* Do special stuff here */
/* Then do the superclass' version */
inherited();
}
}
The order of events is determined by where you place the inherited() statement in your code.
But if you’re asking about how inheritance works more generally in TADS 3, you need to consult the TADS 3 System Manual and the TADS 3 Technical Manual for more detailed information on this topic.
I have read thrice the relevant parts of system manual, and my case indeed seems the fourth case one yourself reckon as “It is probably this last case that seems the least intuitive and the most potentially confusing” in your article on multiple inheritance in TADS technical manual.
So, better raise a bit the curtain and expose the actual case:
There’s an item with 45 components (I’m not joking) each worth one point, effectively handled by grouping the component in an appropriate class (hence the note in PM I sent you this (friday) morning) whose works as expected.
Now, next step, the point is given when EXAMINED, and this is the already-implemented (custom)class-level dobjFor.
But these 45 components are in three layers, examining a top-level component will nil the isHidden flag from its direct sub-components, and in turn examining the now in-scope sub-component will nil its direct third-level isHidden flag. simple to implement, adding isHidden = true to the custom class, then giving isHidden = nil to the top-level. (as a welcome bonus, this get rid of the extreme disambiguation (at the very beginning of the story…)
now, the confusion begins here. Nominally, IsHidden = nil will be placed on a dobjFor (examine) on the top-level components, for their specific sub-part, so, from an inheritance perspective, we should have:
DobjFor (Examine) at the component level (only the top and 2nd layer), whose deal with the removal of the isHidden flag
DobjFor (Examine) at the class level, whose deals with the scoring
and last, DobjFor (Examine) at the library level, whose deals with the output, setting the examined flag, and all the &c. &c. of housekeeping. And from the Object Inheritance model in system manual, the right order should be assured.
apparently linear, but… a dobjFor internally has its five distinct phases, verify &c. on which, only the action one is involved at the object and class level. Reading, uh, 5 chapters on inheriance in three books, isn’t clear if there are pitfalls in dealing only with inherited action in a dobjFor (if you’re lost now, basically the verify, check &c. remains the library ones, only action changes, either at the class and object level, or only at the class level.
basically, in the most inherited case, I should have:
library’s verify()
library’s preCond()
object 's action() whose inherits from class’s action() whose eventually inherits in turn from library’s action()
library’s report()
library’s remap()
or else ?? <— this is the core point !!
Hope to have cleared the question instead of increasing the murkiness…
I confess I’m still not entirely sure what problem you’re facing here. It sounds like it may be to do with multiple inheritance, but I’m not sure why that’s needed here.
I’m imagining you may have defined a TopLevelComponent class along the following lines:
class TopLevelComponent: Component
dobFor(Examine)
{
action()
{
/* Code to unset the isHidden flag on the next level down. */
....
/* Call the library's handling. */
inherited();
}
}
;
Then on the bottom level class you might have something like:
BottomLevelComponent: Component
dobjFor(Examine)
{
action()
{
/* Call the library's handling. */
inherited();
/* Code to handle the scoring */
....
}
}
;
If you need something more complex and you want to be sure you’re calling the library’s version of dobjFor(Examine) you can use this alternative form of inherited:
dobjFor(Examine)
{
action()
{
/* Call the library's version */
inherited Thing();
/* Then do your own custom stuff */
}
}
But I suspect I may still be missing something about your problem?
Aside that you have mixed the placement of scoring and unhiding, or more correctly, discover, two thing are damn true:
Night brings advice
learned people always overlooks simpler, basic solutions.
And, with embarassment I note that on the removal of the hiding, the simpler solution was in plain sight in the earliest pages of your Learning Adv3Lite:
[quote]
solved, but with a major embarassment, whose I fear is mutual…
