Constructors

[Peter Morris [Droopy eyes software]]

This is what Anders says

=====
The problem with Delphi's model (allowing constructors to be called on
an already constructed object) is that it makes it impossible to have
provably immutable objects. Immutability is an important concept because
it allows applications to hand objects to an external party without
first copying those objects and still have a guarantee that the objects
won't be modified. If constructors can be called on already constructed
objects it obviously isn't possible to make such guarantees. In Delphi's
case that may be ok since Delphi doesn't really make type safety
guarantees anyway (you can cast any object reference to a
pointer-to-something and start poking away), but .NET goes further with
type safety and this would be a big hole.
=====

I'm not sure I agree though. If C# can stop me from modifying a readonly
member outside of a constructor then surely it can also prevent me from
calling a base constructor too?

"Chrome" (http://www.chromesville.com) will apparently let you call the base
constructor at any point you wish and the constructors are still not
accessible from standard methods.

Am I missing something in this reply? I don't think I am but you never know



Pete

 

[Peter Morris [Droopy eyes software]]

hehe, thanks for the info

 

[Barry Kelly]

=====
The problem with Delphi's model (allowing constructors to be called on
an already constructed object) is that it makes it impossible to have
provably immutable objects. Immutability is an important concept because
it allows applications to hand objects to an external party without
first copying those objects and still have a guarantee that the objects
won't be modified. If constructors can be called on already constructed
objects it obviously isn't possible to make such guarantees. In Delphi's
case that may be ok since Delphi doesn't really make type safety
guarantees anyway (you can cast any object reference to a
pointer-to-something and start poking away), but .NET goes further with
type safety and this would be a big hole.
=====

I'm not sure I agree though. If C# can stop me from modifying a readonly
member outside of a constructor then surely it can also prevent me from
calling a base constructor too?

"Chrome" (http://www.chromesville.com) will apparently let you call the base
constructor at any point you wish and the constructors are still not
accessible from standard methods.

Am I missing something in this reply? I don't think I am but you never know

I'm not sure the answer given is an answer to the question that needed
asking...

It's not about third parties invoking constructors on
already-constructed objects (that's a weird feature to use anywhere, let
alone allow in a safe language / runtime), but rather having discretion
about when to call the base constructor, no?

The CLI certainly permits some discretion about when to call the
constructor, but it does require that exactly one base constructor be
called, and it must be called before any access to inherited instance
data. Not everybody was happy about this - the annotated CLI standard
has some comments from the Eiffel team about this.

-- Barry

 

[Laura T]

Some negative effects come in my mind using non automatic base construction.
One is that you can operate on objects that are still "pending" of
construction.
The derived objects could modify the parent's state (not field initialized)
in a non predictable way.
The base object's constructor usually assumes a predefined state of it. If
derived objects
are allowed to change this assumption it might break the parent's
initialization/destruction.
Also if the code before base constructor has exceptions, what will be
unwound.
The parent objects finalizer should be but the object is not "constructed"
yet.

There are ways to make it, but wouldn't it be a bit too fragile to manage
the different paths?
IMHO, always.

 

[Laura T]

Strange.
(btw, its Hejlsberg, not Heljsberg).

 

[Peter Morris [Droopy eyes software]]

I'm not sure the answer given is an answer to the question that needed

asking...

I believe this is the case too. I had to read through the answer 2 or 3
times because I didn't understand it. The final time I just thought to
myself "I can't see the answer to my question".

 

[Larry Lard]

I'm not sure the answer given is an answer to the question that needed
asking...

It's not about third parties invoking constructors on
already-constructed objects (that's a weird feature to use anywhere, let
alone allow in a safe language / runtime), but rather having discretion
about when to call the base constructor, no?

Well, if you call the base constructor after you have already started
your own construction work, presumably that's "invoking a constructor on
an already constructed object" ?

But then I don't really understand the subsequent stuff about immutability.

 

[Barry Kelly]

Well, if you call the base constructor after you have already started
your own construction work, presumably that's "invoking a constructor on
an already constructed object" ?

No, because the object isn't constructed until the constructor of every
base class has been called.

But then I don't really understand the subsequent stuff about immutability.

For example, strings in .NET are immutable, and for good reasons -
permits maximal sharing since one can avoid copying unless one wants to
change the string. If you had a string class like this:

class String
{
char[] _data;

public String(char[] data) { _data = data; }
}

.... and any arbitrary third party could call the constructor on an
already-constructed object, they could change the data:

myString.String(new char[] { 'f', 'o', 'o' });

-- Barry

 

[Peter Morris [Droopy eyes software]]

My conclusion to this entire scenario is this

1) DotNet itself is capable of doing this without problems
2) C# cannot do it

therefore I can only conclude that this is one of the very few things in C#
that I think are not implemented well at all. What a shame, so pointless
too!


Pete