So you have said that returning the result although it's not needed is
making the code less readable?
Cor Ligthert [MVP] wrote:
Goran,
It is nice that you agree with Jon, however you are telling completly
what Juli and I am stating in this thread, so as Jon says that he
agrees with you, than he agrees as well that he was talking about
another topic.
I have even stated this in my last message.
If one should always return the result, there are quite some methods
in the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...
Where I than add that it is impossible in my opinion because of
backwards compatibility.
Cor.
.
"Göran Andersson" <
[email protected]> schreef in bericht
I must say that I agree fully with Jon in this matter.
If you would always return the result even when not needed, you would
have to rely heavily on documentation to know what the methods
actually do. They really turn into the black boxes that you talk
about.
Take for an example the signature of a method that would add a
watermark to an image:
public Bitmap AddWatermark(Bitmap originalImage, int x, int y)
Assuming that the method returns the result even if it's not needed,
it's not at all obvious what the method does. It can either create a
new bitmap and return it, or draw on the original bitmap and return
another reference to it. As you need to dispose the bitmaps when you
are done with them, it's important to know if the method creates a new
bitmap or not, and you have to dive into the documentation to find
out.
On the other hand, if the method only returns a value when needed,
it's obvious what the method does. If the method creates a new bitmap,
it will be returned. If the method doesn't create a new bitmap, it
won't return one.
If one should always return the result, there are quite some methods
in the framework that needs changing. Like Array.Sort, Array.Reverse,
Array.Clear, Array.Copy, Stream.Read, Buffer.BlockCopy,
StringBuilder.CopyTo, etc...
Cor Ligthert [MVP] wrote:
Jon,
You go out of the point, I never have talked about using references
or not, moreover I have said in this thread to use those in an object
to pass and return information.
Moreover, my point is not to use in normal situations the Sub or the
Void to change in an easy way referency types hidden in a method, but
to return the reference. Even if that is technical not needed (as I
know). I nowhere have told people not to learn reference types, I am
not against guns (I once did sport shooting), I am against the wrong
use of guns.
Cor
"Jon Skeet [C# MVP]" <
[email protected]> schreef in bericht
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?
You can transfer a reference to an address not being the actual
address that
is tranfered.
Care to rephrase that? It doesn't make a lot of sense at the moment.
Used in performs (advanced for loops) which I have never seen
anymore in a
language as advanced it is in extended Cobol versions.
But as I said, have your own ideas, I had the same as yours, mine
is
changed, time willl probably learn if that sustains.
Well, the framework uses the pattern already. It's not like I'm
coming
up with it on my own. It's also used in other platforms such as
Java.
It's a pattern which works. It's efficient and readable - you just
need
to know the basics of the platform and be capable of reading
documentation. If you can't do those things then you've got no
chance
in the first place, IMO.
In my opinion the goal should be that it is not necessary to learn
basic
things. I assume that your new born kids will learn English without
any
problem, while it is for a lot of children more difficult than
their first
language.
If you're suggesting that people shouldn't have to learn the
difference
between reference types and value types, I couldn't disagree more.
Let's put this into a more concrete example. Suppose I have a method
AppendData which takes a StringBuilder and appends some data, either
to
it or to a copy of it. By your reasoning the method should return a
StringBuilder, because people may not be aware that the
StringBuilder
they pass in (as a reference) can be changed during that method.
Now, if they aren't aware that it can happen, they may well assume
that
it *can't* happen. If you're going to cope with that possibility,
then
you need to make sure you don't violate their assumptions -
otherwise
their code will break. So, you'd better take a copy of the
StringBuilder, creating another one, and appending to that before
returning it.
Now imagine someone passes you a StringBuilder with 100,000
characters
in it. See the problem?
In this case, you actually suggested that you just return the same
reference having modified the object in-place. At that point, anyone
who doesn't understand the type system is probably going to end up
with
errors sooner or later.
Compare this with my solution: educate people and document what the
method does. You can then write efficient and intuitive methods
(names
like "Fill" or "Populate" generally give the game away) which don't
make assumptions that the caller is stupid.
