Re: Anders Hejlsberg comment on immutable objects
From: Jon Skeet [C# MVP] (skeet_at_pobox.com)
Date: 02/09/04
- Next message: Cor: "Re: the framework"
- Previous message: Bob: "Firing off a VC++ exe"
- In reply to: Martin Maat [EBL]: "Re: Anders Hejlsberg comment on immutable objects"
- Next in thread: Martin Maat [EBL]: "Re: Anders Hejlsberg comment on immutable objects"
- Reply: Martin Maat [EBL]: "Re: Anders Hejlsberg comment on immutable objects"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 9 Feb 2004 20:07:05 -0000
Martin Maat [EBL] <dummy@somewhere.nl> wrote:
> > No they don't, because just passing in a reference by value doesn't
> > mean that the object it refers to won't be changed. Don't forget that
> > you never actually pass objects as parameters in C#.
>
> I was discriminating between simple types and objects, simple types being
> integer, DateTime and such. I got to the objects in the next paragraph.
Apologies, yes.
> > For instance, take Array.Sort(Array). That doesn't change the
> > *parameter*, but it *does* change the array itself.
>
> If you are worried about this you don't make the argument a type that
> supports methods that can be used to change the object. This is a good
> example of a situation where a read interface does help out. If the
> interface offers only an indexed get property, the server method will be
> able to read the byte array, not change it. Only if you can't be bothered
> and trust the server method, you simply pass the full blown object.
But you can't add your own interfaces on top of, say, arrays,
ArrayList, etc, and the existing interfaces just aren't enough. I
suppose they could be added, but then you'd have pretty much one
interface per mutable class - is that really better than a single extra
keyword?
> > Also, your argument doesn't extend to properties and return values - if
> > something returns a byte array, am I free to alter that or not?
>
> I wasn't considering return values but the same applies. If you intend to
> return an object with the sole purpose of providing information to the
> client, you should return a limited interface, not the object itself. It
> will be clear at least, the client will not have to wonder if it may change
> the object or not. I am not saying there will be no way to hack around it.
Indeed - just casting would do it.
> As you pointed out with your examples it is hard to define what should be
> considered change, what is a violation of a const contract. With any complex
> type that is quite impossible, not only technically but even more so
> semantically. To what does the contract extend if you have contained and
> agrigated objects? I believe this is the shadow world Anders was refering
> to.
I don't think my example showed it being hard at all - Sort certainly
wouldn't take a "const array", although it could take an "array of
const elements" because it doesn't change the elements themselves. One
of the biggest problems there is the syntax, really.
Admittedly, there *is* another problem which is quite nasty. For
instance:
object[] o = new object[...];
o[0]=o;
...
Should you be able to sort o or not? Changing the array changes the
element within it because it contains itself. Personally, I'd be happy
with something which didn't try to particularly get things right in
that kind of situation, just because it's *so* hard to get right.
-- Jon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
- Next message: Cor: "Re: the framework"
- Previous message: Bob: "Firing off a VC++ exe"
- In reply to: Martin Maat [EBL]: "Re: Anders Hejlsberg comment on immutable objects"
- Next in thread: Martin Maat [EBL]: "Re: Anders Hejlsberg comment on immutable objects"
- Reply: Martin Maat [EBL]: "Re: Anders Hejlsberg comment on immutable objects"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|