Re: Why does this code work?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Cor Ligthert [MVP] <notmyfirstname@xxxxxxxxx> wrote:
What it takes extra is one time a set of the addressvalue (reference) to the
address (stack) that it already contains. I does not take the time to paint
the result of that, when you do that a billion times, on the screen.

I think you've completely missed my point.

If you think people aren't going to understand that when you pass a
reference in, the object referred to might change, then you ought to
honour that assumption. That means that if you *do* want to effectively
change the object (and return it), you need to create a new object with
the same data as the old object. *That* is much more than copying a
reference.

If, however, you don't do that, and you just modify the object in-
place, then it's confusing to the person who assumes that the object
*won't* be modified.

You can call this inefficiency. I thinkt that consistent use makes programs
it better to understand.

No - you either introduce a significant penalty by working against the
point of the framework, or you introduce *inconsistency* by implying an
invariant that you don't uphold.

I have used that black box method myself until I forgot what I was doing in
a method.

That's just a case of poor documentation then. The description of a
method should certainly specify if it's going to change the contents of
an object which has been provided using a reference. Given an
appropriate description, there's no reason for it to be confusing at
all.

It is for me a very classic way of programming as done in Cobol, probably
very usefull for programmers who still think in that way and won't give up
those "handy" things.

I haven't used Cobol, but it sounds like it was using value type
semantics. That's okay, but you need to understand the efficiency
penalties of doing that - and acknowledge that it's *not* the .NET way
of doing things. Why fight against what the framework promotes?

I think it should be prohibited that it is possible to use. It is for me the
same use as Cobol that had indexes (pointers) that holds the references too
adresses, good used it was ideal but you had to know what you was doing and
almost not to explain. (I have used this extremely often by the way).

Just because you've used it doesn't make it a good idea.

I have read on Internet that I am not the only one who does not like it, but
as I have understand those articles well, seems it to be a hobby of somebody
to keep this Cobol like behaviour in Net.

However as forever, feel free to disagree with me.

I'm afraid you just don't seem to be seeing my point at all. What
you're proposing is confusing in the extreme - it implies that you
don't make changes to the object whose reference is passed in. Either
you need to make sure that you honour that, in which case you have the
penalty of copying data, or you don't, in which case you create
confusing code because someone using that implication will be confused
if the object *does* change.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: DirectoryServices Problem
    ... the .NET architecture has me completely confused. ... programming since I wrote Machine Language for 8088 and Z80 CPU's, ... It's all so very confusing. ... I am hoping someone out there knows a great reference or link that can help ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Is everything a refrence or isnt it?
    ... > See what confusing, complicated hoops people have to jump through to ... > hammer the round peg of Python's behaviour into the square peg of "call by ... > Python coders can not get to them. ... > about "call by reference" and you just confuse yourself and others. ...
    (comp.lang.python)
  • Re: Weekly series after 52...
    ... It's just combine with your ambiguous sentence ... Another "Year" reference, reinforcing the notion that you think 52 ... not "52" that was confusing to you about my post. ... I'm not going to say that your communication skills are worse than ...
    (rec.arts.comics.dc.universe)
  • Re: basic newbie question about types
    ... > don't think it is confusing to say that Value Types get stored on the Stack ... > and Reference Types get stored on the Heap. ... That's like saying that objects are ... People claim that saying objects are passed by ...
    (microsoft.public.dotnet.general)
  • Re: CALL using OMITTED
    ... look for ways that Cobol can help with this. ... invoke MyCollection "new" returning CollectionObject ... I've never done it so I don't know the full implications - hopefully it creates a unique reference in the first Collection without impacting the second. ... Procedure Div using.... ...
    (comp.lang.cobol)