Anders Hejlsberg comment on immutable objects

[Magnus Lidbom]

On Mon, 9 Feb 2004 20:45:50 -0600, "Daniel O'Connell [C# MVP]"

Yes, I know what the purpose of the feature is It is also useful
for the ability to implement an internal interface. But neither of
these uses would replace an implicit implementation with an explicit
one. My point was that such a replacement is a fundamentally flawed
design that makes it impossible, even in theory, to know in a generic
fashion how to call the method in order to access the correct method.
There simply is no correct method. Given this, I wouldn't cast to an
interface unless it was emplicitly implemented for the class in
question. Of course, I'd have no choice in that situaton

Unfortunatly, there are alot of situations where an explicit implementation
may have been chosen. I try to work with interfaces as interfaces(actually
try to never see anything but the interface, but factories can't always
solve the problem). Most of the time I work with interfaces explicitly,
trying to avoid concrete types(I do alot of plugin\loosely coupled systems).
So my casts to interfaces are done at a rather low level, usually casting
from object using as. It works fairly well, IMHO.

I've been arguing against using unnecessary casts. For a plugin
architecture, there is no choice, that I know of, somewhere you will
have to cast to the interface that the plugins implement. As long as
this is done only in the appropriate part of the subsystem that sets
up the plugins, I see nothing wrong with it.

I think readonly would fit here better. readonly const MyStruct myInstance.
readonly already restricts access to a reference to only a constructor for
fields, in a method it could be limited to declaration or perhaps a readonly
block:

readonly
{
readonly const MyStruct myInstance;
myInstance = new MyStruct();
}

This isn't nessecerily the same thing, more complicated structures like
point have fields that can be set, properties and methods that can be
called. Some of these properties and method are const, some are not. In
these cases changing the entire structure is a different matter than
changing certain fields.

But that's my point, there is no meaningful difference. The variable
is the instance There are no references, except when using ref or out,
to value types. If const above means no field may be modified, then it
also means that the entire instance may not be replaced, because that
would replace all the fields. The variable, the instance, and the
instance's fields, are all one and the same, they occupy the same
memory. Accordingly, you only need one. Readonly or const.


<snip>

/Magnus Lidbom

 

[Kamen Yotov]

<snip>

not

a defined

The spec here is using the word conversion (in conjunction with reference,
as in "reference conversion") literaly.
Magnus, the "conversions" you are talking about are simply "casts" in
Daniel's mind.
As he says, casts do not change the value of the object casted.
The conversions Daniel refers to are those, defined with a conversion
operator in C#:

public static implicit operator T1 (T2 v)
{
...somehow convert the object v from type T2 to T1, pottentially
creating a new object...
}

Excuse me if that was clear to both of you, it might very well have

been.

In
that case, please ignore this message.
Just trying to help...

This is pretty much waht I mean, conversion operators.

On a sideline, I have to disagree with Daniel on the usefullness of
conversions.
Conversions (and especially implicit ones) are invaluable asset in C#, one
of the things that makes it far more expressive than Java.
I agree there is dark side to them in the sense that for someone might not
be obvious what is going on, but still, I think the benefits are well worth
it.

I dislike implicit conversion operators, mainly because they are unapparent.
I would have no problem with explicit conversion operators if they didn't
use the cast operator, instead opting for different syntax. The cast and
implicit conversions make it to hard to determine exactly what is going on.
I also have issues with the way operators work, being static they are
unreliable, I simply don't care for them.

Well, I am glad you are not on the C# design team
Again, it is almost always apparent what you want to do in Java, but to
maintain this apperentability, the expressions are more complex than they
should be (well, at least more complex than I am willing to tolerate).
Now that Java 1.5 has boxing and generics, can you please tell me what is it
that will make *YOU* prefer whidbey instead of java 1.5?

 

[Daniel O'Connell [C# MVP]]

<snip>

message news:%[email protected]...

Well, I am glad you are not on the C# design team
Again, it is almost always apparent what you want to do in Java, but to
maintain this apperentability, the expressions are more complex than they
should be (well, at least more complex than I am willing to tolerate).
Now that Java 1.5 has boxing and generics, can you please tell me what is it
that will make *YOU* prefer whidbey instead of java 1.5?

Well, as a whole mainly that I am not particularlarly fond of java. I've
used it several times and while the language itself is fine, the IDE's and
many of the libraries\design decisions leave alot to be desired. I dislike
the java implementation of generics(as I understand them), dislike the java
event system(is that changing in 1.5?), dislike not having valuetypes,
dislike not having unsafe code(use it rarely but I like having the option),
dislike the hoops required to interop with non-java code(I use vb.net to
work with office now and then). I consider java naming conventions to be
aimed at obfustication. If I wanted to try, I imagine I could come up with
more, however I think you've got my point.

My argument against implicit conversions is that they are abusable and in
*almost* every case they are used they are abused. I do see their value, in
mathematics and other small domains, however as a whole I'd rather see
explicit conversions(using a different operator, convert<int>(x) for
example, even if it is a touch more complex, however in math it would be
annoying(I would rather cast a long to int rather than use a conversion
operator, in almost every other case I'd rather see the conversion. Such
rules make things too complex in and of themselves though.). Operator
overloading is tricky IMHO. I am not entirely sure what I'd like to see, if
I'd prefer polymorphic, instance based operators(with ==(object,object)
defined as a reference comparison on the base) and using more complex rules
to determine which operator to call vs using the static ones as they are.
They both have their upsides, both their downsides, and sometimes it makes
it a bit too complex. As with implicit conversions, they are ok if used
carefully, when viable. Not as a shortcut for the lazy(one operator I doubt
I'll ever approve of is the assignment operator, I don't think that should
be overloadable).