Re: [sv-bc] enumerated variable used with an equality operator

if packages are not enough maybe smth like namespaces needed?

DANiel

W dniu 3/26/2014 10:42 AM, Bresticker, Shalom pisze:
>
> A particular case we had recently was where someone wanted to declare 
> two enum types that were variations of each other, and did not want to 
> have to rename all the names that were the same.
>
> *From:*Daniel Mlynek [mailto:danielm@aldec.com.pl]
> *Sent:* Wednesday, March 26, 2014 10:01
> *To:* Bresticker, Shalom
> *Cc:* Greg Jaxon; sv-bc@eda.org
> *Subject:* Re: [sv-bc] enumerated variable used with an equality operator
>
> IMHO current behaviour that 2 enums cannot have same enum labels is 
> ok, also strong type checking only for assigning to enum is ok.
>
> I think that there can be many arguments to support my point of view ie:
> -  it is bad idea to deliberately define the behaviour of features 
> well known  in programing in the opposite way that it is defined in 
> other languages like ie C++.
> - it is not good idea to use same label in 2 enums - different enums 
> should describe different types so why they has to have same names
> - If user really wants to have 2 enums with same enum label he can 
> define them in different scopes ie packages.
>
>
> DANiel
>
> W dniu 3/26/2014 8:43 AM, Bresticker, Shalom pisze:
>
>     In a somewhat similar vein, there is sometimes a problem with two
>     enum type declarations that use the same value names.
>
>     Example:
>
>     typedef enum { A, B, C } e_1 ;
>
>     typedef enum { C, D, E } e_2 ;
>
>     Currently you get a fatal syntax error on multiple declarations of C.
>
>     I would like to propose that a case like this be treated like
>     importing packages.
>
>     That is, you would not be able to reference C directly, but you
>     would be able to write e_1::C.
>
>     Shalom
>
>     *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>
>     [mailto:owner-sv-bc@eda.org] *On Behalf Of *Greg Jaxon
>     *Sent:* Friday, March 21, 2014 20:37
>     *To:* sv-bc@eda.org <mailto:sv-bc@eda.org>
>     *Subject:* Re: [sv-bc] enumerated variable used with an equality
>     operator
>
>     ISO-C 5.5 holds that two enum types are always distinct.
>     Following tradition, if Verilog has the same syntax as C, it must
>     take on a different meaning.
>     To appeal to folks who believe in this guiding principle, I can
>     offer them this suggestion:
>     The enum label exported to the declaring scope will be strongly
>     typed (C-like), but if you select it
>     directly out of the enum scope itself, it will be weakly typed.
>     Thus |TRUE == FALSE| would be a type-mismatch /error/ in a scope
>     where these were labels of distinct enums,
>     even though |BLUE::TRUE == TEETH::FALSE| would be legal, and
>     perhaps true.
>     There, is that different enough from C so the pain of matching it
>     elsewhere is diminished? ;-)
>
>     On 3/21/2014 12:16 PM, Brad Pierce wrote:
>
>         Enum types should be 100%-strong with the base type encodings accessible
>
>         via an enum method as inhttp://www.eda.org/svdb/view.php?id=4887  .
>
>           
>
>         Such a method would still be useful even if weak enum typing must be
>
>         preserved for legacy reasons.
>
>           
>
>         Replying tohttp://www.eda.org/sv-bc/hm/11537.html  .
>
>           
>
>         -- Brad
>
>           
>
>           
>
>           
>
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>
>     ---------------------------------------------------------------------
>     Intel Israel (74) Limited
>
>     This e-mail and any attachments may contain confidential material for
>     the sole use of the intended recipient(s). Any review or distribution
>     by others is strictly prohibited. If you are not the intended
>     recipient, please contact the sender and delete all copies.
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.