RE: [sv-ec] Manti 2701, 2514 - response to Tom Alsop's feedback

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Thu Apr 30 2009 - 02:43:13 PDT
On 2514, I wonder about the use of "obligation".

First, 18.5.1 says, 

"Both forms impose an obligation that should be satisfied by providing an external constraint block using the class scope resolution operator".

Afterwards, it says,

"If the implicit form of prototype is used and there is no corresponding external constraint block, the constraint shall be treated as an empty constraint and a warning may be issued."

I'm not sure it is wise to use "obligation," which sounds like a requirement.

18.5.2 says,
"If a derived class has a constraint prototype with the same name as a constraint in its superclass, that constraint prototype shall replace the inherited constraint and therefore shall impose the obligation (as described in 18.5.1) to provide an external constraint block for the derived class."

And

"A pure constraint represents an obligation on any concrete (non-virtual) derived class to provide a constraint of the same name. It shall be an error if a concrete class does not have an implementation of every pure constraint that it inherits."

The use of "obligation" seems a little inconsistent.

It could be a little confusing.

Shalom

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #182, Mantis 2514 ~~~~~
> > [Alsop, Thomas R] I agree with the premise of the proposal, just not
> > with some of the wording as it?s not consistent with the draft8 
> > wording.  Specifically the references to ?concrete type? (Clause 8.
> > 24, third paragraph on page 142). à ?A generic class is not a type; 
> > only a concrete specialization represents a type. In the example 
> > above, the class
> > vector becomes a concrete type only when it has had parameters 
> > applied to it, for example?  But this proposal states ?A pure 
> > constraint represents an obligation on any concrete (non-virtual) 
> > derived class?, defining a concrete class to a non-virtual class. 
> > I?m just unclear about using the wording of ?concrete?.
> 
> Fair enough.  I've always thought of "concrete" as an antonym
> of "abstract" that doesn't need any further glossing, but I take
> your point.  Clause 8.20 consistently uses "non-abstract" to
> describe a class that isn't a virtual==abstract class, and 
> I probably should have used the same form in this proposal;
> again I'll prepare a modified version in the hope that it 
> could be treated as a friendly amendment.
> 
> In my defence (and with my tongue firmly in cheek) I should
> point out that at least I took the trouble to *define* my use
> of the word "concrete", which is more than the draft LRM 
> bothers to do in clause 8.24 .......
> 
> Thanks for the detailed review.
> -- 
> Jonathan Bromley
> Consultant
> 
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * 
> Tcl/Tk * Project 
> Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, 
> Hampshire, BH24 1AW, 
> UK
> Tel:  + 44 (0)1425 471223                       Email: 
> jonathan.bromley@doulos.com 
> Fax:  +44 (0)1425 471573                        http://www.doulos.com
> 
> --------------------------------------------------------------
> ------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International 
> Airport,
>         Christchurch, BH23 6SE, UK. 
> 
> This message may contain personal views which are not the views of
> Doulos, unless specifically stated.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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.
Received on Thu Apr 30 02:46:20 2009

This archive was generated by hypermail 2.1.8 : Thu Apr 30 2009 - 02:46:54 PDT