[sv-bc] Feedback from Freescale on name resolution issues

From: Michael Burns <michael.burns_at_.....>
Date: Fri Oct 12 2007 - 12:54:56 PDT
Hi sv-ec and sv-ac,

Here's some feedback from Freescale on the name resolution issues w/ opaque 
types raised in the face-to-face meeting a few weeks ago. I believe the vendors 
were asking for some direction from users - I hope this helps. We address three 
areas - "randomize() with" on opaque type objects, deriving from opaque type 
classes, and the overall issue of static vs. dynamic typing.

For constraints in "randomize() with" on opaque type objects, we feel that the 
binding rules on simple names are scary enough that we just won't use them - 
we'd rather use our internal coding standards to mandate explicit disambiguation 
either into the opaque type object being randomized or into the enclosing 
lexical scope. As long as the LRM provides for disambiguation, we don't see the 
need to make any LRM changes to address this issue.

We aren't as interested in deriving from opaque types - not because it isn't 
useful, but simply because we don't see it being implemented widely enough soon 
enough to be on our radar yet. We would use this feature if it were available, 
but we aren't pushing it. We would not want to see a delay in the standard to 
straighten it out, but would expect to see it working properly in the next 
revision (if it isn't working already today, which isn't yet clear). We would 
expect the name resolution to work as it appears to today - preferentially into 
the opaque base class. We would avoid unexpected name binding by using internal 
coding standards to prevent the use of simple names in the enclosing lexical 
scope that are also expected to be present in the opaque base class.

Overall, we are interested in the robustness of static typing and would like to 
know more about Mentor's proposals for "specs" for type parameters, but again, 
we aren't in favor of delaying the standard to get it included this time around.

--Mike Burns
   Freescale


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Oct 12 12:55:24 2007

This archive was generated by hypermail 2.1.8 : Fri Oct 12 2007 - 12:55:34 PDT