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

From: <jonathan.bromley_at_.....>
Date: Fri May 08 2009 - 08:22:43 PDT
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.
-- 
Jonathan Bromley


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri May 8 08:24:05 2009

This archive was generated by hypermail 2.1.8 : Fri May 08 2009 - 08:24:52 PDT