Implicit class construction, _cast() and `=()

Do you mean that this:

SomeObject o; ... o = 17;

should be rewritten to:

SomeObject o = <magic unassigned value>; ... if (o == <magic unassigned value>) o = SomeObject(); o->`= (17);

? If so, I have two objections:

1. The runtime overhead to check for the magic unassigned value before essentially every assignment is a bit too expensive for this feature.

2. Assignment operates on the variable, not the value in it. That's a sound rule which overall makes it a lot easier to reason about variables and values. If it's violated we'll probably get odd bugs which will be variants of this example I gave a while back:

object x = a_fishy_object; ... x = a_nice_object; if (x->is_fishy_object) { werror ("Foo?\n"); x = 0; // Begone! if (objectp (x) && x->is_fishy_object) { werror ("Arrgh!\n"); destruct (x); // Die, sucker! } }

In which situation would it be really useful to have an assignment operator? Would you be able to control it? I mean, even if you're aware that you're handling an object that behaves as above, wouldn't you find it difficult to not be able to assign values to the variables themselves?

/ Martin Stjernholm, Roxen IS

Previous text:

2003-05-06 04:22: Subject: Implicit class construction, _cast() and `=()

---

Hi everybody,

This topic was discussed once here, but...

Why _cast() is called only for builtin data types? When I do:

(int)something;

then something->_cast("int") gets called, but when I do

(SomeType)something;

then SomeType(something) gets called? I just can't understand why, it seems a bit unlogical (if there is some logic behind - please explain). Additionally, there is no way to distinguish between regular constructor call and when type is casted...

And concerning assignment operator overloading. I believe that this will be very useful feature, and it should not be [too] difficult to implement. Well, there will be some problems when target (lvalue) may have more than one type, but in case when it is not multi-type, it should be quite simple.

So... If, and only if, the object (class) defines `=() and ``=(), then:

• If variable is of type SomeObject, and it is undefined, the function ``=() will be called and it should play constructor's role (we can't simply call constructor here since in this case we can't distinguish between regular constructor call and a call from assignment).

• If variable is defined and contains object of type SomeObject, then the function `=() will be called.

When there is ambiguity, standard behavior should be used (or exception raised, or compiler error, etc).

This way, IMHO, we can keep compatibility, and use very nice and useful feature same time.

Any opinions, suggestions, idea, flames? :)

Regards, /Al

/ Brevbäraren