Gord wrote:
I suspect (but am not sure) that you are viewing types, parameters,
etc. as being different than methods -- that they are essentially
inherited from the class being "implemented" while methods follow
what I consider to be "constraints" on the final type -- something
that is required to be provided by the implementing class type.
Another (more operational) way of expressing this is that you are in
fact doing inheritance -- you inherit all types, parameters and *method
pointers* via an "implements" and the only thing that a class can do
is "fill in" the method pointers. Is that in fact the model that you
have in mind?
[Alsop, Thomas R] Gord, this is correct. I could be totally wrong in how I perceive this and we can talk about it, but fundamentally what you have described is how I viewed non-method members of the 'implemented' class. So with that perspective I was attempting to see what type of name collisions would occur and what should and should not be allowed, given the parameterized name versus other tokens in the surrounding scope. At least this is what I thought the exercise was that you were asking for. Perhaps you could express how you think these other tokens should be managed when implemented (I'm not even sure how Java interfaces manage this). Then Brandon and I can walk through your exercise again.
Going back to this first question you had Gord and noting what Brandon has said, see my new comments about it below.
> 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.
[Alsop, Thomas R] So my new question about this is what exactly this behavior should be. When a specialization happens (i.e. a parameterized class get instantiated or type with a specific parameter value), I tended to think that if two generic classes with the same parameter name were implemented at the same time, that this should be a collision. However wouldn't this be considered the specialization. In other words, if at the time of the implementation of the two class, that they were specialized too, then there shouldn't be any collisions. However if the specialization was carried over (i.e. hidden) by the class that is doing the implementing, and both parameters do not get specialized, how does this play out. Does that make sense? We may want to set up a time Gord to talk about this. Perhaps we can invite others from the committee to meet to iron this out before the next meeting. At the very least it would be nice for Brandon and I to meet with you and walk through all these special cases and come to an understand of how this would all work.
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.Received on Tue Aug 17 08:59:22 2010
This archive was generated by hypermail 2.1.8 : Tue Aug 17 2010 - 08:59:26 PDT