Re: [sv-ec] RE: id 185, svdb 2342 static constructor

Arturo,

I really appreciate the feedback.

In terms of the static construction side, I don't see
the current change as being a "we'll never have any form
of static constructor semantics" but rather that we can't
define it in this PAR and we're protecting that form from
any ambiguity with the current constructor semantics
by making it illegal.

I'll try to get an initialization proposal written up and
into Mantis.  I'll send it out early for review to make
sure that we're all in agreement on the details.  Given
that we have conceptual consensus, I think that we should
be able to get the details right.


Thanks!

Gord.

Arturo Salz wrote:
> Gord,
> 
> In view of all the confusion caused by my comments, I withdraw my objection and switch my vote to yes.
> 
> BTW, I was trying not to shut the door on static constructors. Some languages support this special type of constructor to explicitly initialize static members even before creating an object of a particular class. C++ has a very clumsy mechanism for initializing static class members and SV relies either on the regular constructor or (like C++) explicit assignments using the class resolution for each static variable. Neither mechanism is OOP-like nor particularly good. It seems that a static constructor - which is indeed static and has no access to "this" although it mat have access to the static super-constructor - would be a good construct to have.
> 
> I realize that a static constructor would be a completely different type of beast - and certainly an enhancement that's outside the scope of the current LRM, but I was concerned that Dave's proposal would shut the door on such a mechanism. That is, live with the extant ambiguity and later associate an explicit semantic to a static constructor. I realize now that it's best to make it explicitly illegal and perhaps review the enhancement later.
> 
> Regarding the initialization ordering, I have reviewed your proposal and carefully read Steven's arguments. I have to admit that I find the arguments compelling and favor a change to the prescribed semantics. In my earlier comments I was simply trying to document the semantics of our implementation, but I recognize that threading initializers and constructors per class is a better semantic model and will support your proposal. This does leave us with a backward compatibility issue, but I hope it's not too severe as I expect these dependencies to be corner-cases that actual code does not rely on.
> 
>         Arturo
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Friday, May 08, 2009 9:49 AM
> To: jonathan.bromley@doulos.com
> Cc: SV_EC List
> Subject: Re: [sv-ec] RE: id 185, svdb 2342 static constructor
> 
> Jonathan,
> 
> I didn't really think that you expected "this"
> to be illegal.  But it does make it clear that
> "new" is a different kind of thing.  It really
> is neither static nor automatic -- it follows
> constructor rules.  So let's just not allow
> static/automatic.  Explicit use of either is
> very confusing; "new" is a constructor and
> follows its own slightly different rules.
> 
> BTW, on the initialization ordering, please
> see:
>     http://www.eda.org/sv-ec/hm/6609.html
> 
> I disagree with your proposed ordering and
> have explicitly discussed that variant in
> that post.
> 
> Gord
> 
> 
> 
> jonathan.bromley@doulos.com wrote:
>> Gord,
>>
>>> So are you implying that the use of "this"
>>> in a constructor is illegal?
>> No, no!  Of course the constructor code MUST know
>> about "this", a reference to the object that has
>> rather recently been allocated and with whose
>> contents the constructor code is busily messing.
>> I was trying to play devil's-advocate and point out
>> that new() most certainly is not an ordinary method.
>> For example, I'm sure you would object strongly if
>> I tried to do the following:
>>
>>    C c = new();  // create and initialize c
>>    c.whatever(); // do something to c's contents
>>    c.new();      // reset c to its initial state (!!!)
>>
>> So the rules for new() must, whatever, be special.
>> Consequently, whether new() is static or not is
>> really splitting hairs, isn't it?  And I apologize
>> that I was guilty of continuing to split those
>> hairs, unnecessarily.
>>
>> We have precisely two forms of call to new(), don't we?
>>     handle = new(...);
>> and
>>     super.new(...); (whether implicit or explicit)
>>
>> The first of these:
>>   - allocates and default-initialises the new object
>>   - runs explicit initializations on member variables
>>   - runs the user constructor code
>>   - returns the value of "this"
>> The second form...
>>   - only runs the user code????
>>
>> Given this limited set of possibilities it shouldn't
>> be too hard to write a bunch of rules that say exactly
>> what each does, including rules about the constructor
>> arguments and so on.  As I've said before, speaking as
>> a user I'd be happy to accept ANYTHING realistic here;
>> I don't much care about the relative merits of existing
>> languages, but I do care a lot about clear definition,
>> portability, and freedom from obscure corner cases.
>>
>> The initialization sequence that I personally think
>> would be easiest to understand is....
>>
>> 1. allocate the whole derived-class object
>> 2. default-initialize all its data members
>> 3. run explicit data member initializers,
>>    deepest base class first
>> 4. call user constructor for the derived
>>    class; since that calls super.new as its
>>    first statement, that means user constructors
>>    also get executed in deepest-base-first order,
>>    but it means that constructor arguments get
>>    evaluated in most-derived-first order.
>>
>> But if there are good reasons for doing something
>> different, I would not argue with them.
> 
> --
> --------------------------------------------------------------------
> 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.