Re: [sv-ec] Multiple Inheritance Proposal

Tipp, Brandon P wrote:
> I just saw Tom's response, and he had the exact opposite answer that I do because he started off contradicting my first assumption... Is that really how it works in SV? When you extend a parameterized class you still have visibility into the extended class's parameter? I've seen this work in SV:
>
> class B #(T type = int);
> endclass
> class A #(T type = int) extends B(.T(T));
> endclass
>
> I would think that if the parameter T from class B is visible inside class A, then there should be a collision that shouldn't compile today.

No, A#()::T hides B#()::T within A but it does not
collide with it. So references to "T" within
A are legal.

I'll skip the rest until we have understanding on this.

Gord.

>
> See the answers that I was working on below...
> ======================================================
>
>
> Your questions are focused on the visibility of a parameter from a parameterized class by a class which implements the parameterized class. I don't see this as being any different than what already exists in SV. I believe that a class which extends a parameterized class (or parameterized virtual class or parameterized pure virtual class) has no visibility of that parameter.
>
> class myA implements A #(.p(5));
> // there is no visibility of p inside this class
> // therefore myA is free to re-define p
> endclass : myA
>
> If I'm mistaken, and myA has visibility of "p", then that would affect my answers below. See below for answers to your specific examples.
>
>
> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Monday, August 16, 2010 2:40 PM
> To: Alsop, Thomas R
> Cc: sv-ec@eda.org; Tipp, Brandon P
> Subject: Re: [sv-ec] Multiple Inheritance Proposal
>
>
>
> Tom and Brandon,
>
> Thanks for the initial directions.
>
> Just to check my understanding of what you posted, given:
>
> pure virtual
> class A#(p = 1);
> pure virtual function int f();
> endclass
>
> pure virtual
> class B#(p = 1);
> pure virtual function int g();
> endclass
>
>
> It would be impossible for any class to implement
> both a specialization of A and a specialization of
> B since both classes have a symbol (the parameter)
> named "p".
>
> Is that a correct implication of the intent?
> =======================================================================
> [Tipp, Brandon P] I believe that this case should be acceptable. Any class which implements A or B or both will have no visibility into the parameter p, so there is no collision.
>
> The intent of the rule is to avoid collisions with methods (and potentially data members) defined within the class, especially since SV doesn't support method overloading. This restriction is to help simplify eda tools while enforcing what I would consider to be a good coding guideline.
> =======================================================================
>
>
> Essentially it becomes the user's responsibility to make
> sure that all names are distinct between any set of
> classes which participate in an "implements" clauses.
>
>
> As a second question, if a class "implements" A#(5),
> what is the compatibility rule for symbols? For
> methods, I assume that the rules are essentially
> the "overriding" rules, but what about other symbols?
>
> For example, given my defn of "A" above, which of the
> following would be legal (clearly some are not correct
> in terms of intent, but what is legal and what is the
> rule constraining legality):
>
> 1)
> class myA implements A#(7);
> function int f(); return 1; endfunction
> endclass
>
> 2)
> class myA implements A#(7);
> localparam p = 5;
> function int f(); return 1; endfunction
> endclass
>
> 3)
> class myA implements A#(7);
> static int p = 5;
> function int f(); return 1; endfunction
> endclass
>
> 4)
> class myA implements A#(7);
> typedef int p;
> function int f(); return 1; endfunction
> endclass
> =======================================================================
> [Tipp, Brandon P] I think that all of the above should be legal since myA should not have visibility into A::p.
> =======================================================================
>
> 5)
> class myA extends B#(7) implements A#(5);
> function int f(); return 1; endfunction
> function int g(); return 1; endfunction
> endclass
>
> =======================================================================
> [Tipp, Brandon P] This should not compile/elaborate: The rule is that a class may extend 0 or 1 class or virtual class; you cannot extend a pure virtual class. I don't see any problem with this however:
> class myA implements B#(7), A#(5);
> function int f(); return 1; endfunction
> function int g(); return 1; endfunction
> endclass
> =======================================================================
>
> 6)
> class myA extends B#(7) implements A#(7);
> function int f(); return 1; endfunction
> function int g(); return 1; endfunction
> endclass
> =======================================================================
> [Tipp, Brandon P] Same as above for the same reason.
> =======================================================================
>
> I have some additional intent and expectation questions
> but would like to understand the visibility assumptions
> and constraints that you expect first.
>
> Gord
>
>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>

-- 
--------------------------------------------------------------------
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.