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

Hi again folks,

It turns out that there is a case where it is not possible to disambiguate the 
simple name reference in a "randomize() with" - when the lexical scope contains 
locals/automatics, there's no way to explicitly say that you intend a name to 
bind to the local rather than into the opaque randomized object.

This clearly seems dangerous, and I can't see any way in the current standard to 
protect ourselves from it without resorting to annoying, fragile naming 
conventions. Does anyone have a good solution? If there isn't a good way to deal 
with this using what we have, I'd like to see a fix added in the 2008 standard.

Thanks,
--Mike

Michael Burns wrote:
> 
> 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.