Re: Anders Hejlsberg comment on immutable objects

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

Date: Mon, 09 Feb 2004 19:55:46 +0100

On Mon, 9 Feb 2004 18:45:01 +0100, "Martin Maat [EBL]"
<dummy@somewhere.nl> wrote:

>"Jon Skeet [C# MVP]" <skeet@pobox.com> wrote in message
>news:MPG.1a91c58586299a9298a098@msnews.microsoft.com...
>> Martin Maat [EBL] <dummy@somewhere.nl> wrote:
>
>> > If I pass in a simple type by reference I typically want it to be
>changed.
>> > Had this not been my intent, I would have passed it by value. C# has ref
>and
>> > out for those purposes and they serve us well.
>
>> 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.
>
>> 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.

I wrote a post, with a short comparison of const and read only
interfaces, not long ago that you may find enlightening:

http://groups.google.com/groups?q=g:thl1806205673d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=bvhnig%24sd2t9%241%40ID-204195.news.uni-berlin.de&rnum=38

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

Not really. He just pointed out the fact that you must distinguish the
parameter from the object referenced by the parameter in the case of
reference type parameters, and that the ref and out keywords doesn't
help in managíng access to that object.

> 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've never seen or heard of any such impossibilities. How const
applies to aggregated objects has always seemed perfectly logical and
infinitely extensible to me. Could you provide a concrete example?

/Magnus Lidbom

Relevant Pages

  • Re: Anders Hejlsberg comment on immutable objects
    ... >explicit interface implementation exists is so an interface name can class ... Improper implicit conversions constitute a nasty ... >> With value types, the variable's value is the object, not a reference ... Consider the affects of our different views on a const ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Anders Hejlsberg comment on immutable objects
    ... >>explicit interface implementation exists is so an interface name can ... I wouldn't cast to an ... > variable as a sort of implicit reference, ... readonly const MyStruct myInstance. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Delphi interfaces vs. COM interfaces
    ... it decrements the reference count of the COPY. ... > the interface has to change. ... In the context of mixing object references and interface references, ... counting on the const to not cause an object reference to go out of scope ...
    (borland.public.delphi.language.objectpascal)
  • Re: Anders Hejlsberg comment on immutable objects
    ... > example of a situation where a read interface does help out. ... > able to read the byte array, ... > and trust the server method, you simply pass the full blown object. ... what is a violation of a const contract. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: 7.0 wishlist?
    ... The "auto-implement" is intended mainly for the odd situation where an existing class you can't edit fits some interface and you're willing to take responsibility for it if it turns out not to actually adhere to the contract, and try using it where that interface type is expected. ... If reference declarations started showing up with the odd asterisk, bang, or other punctuation mark on it, but never primitive declarations, people would probably be able to guess what was going on, on the basis of "what other binary flag might be set on references but not primitives and would be really useful besides can be/cannot be null?" ... the compiler cannot prove by static analysis that the RHS isn't null might be a good idea. ... Object foo, bar; ...
    (comp.lang.java.programmer)
Loading