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

Ray,

I'm not quite sure whether you are suggesting that
    randomize with () { ... }
be needed for the "item." form or whether you wanted to
retain the implicit switch to "item." semantics when "item."
was used.

I'm slightly leaning towards wanting the "()" to be required
to cause the rule switch -- I am a bit concerned about
having to re-examine decisions due to a later implicit change
in the rules due to the simple appearance of "item.".

Gord.



Ryan, Ray wrote:
> I agree with Jonathan and Gord that this must be fixed and agree with
> Gord that there is only a minor (acceptable) compatability issue with
> the 'item' syntax. 
> 
> I'd be OK with [7], although it might be useful to allow the "(thing)"
> to be optional and default to "(item)". 
> 
> - Ray
> 
> 
>> -----Original Message-----
>> From: owner-sv-ec@server.eda.org 
>> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Vreugdenhil, Gordon
>> Sent: Tuesday, October 23, 2007 6:49 AM
>> To: Jonathan Bromley
>> Cc: sv-ec@server.eda.org
>> Subject: Re: [sv-ec] Re: Feedback from Freescale on name 
>> resolution issues
>>
>>
>>
>> Jonathan Bromley wrote:
>>> I'm continuing to worry away at this (name binding in inline 
>>> constraints) because I believe we have a fairly important usability 
>>> problem here, and a real opportunity to resolve a good fix.
>> [...]
>>
>>> (7) seems to me to be a useful compromise.  It could also be 
>>> retrofitted to the array-method syntax, allowing users to 
>> work around 
>>> a (much less problematic) name conflict that can exist 
>> there with the 
>>> current "item" syntax.  And it has the advantage that it is a 
>>> completely different syntactic form than the present one, clearly 
>>> flagging the different behaviour.
>> I would be Ok with this syntax although I don't really think 
>> it is necessary.  If "item" is being used as a class member 
>> then "item.item" works and is such a unique special case that 
>> I really don't think that it would be that confusing, 
>> particularly if the LRM addresses it directly.
>> There is the minor backwards compatibility issue but I really 
>> don't think that alone requires us to make the change to (7).
>>
>> In any case, I agree with Jonathan that this really must be 
>> fixed, so I'd certainly support either "item." or the 
>> proposal in (7) above.
>>
>> I also agree that the ".name" form would be far too error 
>> prone and easily misread and I would object to that syntax.
>>
>> 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.
>>
>>

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