Why does this code work?

[Cor Ligthert [MVP]]

Goran,

So you have said that returning the result although it's not needed is
making the code less readable?

I have said that if there is a result it should be returned, if there is no
result it should not be returned.

Cor

So you have said that returning the result although it's not needed is
making the code less readable?

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.

.

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.

 

[Jon Skeet [C# MVP]]

I think you are mixing me up with somebody else, this is typical Herfried.

No, definitely you. (Mind you, Herfried was indeed saying that it was
good that VB.NET allows it.)

See

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/bro
wse_frm/thread/4ae51a3df8cf5165/258510a78bdd119f

You agreed it should not be used, but disagreed with the idea of it
being prohibited:

<quote>
But I only agree that it should not be used

When I saw that you said "prevented from" than I did disagree and I did
not use more arguments in this long thread.

Because I find it one of the charms from VB.net that it gives such a
lot of personal responsibility.

We both live in the EU which gives us responsibility. But there are
more countries in the world and in that countries is another behaviour
and therefore I am glad that I am from the EU and will defend that
also.
</quote>

(This was after a lot of disagreeing with me, claiming I was changing
my line of attack despite the fact that throughout the entire thread I
was only ever addressing this single issue.)

In other words, you seem to find it a *good* ("charming") thing that
VB.NET lets you write less readable code in this particular way,
despite the fact that in the very same message you said it had cost you
some time when reading some code.

I find that a difficult view to reconcile with the one you're currently
expressing, that it would have been good to have prohibited a feature
which is genuinely useful and need not in any way be unreadable.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Goran,


I have said that if there is a result it should be returned, if there is no
result it should not be returned.

Cor

But that is so unbelievably obvious. Why did you even say that?

Do you mean that your selfevident statement would be the same thing as
when I said that if the method creates a new object, it should be
returned, and if it does only change the object passed to it, it should
not return anything?

Then you contradict yourself, as that is the opposite of what you have
said throughout the entire thread.

So you have said that returning the result although it's not needed is
making the code less readable?

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.

 

[Cor Ligthert [MVP]]

Jon,

No, definitely you. (Mind you, Herfried was indeed saying that it was
good that VB.NET allows it.)

See

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/bro
wse_frm/thread/4ae51a3df8cf5165/258510a78bdd119f

Nothing in that, than things like this.

If you follow the thread well, I explained to OHM that I agreed with the
basic of the arguments of Jon, OHM and Armin about the use of the code.
However, my point was only that I understood from OHM that it should be
preserve in the language. If that would be the point, every language older
than 1 year should be newly written again.

I am telling only again and again in that long discussion thread that every
program languages has their special aspects the same as with natural
languages and you cannot change a language just by telling that you would
like it in another way.

The same as I am telling in fact now

Somewhere you have written that I wrote what you said, what I denied, and
now again I cannot find anything in that thread where I wrote what you tell
that I wrote.

Cor

 

[Jon Skeet [C# MVP]]

Nothing in that, than things like this.

Er, yes. There's plenty of other things than that. That's why fairly
early on, when someone had agreed with me that C# makes things clearer,
you changed the title of the thread to "Static members in C# (I
respectfully disagree)". Anyway, I guess we can leave it to other
readers to make their minds up.

I am telling only again and again in that long discussion thread that every
program languages has their special aspects the same as with natural
languages and you cannot change a language just by telling that you would
like it in another way.

You certainly can - which is why it's now configurable as a warning in
VS2005. In fact, your argument was a straw man as I don't think I ever
said that the language should be *changed* - just that it shouldn't
have been allowed in the first place. It was a flaw in VB.NET. That
flaw has now been at least partially remedied by having a warning
available. Not quite as good as making it an error that cannot be
changed as an option, but not too bad.

The same as I am telling in fact now

Somewhere you have written that I wrote what you said, what I denied, and
now again I cannot find anything in that thread where I wrote what you tell
that I wrote.

You couldn't find the text I quoted? See

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/msg
/794fa45690ccec72

 

[Cor Ligthert [MVP]]

Goran,

It seems to be an hobby from developers to tell what others said.

I said in the entire thread that if there was a result it should be
returned, even if that was a zero result or a result that would be created.
If it was a void method (sub) than it should be obvious that there is not
comming any result from the method.

This I have said during the entire thread.

That in oposite of the idea that there is no reason to return it because it
is the nature of a reference type that the result can be placed in the
reference type. I find this extremely handy, but not real good to
maintenance, because you have than to check every method if there is not
something happening.

In code, I don't find this nice coding even as handy that it can be.

Private function (byval myref as whatever) as datatable
if myref.createproperty = true then
myref.createproperty = false
return new datatable
end if
End function

Now I can use that property only once or have to preserve it in advance what
makes it not clearer in the caller

Cor

I have said that if there is a result it should be returned, if there is
no result it should not be returned.

Cor

But that is so unbelievably obvious. Why did you even say that?

Do you mean that your selfevident statement would be the same thing as
when I said that if the method creates a new object, it should be
returned, and if it does only change the object passed to it, it should
not return anything?

Then you contradict yourself, as that is the opposite of what you have
said throughout the entire thread.

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.

 

[Jon Skeet [C# MVP]]

It seems to be an hobby from developers to tell what others said.

I said in the entire thread that if there was a result it should be
returned, even if that was a zero result or a result that would be created.
If it was a void method (sub) than it should be obvious that there is not
comming any result from the method.

This I have said during the entire thread.

That in oposite of the idea that there is no reason to return it because it
is the nature of a reference type that the result can be placed in the
reference type. I find this extremely handy, but not real good to
maintenance, because you have than to check every method if there is not
something happening.

But the way you've suggested working, you still have to anyway -
because even though you're returning a result, you're *still* modifying
the object whose reference was passed in. If the point is to make it
clear where there are side-effects, the attempt fails - it adds no
clarity at all, merely confusing developers like myself who would
wonder why the method bothers to return a reference which I clearly
already know about.

 

[Cor Ligthert [MVP]]

Jon,

You couldn't find the text I quoted? See

http://groups.google.com/group/microsoft.public.dotnet.languages.vb/msg
/794fa45690ccec72

You said I wrote something about this

I had an interesting thought earlier, by the way - I find it somewhat
amusing that you'd have preferred it if a genuinely useful feature like
this was prohibited, but in the past you've defended VB.NET for
allowing static method calls to look like instance method calls. Now
that *really* reduces readability! (It's nice to know you can make it a
warning or even an error IIRC in VS 2005...)

I really don't see that I wrote what you said, this text is without the
context not understandable, but there is nothing that you told that I wrote.
--------------------------------------------------------------------------------------
OHM,

I thought that I even saw it yesterday in a message thread and it did cost
me some extra time to understand the code. (To be true I did only slightly
look at what you where talking about, because I did agree with the
arguments).


But I only agree that it should not be used


When I saw that you said "prevented from" than I did disagree and I did not
use more arguments in this long thread.


Because I find it one of the charms from VB.net that it gives such a lot of
personal responsibility.


We both live in the EU which gives us responsibility. But there are more
countries in the world and in that countries is another behaviour and
therefore I am glad that I am from the EU and will defend that also.


Cor
-------------------------------------------------------------------------------

I respectful disagried with OHM that there should be a breaking change
because of what he wrote, for me it was not important enough for that.

Nothing about what you wrote.

Cor

 

[Jon Skeet [C# MVP]]

You said I wrote something about this


I really don't see that I wrote what you said, this text is without the
context not understandable, but there is nothing that you told that I wrote.

Well, all the quoted text was there, and reading the whole thread, it's
hard to think of anything other than access to static members through
instances which would prompt this bit:

<quote>
Because I find it one of the charms from VB.net that it gives such a
lot of personal responsibility.
</quote>

Anyway, it's ancient history now. It's still not entirely clear to me
what point you *were* trying to make on the thread, but I certainly
wasn't the only one who believed you were defending VB.NET's position
on the static/instance business. Perhaps if you're so worried about
people claiming you've said things you didn't, it would be worth trying
to be clearer about what you *are* saying.

 

[Julie]

Jon / Goran,

Its obvious if you have a VB.Net function that, recieves a prameter but
doesn't return anything (a.k.a. my SQL Command object) well then think
refernce type and the values for the passed object will be modified.

Again I say, I can appreciate reference types efficency.

BUT WHY ON GODS GREEN EARTH WOULD A VB.NET PROGRAMMER CODE A FUNCTION
WITHOUT A RETURN VALUE. FOR WHAT IS A FUNCTION THAT DOES NOT RETURN A
VALUE ... HELLO A SUBROUTINE.

 

[Jon Skeet [C# MVP]]

Its obvious if you have a VB.Net function that, recieves a prameter but
doesn't return anything (a.k.a. my SQL Command object) well then think
refernce type and the values for the passed object will be modified.

Exactly - assuming that it needs to modify anything in the first place,
of course.

Again I say, I can appreciate reference types efficency.

BUT WHY ON GODS GREEN EARTH WOULD A VB.NET PROGRAMMER CODE A FUNCTION
WITHOUT A RETURN VALUE. FOR WHAT IS A FUNCTION THAT DOES NOT RETURN A
VALUE ... HELLO A SUBROUTINE.

Yes, I think everyone agrees with that.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Goran,

It seems to be an hobby from developers to tell what others said.

No, it's mostly you who do that.

You said:

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

Since then I have tried to make it clear that I did not in fact say what
you claimed that I did.

I said in the entire thread that if there was a result it should be
returned, even if that was a zero result or a result that would be created.
If it was a void method (sub) than it should be obvious that there is not
comming any result from the method.

This I have said during the entire thread.

That in oposite of the idea that there is no reason to return it because it
is the nature of a reference type that the result can be placed in the
reference type. I find this extremely handy, but not real good to
maintenance, because you have than to check every method if there is not
something happening.

I agree with you that changing an object sent to a method is not ideal
when it comes to maintainence. That's why it's mostly used where there
are great performance requierements and gains.

However, it is not in any way made better by also returning the object
that was changed. It only makes it much more confusing.

In code, I don't find this nice coding even as handy that it can be.

Private function (byval myref as whatever) as datatable
if myref.createproperty = true then
myref.createproperty = false
return new datatable
end if
End function

Now I can use that property only once or have to preserve it in advance what
makes it not clearer in the caller

Cor

So you have said that returning the result although it's not needed is
making the code less readable?
I have said that if there is a result it should be returned, if there is
no result it should not be returned.

Cor

But that is so unbelievably obvious. Why did you even say that?

Do you mean that your selfevident statement would be the same thing as
when I said that if the method creates a new object, it should be
returned, and if it does only change the object passed to it, it should
not return anything?

Then you contradict yourself, as that is the opposite of what you have
said throughout the entire thread.

"Göran Andersson" <[email protected]> schreef in bericht
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.

 

[Ciaran]

This works because the command is a reference type. That means the VALUE
that is passed if the address of the object. That means that there are now
to references to the same object. One in the function and one original one
outside the function. Changing property values on the object, like adding
parameters, will affect both.
If in the function however you wrote:
cmd = new Command()
then the reference would be replace with one to a new object and they would
no longer point at the same object.
If the parameter was passed by reference, then the value passed to the
function is a reference to the reference to the object. This has the same
affect with the properties but also means using the new keyword as above
would update the reference in the calling function too.



Ciaran
There are 10 types of people in this world, those that understand binary,
and those that don't.