Front page | perl.perl6.language |
Postings from January 2002
Re: Some Apocalypse 4 exception handling questions.
Thread Previous
|
Thread Next
From:
Glenn Linderman
Date:
January 23, 2002 10:36
Subject:
Re: Some Apocalypse 4 exception handling questions.
Message ID:
3C4F031E.B1D73AF0@netzero.net
Me wrote:
>
> > > My question is, why are blocks like FIRST not inherited?
>
> > The FIRST (NEXT, LAST, CATCH) blocks from a method *MAY*
> > be completely inappropriate for use in any of its derived methods
>
> With my emphasis added. The same could be said of
> pretty much any code other than logical constraints,
> as covered in the next point:
Agreed. MAY, or even MAY NOT.
> Yes. Optionally. I was assuming something like, if you want
> the ancestor code, you say 'inner' or similar, just like all the
> other oo languages I've known. (Simula 67 used something
> like 'prefix', 'postfix', 'insert', right? Or maybe I'm thinking of
> some other language.)
If _all_ the code from the ancestor class is appropriate to the method
of the subclass, it is possible to call the method of the ancestor class
from the derived method of the subclass, at the appropriate point in the
method of the subclass. In such cases, the subclass method is
augmenting, but not replacing, the ancestor method. Different languages
have different syntaxes for invoking that; Perl 5 has one, and I'm sure
Perl 6 will have one. But I don't know of any language that allows
selective, individual statements from the method of the ancestor class
to be incorporated into the method of the subclass. Perhaps that is
because I only have experience and knowledge of a few OO languages, not
including Simula 67, but I've never heard of such a thing in the
literature either.
> Anyhow, for catcher blocks, I was originally thinking that if
> you name a block, then it would be inheritable, and would
> be inherited by default. (To NOT inherit it, you would have
> to declare it in descendants with an empty or different
> body.)
The control over whether or not it is inherited, would have to be in the
derived method. The problem I see with inheriting subblocks such as
FIRST/LAST/etc, is that they are tied in with the logic and lexical
variables of their enclosing block, and you would either have to inherit
them as closures, or as text macros. It is not at all clear to me that
either would be particularly useful, most of the time.
Having thought it through this far, it would seem that inheriting
PRE/POST could be difficult for the same reasons, except that they are
supposed to be evaluating preconditions and postconditions, and such
conditions shouldn't be dependent on locally lexically scoped variables,
so inheriting those blocks as text macros or even as (internally)
subroutine calls, should work, even outside the scope of their
definition. However, this has turned into an argument for PRE and POST
blocks to be defined OUTSIDE the scope of the block that they apply to,
or using some special rules, so that it becomes impossible for them to
reference locally lexically scoped variables contained within the block
to which the pre/post-condition applies.
> Thus avoiding the need for:
>
> > Where such a benefit might exist, a subroutine with appropriate
> > parameters could be written...
At least subroutines have parameters and return values that are
explicit, so the result is clear and understandable.
> Thanks for your response, which helped clarify the issues
> for me. Did Larry or anyone else write up their thoughts on
> this matter?
I think Larry wrote most of his publishable thoughts into Apoc 4,
although there have been some clarifying/extending emails on the list.
--
Glenn
=====
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Thread Previous
|
Thread Next