Re: [sv-ec] Multiple Inheritance Proposal

Tipp, Brandon P wrote:
> Thanks for the clarification. That changes things a quite a bit in my mind. Let me ask, would examples 1-4 be legal if you were extending a parameterized (virtual) class? The answer should be exactly the same for implementing a pure virtual class.

Well, in class extension they would be legal. But I'm not sure
that I buy your contention that the same answer applies to
"implements". In class extension, you are hiding an inherited
member; in implements you are satisfying a contract specification.

>
> I agree with Tom that example 5 feels like a collision since inside class myA the value of p is ambiguous, but I can see why there could fair case to be made to allow example #6. For example, if there were two pure virtual classes, both of which have an "ADDR_WIDTH", you should be able to implement both pure virtual classes within one derived class as long as the value of ADDR_WIDTH is the same between the interfaces. Given my original definitions, both of these cases would be collisions.

Why should 5 be any different? Unless you want to claim
that implements and extension happen "simultaneously", one
will "win" the name ordering and hide the other. If you
think this is a collision, I definitely want to know the
rule under which that is made since the repercussions of
any such rule will be significant.

> Perhaps an exception should be added?

You seem to be hinting that in order to define implements
that we'd have to inspect parameters (types, values, etc) and
see if they were sufficiently equivalent in order to allow
the multiple implements to occur. That seems to be extremely
fragile to me in terms of when/how things would work in
SV in the presence of parameters that adopt types from their
overriding values.

Java resolves a bunch of these questions by way of a number
of restrictions and very clear rules regarding visibility
and the use model when collisions occur. Fundamental to
this model is that generic Java interfaces do not contribute
their generic parameter names to the implementing class. In
SV some of this is going to be more problematic along several
fronts which is why I've had serious questions about this model.

Here are some basic things to consider:
    1) how would a user be able to implement interfaces from
       two distinct (frozen) IP libraries in the presence of name
       collisions? If that isn't possible, we likely have
       serious long-term problems.
    2) For something like:
         function void some_function (SomeJavaStyleInterface a);
       What is the relationship between a possible parameterization of
       the java style interface and the actuals (i.e. what typing
       rules define contract satisfaction)?
    3) How do parameter propagation requirements in the presence of
       parameterized java style interfaces impact the use model and
       address ongoing concerns about parameter propagation through
       designs?

Although examples are useful to look at, there must be a very
clear model of what the meaning of a "contract" is when you
are talking about Java style interfaces. I am not yet at all
convinced that the complexities of any sufficiently well-defined
model are worth trying to go this route.

I'd suggest looking at examples that are more compositional
in nature. There are many of these that are "traditional" CS
language examples which tend to expose issues and weaknesses
with various models. Some classic examples are "Comparable"
items, iterators, and more interesting structures like
ordered trees (which are composed of comparable items). Getting
those kinds of things to be clean bodes well for the core
language design; having substantial restrictions or assumptions
does not.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.