Re: Anders Hejlsberg comment on immutable objects
From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 02/10/04
- Next message: Michael Culley: "Re: Find External (WAN) IP Address"
- Previous message: Eric: "Enter Data in the AddNew Row"
- 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 20:45:50 -0600
> >> >
> >> >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.
Lemme reword this. Immutability is a design goal that is achieved by use of
const, not an effect or result of const itself. It can be achieved *without*
it, and has been. Immutability is a concept, a constant method is a
different concept, even if one is used to achieve the other.
>
>
> >> 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.
>
Nor would I, but that doesn't mean my app needs to run in .0015 seconds
either. Even with some runtime additions I doubt performance would drop
significantly. My algorithms are more likely the issue.
> >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.
As do I, which really isn't on point. I believe originally it was a concern
about runtime const verification being a performance liability?
>
> >> 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.
Usually because of explicit implementation(or to decouple things, usually
due to reflection.) However it can be difficult sometimes to know if an
explicit implementation exists or not, just because a base class implements
it implicitly, a derived class could reimplement it explicitly, so I'll
often cast to get the interface instead of simply hoping that the entire
interface is implicitly implemented. I generally don't trust that MyObject o
= <whatever> is nessecerily MyObject, not MyObjectDerivedFromMyObject.
>
>
> >> >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?
Which is, in part, a problem. However there is simply no way to avoid it. I
feel with const that there may well be a way to avoid it without leaving
this hole.
>
> >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.
If you are working strictly with built in types you are lucky. I don't hav
ethe time to analyze every piece of code\library I get nor can I
realistically reject something simply because it provides an implicit
conversion I don't like. I don't like to rely on implicit conversions
otuside of some very limited situations
>
> >> >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.
Mainly because you would loose the ability to pass objects into the
framework. If an object can't be used with the framework then why have a
framework? As I illustrated before(different convo), you also technically
loose access to ToString(), Equals(), GetHashCode(), the comparison operator
and more or less any other method that the framework uses constantly.
Without const in System.Object, const is broken.
>
> >> >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?
The primative .NET types are immutable. You create a new value type instead
of modifying the existing one. Other simple value types will be immutable,
when only one data type exists, why allow them to chagne the existing value?
Beyond that, it rarely matters, changing a struct usually only affects the
code that changed the struct
>
> >> >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.
It isn't related at all. I'm not entirely sure what your point is here. ref
implies that the *variable* can change, not the struct. There is a different
IMHO
>
> <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.
Simply because the next guy can easily tell whats going on. With the
exception of numeric conversions(mostly because thats how peoples minds
work), I don't like implicit conversions. A cast to a base class isn't an
implicit conversion, thats an implicit cast. Which is quite a different
thing.
>
>
> <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 :)
>
Hehe, although I think generics are a litttle overhyped, whidbey also adds a
few features that may make things worse...I just don't know yet.
>
> Regards /Magnus Lidbom
>
- Next message: Michael Culley: "Re: Find External (WAN) IP Address"
- Previous message: Eric: "Enter Data in the AddNew Row"
- 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
|
