Re: Run-time accessibility checks (was: Construction initialization problem)

["Randy Brukardt" <randy@rrsoftware.com>]

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote

> My solution is inheritance, disliked so much. If you want
> a referential type to be a substitute for the target type, then the 
> referential
> type simply must  inherit to the target. (We don't need "all", though it 
> can be preserved using some intermediate referential type.)

Well, this doesn't make any sense to me at all. And the following example 
doesn't help; you've made it the *same* type, which is definitely not what 
you want. The result of dereferencing an access value is a *different* type, 
with *different* operations. I don't *want* interchangability!!

...
> Because Ref_Type is not abstract, you will have to override all primitive 
> operations of Target_Type, and assignment must be a primitive operation, 
> and components getter/setters of, in case Target_Type were a record type, 
> must be as well.

That sounds like a maintenance headache (any change must be replicated 
everywhere. That became such a pain for the Claw Builder program that it 
almost ground development on it to a halt.)

...
>> You certainly can't have a procedure ":=" to do assignment in because of 
>> discrimant-dependent components.

> ":=" is a statement. What I would do is to define *two* primitive 
> subprograms the compiler will use in order to compose *one* ":=". The 
> first operation will determine the discriminants, the second will continue 
> with those known.

That's not the problem; the problem is that components appear and disappear, 
and there is no way to assign them. And there is no way in Ada to just set 
the discriminants without giving values to the components as well; that is a 
fundamental invariant of the language which I don't think can be changed 
without making everything erroneous.

...
> Records are not iterated. If we want a container to support iterations, 
> that must be an abstract array. It also was getter and setters:
>    function "()" (A : Abstract_Array_Type; I : Index_Type) return 
> Element_Type is abstract; procedure "()" (A : in out Abstract_Array_Type; 
> I : Index_Type; E : Element_Type) is abstract;

That's not flexible enough for iteration; the index can be anything (it need 
not have an inherent ordering; it surely cannot be restricted to a discrete 
type) and thus just having this interface does not allow iteration.

There also is very little chance of such an interface being supported in 
Ada, if I read the feelings of the group well enough. One concern I've heard 
is that there is no practical way to support this for slicing (again, 
because the index does not necessarily have ordering). Personally, I'd give 
up slicing for this sort of abstraction, but I don't think that will fly.

Another concern is that almost all of the existing predefined packages would 
have to be scrapped and replaced to make any use of this (especially the 
string packages). But people aren't willing to do that ("insufficiently 
broken"), even if there is plenty of evidence that we could do a lot better 
for those packages.

>> And it also isn't very flexible -- where does the Cursor of a container 
>> go??

> To me to the recycle bin. *BUT* there is no any problem with cursors, 
> absolutely. A cursors is a pair. The first component is a type derived 
> from the container's interface (a reference to the container), the second 
> component is the container's index. Done!

The cursor is the index in the model you have here. And it already is a pair 
(container, access to something). Not sure what you dislike about them; 
they've have the same semantics if not the same name. (I was talking about a 
record selector interface, which makes more sense for getting individual 
elements.) What *cannot* be the case is that the index is required to be 
some sort of discrete type. That would require a map to translate said index 
into some sort of access to the actual element. But that would be silly, 
especially for map containers (you'd have to go through two maps to find 
anything, and for what??)

But the real problem in all of these things you've suggested is that they 
are all technically by-copy for reading. If that is all you want, the 
existing Ada containers do that just fine. The problem is that if the 
elements are large, copying them may be very expensive, so a by-reference 
access method is reading. That's the core of the problem I'm trying to 
address (because I think there is a chance that people will view it as 
significant enough to deal with). Functions returning values of a type *do 
not* provide any solution to that (and cannot).

                                        Randy.