Re: Making sense of predicates

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

On Wed, 23 Oct 2013 23:03:05 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:9vlzla1igu9w$.1ifys2xkaugrn$.dlg@40tude.net...
>> On Mon, 21 Oct 2013 23:35:59 -0500, Randy Brukardt wrote:
>>
>>> It should be one step (only). We'd need something like co-derivation for
>>> that, which might make sense to pursue someday (the main reason would be 
>>> to
>>> get rid of access types altogether, but to do that you need some sort of
>>> handle, like the container cursor -- and clearly you need to be able to
>>> derive the container and its handle together). But that would be a big job
>>> to define properly, it would take the existing inheritance rules and make
>>> them much more complex. (There are already 3 pages of rules associated 
>>> with inheritance for derived types.)
>>
>> It is not only access types. It is relationships between types: Pointer -
>> Target, Array - Index - Element, etc.
> 
> Yes, of course. The idea is that you'd be able to declare any set of types 
> as "co-tagged" or something like that. (I'm thinking on the fly here, so 
> don't read anything much into the names.) Then they'd have to be derived 
> (extended) together as a group.

The problem going this path is that when you derive from a "co-tagged" type
you most likely have to drop its implementation. E.g. a more specific
handle must replace a wider access type in it with a narrower one. This is
why I always suggested interface inheritance from concrete types. That is,
not a type extension, you inherit primitive operations abstract and drop
the representation.

A way to do it through null extension (though more limited in its
capabilities) is what I did in the original post. That requires a mechanism
of propagation constraints from the type down to its components and a
mechanism of static constraining T'Class to a subclass.

Of course constraints propagation could be a benefit elsewhere. E.g.
consider not null access components. They are mostly useless because the
constraint is on the component's type and thus is enforced too early.
Instead of that if we could attach the constraint to its container and let
it propagate to the component, we could postpone first check until
initialization of the container, e.g. until return from Initialize. Which
will make it possible to initialize such components from Initialize and
cleanup in Finalize.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de