Re: User-defined type attributes

"Eric Hughes" <eric.eh9@[EMAIL PROTECTED]
> wrote in message
news:c6b7e0b5-6b81-486a-8054-becd0df9842b@[EMAIL PROTECTED]
> Tagged types do work better, sure.  But they're not a panacea,
> either.  It would a mistake to address other difficulties with types
> by shoehorning "solutions" to them into tags.  And in the last couple
> of days I've realized the problems with untagged types as formal
> parameters is much greater than the absence of dot-notation.
>
> So here's a brief example.  I'm writing a smart accessor package set
> right now.  As something of an exercise, I'm doing this as generically
> as possible.  So I'm looking to write code that can use both intrusive
> (part of the managed object) and accretive (separate from the managed
> object) allocation strategies for reference counts.  And I want to do
> it without making the accessor types tagged.  Since an intrusive
> accessor is simple a wrapped-up access object, adding a tag would
> double the machine size of an object.  I consider this a poor result
> for a system-level library.
>
> My first foray at solving this was to use a formal type parameter for
> the implementation of the accessor.  The intrusive implementation
> would contain just an access object; the accretive one would have that
> plus an access to a reference count.  Pretty simple, so I thought.
> But without using a tagged type in the formal parameter definition,
> there's no visibility either for record components or for implicit
> visibility of operators on that type.  Thus I couldn't get at
> components either directly or indirectly.  I discarded that approach.
>
> It's a shame really, because it would otherwise be a natural
> representation of variety of in possible implementations.  I'm still
> looking at other ways of approaching the problem.  I'm beginning to
> suspect that doing this may be impossible, but I don't have an
> argument yet.

In cases like these, you have to pass accessor routines explicitly.
Something like:

generic
     type T is private;
     procedure Increment_Count (Obj : in out T) is <>;
     function Count (Obj : in T) is <>:
     ...
package Whatever is ...

Note the use of <> in these formal subprogram declarations. It gives a
default for the subprograms such that a routine with the right name and
profile automatically matches. (Why you can't have such defaults for types
is unknown by me...) This makes the instantiations less annoying (but you
do
need to declare the appropriate routines somewhere).

You can wrap these things up and use them as formal packages if they are
common, so you don't necessarily have to end up with lots of generics with
a
hundred parameters.

I would prefer to use an interface or tagged type here, but obviously you
can't do that. This is not a perfect solution, but it works and is
commonly
used.

                                  Randy.