Re: [sv-bc] SV_BC #26 - Enumerated Literals in Packages - Feedback Requested

From: Clifford E. Cummings <cliffc@sunburst-design.com>
Date: Mon Nov 29 2004 - 12:21:07 PST

Hi, All -

I don't have very strong leanings either way on this one. I just accepted
the assignment and made a first-cut proposal.

Changes to this proposal will not offend me :-)

At 10:30 AM 11/29/2004, Greg Jaxon wrote:
>I don't see why the importation of an enumerated type also
>needs to import its literal labels. They are separate names
>and no one explicitly asked to have them imported.
>
>On the contrary, when you used the wildcard import, you
>explicitly renounced responsibility for what things matched
>that wildcard, and so you got all names which the package
>defines.

I built examples for all of the entires of Table 18-1 to better understand
the ::* impact (BTW - the table is not the clearest set of examples (fully
coded examples would have helped), although it is more concise than
elaborating all of the examples - I had to elaborate and create my own
examples for each table entry to really understand the intent.

Row 3, columns 4 -6 seem to address the visibility achieved by the ::*
inclusion. These table entries seem to indicate that the package
declarations may potentially be included if later called within the module.
These are the key examples that spurred me to form the proposal that I sent.

>So I think your examples are generally backward.
>
>module tmp1d;
>import p::bool_t;
>import q::teeth_t;
>
>This is not an error! This module may create new objects of the
>imported enum types and pass them off to (packaged) entities. The
>types may be compared and queried.
>
>module tmp2d;
>import p::*;
>import q::teeth_t; // OK
>teeth_t myteeth;
> initial begin
> myteeth = FALSE; // ERROR, FALSE is a direct reference to p::bool_t::FALSE
> // which was imported by the wildcard syntax.
>
>module tmp3d;
>import q::teeth_t;
>typedef enum ( TRUE, FALSE ) story_t; //OK FALSE has no previous meaning.

Again, I tried to make these examples consistent with the Table 18-1
entries. If I am mistaken, feel free to modify my proposal as appropriate.

Regards - Cliff

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training
Received on Mon Nov 29 12:23:50 2004

This archive was generated by hypermail 2.1.8 : Mon Nov 29 2004 - 12:23:57 PST