Re: Anders Hejlsberg comment on immutable objects

From: Magnus Lidbom (magnus_lidbom_at_hotmail.com)
Date: 02/09/04 

Date: Mon, 09 Feb 2004 22:32:24 +0100

On Mon, 9 Feb 2004 13:26:08 -0600, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

>
>"Magnus Lidbom" <magnus_lidbom@hotmail.com> wrote in message
>news:98af20hjfrgn4ekq7g34nheqtaimqc3nrb@4ax.com...
>> On Mon, 9 Feb 2004 08:08:54 -0600, "Daniel O'Connell [C# MVP]"
>> <onyxkirx@--NOSPAM--comcast.net> wrote:
>>
>> >
>> >"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>
>>
>> >> >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.
>>
>> I don't understand what you mean. Enough what?
>Implicitly const classes are immutable by implementation. That makes the
>object immutable as either a sideeffect or a matter of const implementation.
>This is slightly different than an object being immutable at its core. It is
>subtle, I suppose.

I'm sorry, I still don't understand what point you are trying to
make. What do you mean by "at its core"? I don't understand why you'd
consider it a sideaffect. The immutability could be accomplished
,behind the scenes, by implicitly making all members and alll
instances of a class declared immutable const. That doesn't mean the
immutability of the class would be any less an conscious, intentional,
and explicit atribute of the class.

>> Performance is an important characteristic of any application. There's
>> always a level that's not good enough. For a much used tool, a central
>> library, and any number of other applications, good performance is
>> critical. If one wishes for ones application to do well in this area,
>> one needs to keep it in mind, and performance will to some degree
>> affect every architectural decision made. Every day I work, my
>> productivity is to some degree dictated by the performance of the
>> applications that are my tools in trade. The same goes for anyone
>> using a computer, everyone using the applications I make. The rising
>> power of hardware has not been able to do much more than offset the
>> rising level of complexity that the average application demands.
>> Hardware just a few years old is now completely unsuitable for complex
>> modern applications, and there's no end in sight for that trend.
>>
>On this I agree, however for most apps I still think overarching performance
>is a tertiary issue,

Only if performance is already acceptable. Would you use a news reader
that took 90 seconds to start and 15 seconds to display a post? No
matter how many nifty features it had, or how maintainable it was, I
wouldn't.

>feature set\specs are first, good enough performance
>second Where to draw the line isn't really my place, most apps I write
>aren't highly performance critical, speed of development and safety of
>development is. It would be mainly a tradeoff between the speed of the app
>and the ease and safety of the code

I find that clean well structured designs generally perform very well.
Caching and lazy evaluation barred, I rarely find myself complicating
a design in order to improve performance.

>> Certainly. It is easy to make mistakes. I make them every day. That's
>> largely why I need all the abstractions that helps me create better,
>> safer code faster than I could without them. I very much appreciate
>> the compilers efforts on my behalf. But at the end of the day the
>> compiler is a tool that I need to do what I tell it. If I tell it to
>> look the other way while I cheat, by applying a cast, I expect it to
>> obey, because there are situations where I must have that ability. You
>> brought one such situation up in your last post.
>WHich is part of what bothers me. Cheating via reflection or something else
>that can be controlled by security is one thing, cheating using the language
>is quite antoher.

It bothers me too, but I've yet to hear of an alternative I consider
better.

>> >It depends, I cast pretty much only to explicitly convert to an
>interface.
>>
>> Good catch. I failed to consider that quirk of the language. Since the
>> compiler already knows that the class implements the interface, and
>> that the cast will therefore always succeed, no warning should be
>> issued in this case. Semantically, this is not a cast. It is merely a
>> mechanism to allow you to unambiguously specify which method you
>> intended to call in the presence of naming conflicts when implementing
>> multiple interfaces.
>>
>Unfortunatly, the compiler can't actually know if the class implements the
>interface, atleast usually. A typed variable has no constraints on if the
>class provides an interface unless the type does. Derived classes are free
>to (re)implement interfaces. It may not be the cleanest thing but it is
>often reliable(preferably using as rather than (cast) operation, but still).

I assumed you were talking about casting an instance of a specific
class to an interface that the instance's class implements explicitly.
If that's not what you mean, then either there is no need for a cast,
or we are talking about the sledgehammer that I would want to se a
warning for, at the highest warning level.

>> >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++.

To a great degree that's true. But how hard is it to cast
IConstMyClass to MyClass? Any harder than casting away const? Any
more safe? How about IList to ArrayList when the debugger has shown
you that it is an ArrayList?

>Safe is one thing, confusing and unapparent is another. Implicit conversions
>in most cases are an issue more of apparentability than anything else. Casts
>are apparent and a coder can deal with them, an implicit conversion is a
>risky thing that can cause code and behaviour to come into being that isn't
>expected.

 It should be neither confusing, unapparent nor risky. Implicit
conversions should occur only where the source type is an instance of
the target type as far as OO is concerned. As far as I know this is
the case for all built in implicit convertions.

>> >Now, when the *entire* framework doesn't have const, thats an awful lot
>of
>> >sledgehammering, isn't it?
>>
>> If no part of the framework uses const then const will simply be
>> irrelevant in the context of the framework classes. There will be no
>> need for casts. Problems arise only upon inconsistent use of const.
>If const is limited to only some areas, is it right? Is it valuable? In my
>opinoin it isn't. If const isn't used everywehre its utility is
>significantly reduced, fragemented really. If theframework isn't const able,
>const is a useless feature.

Can you present an example, in code, where the framework not using
const would significantly detract from my ability to benefit from
using const? Except for needing to swap out the included collections,
I don't see much of a problem at all. And I'd certainly expect const
correct collections to be provided if const was implemented.

>> >structs should be immutable by default, IMHO.
>>
>> Immutability is a relatively rare trait, making it the default would ,
>> in my opinion, be inappropriate. It certainly would break an immense
>> amount of code.
>Possibly, I should say immutability should be a design goal for value types.
>Due to their copy by value nature, you can't rely on a value type for much,
>immutability is often logical.

This is not at all my experience. Actually, I don't know of a single
immutable struct type. Could you provide examples and a motivation for
this guideline?

>> >Considering they are by value,
>> >const should be irrelevent in this case.
>>
>> What about ref and out parameters?
>Thats irrellevent, ref paramenters are implicitly going to change, thats the
>purpose of the ref

Exactly. That doesn't mix at all with immutable structs, which was the
point I was trying to make.

<snip>

>> >> >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,
>>
>> Even those, like the one above, that are 100% guaranteed to be safe?
>
>Except in limited situations, I'd rather see the explicit cast in code,
>mainly for maintaince sake.

I don't understand this at all. How would placing a cast at the site
of every implicit convertion help maintainability? I'd expect the
opposite. A whole lot of code would still compile after changing the
type of a variable, because you explicitly cast it when passing it as
a base type or interface. You've written a whole lot of unnessessary
casts and moved refactoring problems from compile time to runtime, as
well as significantly increased the pure typing effort involved in
both the original coding and any refactoring. I see no gain in any of
this. Quite the opposite.

<snip>

>> You don't believe in the competent programmer. I don't believe in the
>> safe programming language. I do believe in the balanced programming
>> language. The one that takes a pragmatic approach and tries to shelter
>> the programmers as much as possible without hamstringing them or
>> creating catch 22 scenarios. I think C# has done very well so far.
>As do I, I just think there are a few other bits that could be done, ;).

As do I. Most of the things I want done are in fact scheduled for
Whidbey :)

Regards /Magnus Lidbom

Relevant Pages

  • Re: Anders Hejlsberg comment on immutable objects
    ... >> all references are implicitly const is in fact immutable. ... >cast it away, and as I've said many times, everyone, me and you included, ... Implicit conversions are quite different. ... >> the vtable pointer from the instance to the reference. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... >>Implicitly const classes are immutable by implementation. ... The immutability could be accomplished ... often cast to get the interface instead of simply hoping that the entire ... >>are apparent and a coder can deal with them, an implicit conversion is a ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... Immutability is a design goal that is achieved by use ... >>const, not an effect or result of const itself. ... I define improper as any conversion not fitting ... Unless the ability to cast away const was removed as you've ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... The immutability could be accomplished ... Immutable means that all instances are const. ... >> the case for all built in implicit convertions. ... If you mean that you use cast to mark _improper_ implicit conversions, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... Implicitly const classes are immutable by implementation. ... >>cast it away, and as I've said many times, everyone, me and you included, ... > Implicit conversions are quite different. ... I should say immutability should be a design goal for value types. ...
    (microsoft.public.dotnet.languages.csharp)