I don't think that further restrictions are necessary since there are already semantic restrictions that the extern must exist in the same scope as the class declaration. So <..>::<..>:: would not be legal in any case. I didn't deal with the specialized form since that isn't restricted in the method form either (and makes no sense in either context). The "class_scope" prefix is exactly what is currently done for the method name prefixed form as well. The other semantic rule suggestion applies to the method prefixed form as well; if you'd like to suggest that for both, that would be fine, but it isn't clear to me that it is needed. Gord. Brad Pierce wrote: > Gord, > > Your current proposal for > > http://www.eda.org/svdb/view.php?id=1857 > > would add [ class_scope ] to function_declaration and task_declaration, > yet gives no examples that require the full generality of [ class_scope > ], such as > > C#(5)::C2#(int)::function ... endfunction > > If all you really intend to allow is > > [ class_identifier :: ] > > then better to use that instead of [ class_scope ]. > > Also, it might be good to add a footnote to the BNF saying that in a > task or function declaration, these new prefixes can be used with the > 'task'/'function' keyword only if the declaration is completing an > extern declaration of a class method. > > There is missing bolding on the keywords in the examples for 8.24. > > -- Brad > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Gordon Vreugdenhil > Sent: Monday, June 11, 2007 8:20 AM > To: SV_EC List > Subject: [sv-ec] Proposal for extended syntax for extern methods of > parameterized classes > > I've added Mantis 1857 and attached a proposal. The key issue is how to > specify function return types in extern method definitions of > parameterized classes. The proposal describes what the consensus > solution seemed to be -- to allow "class_name::function" when defining > an extern method in addition to the "function return_type > class_name::method_name" form. For symmetry, class_name::task is also > permitted. > > Gord. > -- > -------------------------------------------------------------------- > Gordon Vreugdenhil 503-685-0808 > Model Technology (Mentor Graphics) gordonv@model.com > > -- -------------------------------------------------------------------- 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.Received on Mon Jun 11 09:17:15 2007
This archive was generated by hypermail 2.1.8 : Mon Jun 11 2007 - 09:17:36 PDT