Re: Anders Hejlsberg comment on immutable objects
From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 02/09/04
- Next message: machine: "MS Word - PDF converter component"
- Previous message: Anushya: ".NET + Redemption + Addin"
- In reply to: Magnus Lidbom: "Re: Anders Hejlsberg comment on immutable objects"
- Next in thread: Magnus Lidbom: "Re: Anders Hejlsberg comment on immutable objects"
- Reply: Magnus Lidbom: "Re: Anders Hejlsberg comment on immutable objects"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 9 Feb 2004 08:08:54 -0600
"Magnus Lidbom" <magnus_lidbom@hotmail.com> wrote in message
news:2m9d20t56gg2e7dfn1q2pr81c4khsrg48t@4ax.com...
> On Sun, 8 Feb 2004 15:03:21 -0600, "Daniel O'Connell [C# MVP]"
> <onyxkirx@--NOSPAM--comcast.net> wrote:
>
> >
> >"Magnus Lidbom" <magnus_lidbom@hotmail.com> wrote in message
> >news:5e0d20lr56mf0v6tq9kkmspft1jjego3n7@4ax.com...
> >> On Sun, 8 Feb 2004 12:30:17 -0600, "Daniel O'Connell [C# MVP]"
> >> <onyxkirx@--NOSPAM--comcast.net> wrote:
> >>
> >> >
> >> >"Magnus Lidbom" <magnus_lidbom@hotmail.com> wrote in message
> >> >news:lmnc20514dqscgfo82i6qks0ipniogl6ti@4ax.com...
> >> >> On 8 Feb 2004 04:38:29 -0800, andrew_quine@fastmail.fm (Andrew
Quine)
> >> >> wrote:
> >>
> >> <snip>
> >>
> >> >>
> >> >> <Anders Hejlsberg>
> >> >> With respect to immutability, it's tricky because what you're saying
> >> >> when you say something is immutable, is that from an external
> >> >> perspective, I cannot observe any mutation. That doesn't necessarily
> >> >> mean that it doesn't have a cache inside that makes it go more
> >> >> efficiently. It's just on the outside it looks immutable. That's
hard
> >> >> for a compiler to figure out.
> >> >> </Anders Hejlsberg>
> >> >>
> >> >> C++ solves this problem quite handily with the mutable keyword. Only
> >> >> fields declared mutable may be modified by a const member.
> >> >
> >> >It is a clean solution, however it promotes keyword and language
bloat.
> >Is
> >> >it worth yet another modifier?
> >>
> >> If C++ style const is introduced, mutable is a necessity. The need for
> >> lazy evaluation and similar techniques is far to common to leave
> >> mutable out.
> >>
> >> >However that doesn't directly approach the
> >> >subject. An immutable object is not *const*, it is immutable.
> >>
> >> It is const. That's what immutable means. That any and all instances
> >> of the class are const.
> >>
> >What I mean is that an immutable object is different from
> >public const MyObject o;
>
> In concept yes. In implementation, not necessarily. A class for which
> all references are implicitly const is in fact immutable.
>
Is not concept enough? I don't consider implementation enough at times.
> <snip>
>
> >> I don't see why C# could not give the same guarantees through a
> >> compile time validation that C++ can. Could you elaborate on this?
> >
> >To be entirely clear, the C# compiler would be expected to provide
compile
> >time verification, thats a given in my mind. However, I don't feel that
it
> >is enough. The runtime should provide the last-word guarentee, while the
> >language\compiler provides compiletime verification of its own source
> >against the contract provided by classes, but no deeper. The point of
this
> >would be that *no* code could break const. Isn't that part of the point
of
> >managed code, ?
>
> Providing better guarantees and helping the programmer as much as
> possible, certainly is a large part of the point. But you can only
> take it so far. Sometimes one must be pragmatic and take what one can
> get with a reasonable amount of effort and at a reasonable cost in
> runtime complexity and performance.
>
The question is whats reasonable. I feel that a runtime verified system *is*
reasonable. I don't think raw performance really matters anymore, not in
apps I write in .NET. Considering the performance drops from code access
security, reflection, and the dozen other things we use in our apps every
day, would it really matter?
>
> >
> >>
> >> <snip>
> >>
> >> >Const in C++ isn't really much of a contract, its just a "you really
> >> >shouldn't do this, but go ahead if you want to" kind of thing.
> >>
> >> Only if you consider bugs and undefined behavior to be OK.
> >> Const can't stop programmers from making a mess when they break the
> >> rules on purpose. That doesn't detract anything from the protection
> >> and clarification that it can provide.
> >I agree, however, I simply don't feel such a thing as a competent
programmer
> >exists(we all screw up and make bad choices once in a while), if we are
> >going to go ahead with const we may as well do it right. const *isn't* a
> >contract when applied to a reference, in the C++ style, it is more a
> >shelter.
>
> Const in C++ lets you state things like:
> You may not invoke this member on a const reference.
> Invoking this member will not modify observable state.
>
> To me, that is a contract.
const on a method is a contract, const on a variable isn't. That is what I
meant.
>
>
> > It protects the coder from making a mistake, but doesn't stop them.
> >I would like to see a form of const in C#\.NET that *is* a contract. A
const
> >instance should always be constant.
> >For that matter, what I consider to be ok and what is a real contract are
> >very different things. For what I consider, documentation is strong
enough,
> >I will read it and believe it(unless the code starts to show otherwise).
A
> >real contract should be enforced by both the compiler and the runtime,
not
> >something that can be circumvented so easily as C++ const can.
>
> Once again, easily only if you consider undefined behavior and bugs
> ok.
>
You are making a very big mistake assuming that undefined behaviour and bugs
matters as to how easy it is to dispose of. It is *really* easy to simply
cast it away, and as I've said many times, everyone, me and you included,
are going to make stupid mistakes. C++ simply *DOESN'T* protect from that,
at times it may well promote it.
> >> >I don't consider the C++ const implemetnation to be sufficent, the
more I
> >> >think about it the more I consider it broken for .NET\C#.
> >>
> >> Please elaborate.
> >Much as I was saying above. It is a weak contract, if a contract at all,
and
> >not something that should be in a system like .NET.
>
> I think our differences in opinion here stem from different cultural
> values as to the use of casts. Casts are a last resort sledgehammer.
> It's telling the compiler that you know better than it does and that
> it should look the other way while you cheat. The lack of generics in
> C# has fostered an attitude towards casts that I consider unhealthy.
> Cast are used all over the place, often unnecessarily, and no one bats
> an eyelid. Hopefully that will start to change with the arrival of
> generics. The C# community will need to learn that casts are "evil"
> and should only ever be used in exceptional circumstances. I would
> like to se a compiler warning for every cast at the highest warning
> level. That should help to raise awareness that casts are dangerous
> and should be avoided unless absolutely necessary. After the arrival
> of generics the average application should not need a single cast.
>
It depends, I cast pretty much only to explicitly convert to an interface.
Casts are frustrating things, but they are nessecery at times. I consider
casts to be a smaller issue in .NET than it is in C++. Simply put, casts are
*never* undefined, it is either an exception(a cast to a type that the
object isn't), an implicit or explicit conversion, or a cast to a actual
class. Its not possible to cast to a random object and circumvent things as
it is in C\C++.
A warning on every cast would annoy me greatly, I don't like casting things
that can be implicitly cast without an explicit cast.
> >>>> <Anders Hejlsberg>
> >>>> If you declare a method that takes a const Bla, you could pass it a
> >>>> non-const Bla. But if it's the other way around you can't.
> >>>> </Anders Hejlsberg>
> >>>>
> >>>> That is exactly the point to having const. That is a boon. If your
> >>>> code fails to compile because of this, you were just saved from
> >>>> introducing a bug by modifying an instance you had no right to
modify.
> >>>
> >>>But it is annoying when the code actually doesn't make a modification,
> >>>but
> >> >simply was written without regard to const(which, at this point, will
be
> >> >most code).
> >>
> >> The fix is extremely simple, add const to the parameter declaration.
> >And do what exactly when you don't control that code?
>
> You complain to the provider, demanding they supply a reasonably well
> designed interface. In the meantime you copy the instance. If that's
> undoable you bring out the sledgehammer, cast const away, and hope you
> know what you are doing.
>
Now, when the *entire* framework doesn't have const, thats an awful lot of
sledgehammering, isn't it?
> >>
> >> > Its a considerable limitation when your const methods have to
> >> >start rolling their own methods to do everything because they can't
> >> >realistically pass a const reference into a non-const method.
> >> >I would expect something like
> >> >public const MyType MyMethod(const MyType t) const
> >> >{
> >> > MyOtherMethod((MyType)t);
> >> > return t;
> >> >}
> >> >
> >> >to fail the compile time verification. t may have changed in the call
to
> >> >MyOtherMethod
> >>
> >> Only if MyOtherMethod takes a non const MyType.
> >
> >I should have specified that, but I meant to imply that MyOtherMethod
> >doesn't take const MyType as its parameter.
> Ok. Then you're certainly right, that code would, and should, fail to
> compile.
>
>
> <snip>
>
> >> Making it impossible to cast away const would, as you say, require
> >> modifications to the runtime. Unless I'm mistaken, it would in fact
> >> require changing the runtime representation of a reference, doubling
> >> its size from 32 bits to 64, and introducing another level of
> >> indirection for each invocation of a member on a reference. I don't
> >> think the consequences of such a change would be palatable. For
> >> starters it would almost double the memory usage of most .Net
> >> applications,
>
> I overestimated badly here. The implementation I imagined would move
> the vtable pointer from the instance to the reference. The increase
> would occurred only for instances having multiple references to them.
> Also, no increase would occur for structs. The increase would likely
> be noticeable. but probably be nowhere near a doubling for the average
> application.
structs should be immutable by default, IMHO. Considering they are by value,
const should be irrelevent in this case.
>
> >and I'd expect a performance degradation across the
> >> board.
> >
> >I don't think there would be a nessecery increase in the size of a
> >reference. 32 bits will handle 4 billion references, which is impossible
to
> >do with 32 bit hardware(16gigs of references alone), on 64 bit hardware
you
> >have far more. It wouldn't be impossibleto carve off 2 or 3 bits from a
> >reference for flags, even if a reference is only 30 bits you end up with
> >about 1billion possible references, which is more than enough for *ANY*
> >application running on the framework, even 500 million is probably
> >sufficent(at this numbers, the size of reference * the number of
references
> >alone supercedes .NET allocable memory, leaving no room for the actual
> >objects). While such a thing isn't nessecerily feasible, it would work
> >without any of the problems. It also assumes the top 2 bits aren't
already
> >used for something.
>
> This would still require a translation for every single derefencing of
> a pointer/reference. You may save some memory, but you will certainly
> still suffer a performance degradation across the board.
>
It shouldn't be that much, considering the work done for a reference anyway,
it shouldn't be a big deal.
> >Ideally, it would be possible to cast *to* const
> That should be an implicit conversion. Zero runtime cost with a
> classic implementation.
I dislike implicit conversions, would have been happy if the implicit
conversion operator didn't exist in C#.
>
> <snip>
>
> Regards /Magnus Lidbom
- Next message: machine: "MS Word - PDF converter component"
- Previous message: Anushya: ".NET + Redemption + Addin"
- In reply to: Magnus Lidbom: "Re: Anders Hejlsberg comment on immutable objects"
- Next in thread: Magnus Lidbom: "Re: Anders Hejlsberg comment on immutable objects"
- Reply: Magnus Lidbom: "Re: Anders Hejlsberg comment on immutable objects"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
