Re: GNAT controlled types

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

Many thanks for the comprehensive reply.  I had forgotten that the rule
applies wholesale to tagged types (as it sensibly must).

I have to say, with the benefit of hindsight, it might have been a better
decision to implement controlled types in a different way.  I feel sure
that -- by means of inlining -- undue performance penalties could be
avoided.  It is surely inconvenient, at times, not to be able to control
non-tagged types.  This ability may have been considered 'dangerous' or
unnecessary by the committee, but wrongly IMHO!

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Robert A Duff wrote in article <EnEu4B.6rr@world.std.com>...
> It's not a special rule about controlled types (although that's what the
> GNAT error message might imply).  The rule is that when you have a type
> extension, "type T2 is new T1 with ...", T2 must be at the same nesting
> level as T1, where "nesting level" means dynamic nesting, like
> procedures, tasks and the like, and not static nesting, like packages.
> 
> The reason for the rule is to avoid dangling references.  If you were
> allowed to write "type T2 is new T1 with ..." inside a procedure, where
> T1 is outside, then it would be possible to create an object whose tag
> is T2'Tag that outlive the procedure.  And then, after the procedure is
> gone, call something inside it, which might reference something in that
> long-gone procedure.  Bad news.
> 
> The fact that this rule applies to controlled types is to some extent an
> artifact of the fact that controlled types are defined by saying "is new
> [Limited_]Controlled", rather than by some special syntax.  And *this*
> language design decision was made to simplify implementation (and
> language description).  We don't need all kinds of special semantics
> about controlled types -- most of it follows from the normal rules for
> type extensions.  Part of the issue is that the implementation can call
> Finalization without constructing some more-inner context for that call.