Cor said:
Where, you do real suprise me, that is something I never would write not
even in the slightest way, I have absolute the oposite opinion and thought
that I have often told that in this thread.
Are you not mixing up this thread with another one?
Absolutely not. Here's what you wrote:
"In my opinion the goal should be that it is not necessary to learn
basic
things."
Reference type semantics count as "basic things" IMO, which means that
to me you're suggesting that it shouldn't be necessary to learn
reference type semantics. As people don't tend to be born with a
knowledge of reference type semantics, anyone who is in the state of
understanding reference type semantics must have learned them.
Therefore, the quote above implies that you believe people shouldn't
need to know reference type semantics. It's pretty simple reasoning.
That's *not* a good goal IMO. Programming without understanding the
basics is never going to be a good idea.
I try all the time to tell you in this thread that reference type itself is
not the topic.
We disagree. Julie didn't understand what was going on because she
apparently thought it was the *object* that was being passed by value,
not the *reference* - until she was reminded. When she was reminded
about reference type semantics, it was obvious to her how the code
worked, as far as I can tell.
Yes but it is not stated that the reference is only usefull as parameter in
a Method as you all the time are suggesting. The reference has more
purposes..
I haven't stated (not even once, let alone "all the time") that
references are only used as parameters. Could you point out where I
supposedly stated that?
Wow. I suspect we'll have to agree to disagree on this then.
That's no good if you want to want to copy stuff into an existing
array, however - which is often the case.
Consider reading data from a stream. The normal way of doing this is to
create a single buffer, and repeatedly read into it. Presumably you
object to Stream.Read's signature as well, thinking it should always
return a new buffer?
You can pass 5 parameters to a sub and do nothing with it that has to be
returned.
I never claimed that it did. I was making the point that every part of
a message signature should be useful (assuming you have complete
control over the signature). Whether parameters are used or not was
another example of this. I hope you would agree that it's confusing to
have parameters which aren't used?
In any other way I find it C like programming, however I have the idea that
some mean that every method that has been used in C is OOP.
You seem to blame a lot of things you don't like on C, whether or not
it has any basis on reality. (As an example, you have repeatedly
claimed that C# has "legacy functions" from C, and have always failed
to provide any examples.)
This has nothing to do with C, and everything to do with the idea that
not all method parameters should be effectively immutable within the
method. Yes, you need to document what changes will occur, but when the
point is quite often *solely* to change the object, I don't think
there's anything wrong with it.
Furthermore, I think it's *bad* to change a method to make it *look*
like it won't be changing the object referred to by the parameter, when
actually you still do. That's the effect the change you suggested would
have (where you just return a reference to the same object, having
changed the contents).
Will I send you a program written with Dutch names and only Program language
semantic in English?
If a program becomes documentation or intelisence dependend, than it has the
criteria for me to be suspicious.
Whereas for me it's suspicious if you don't have the documentation, or
it's inaccurate. There are *lots* of things which essentially require
documentation. In particular, when you don't understand something, that
should be the first place you look.
Can you reprash this because probably I don't understand it, it sounds so
strange for me that you can state this. I assume that you know that in a non
void method only the declared type is returned.
Of course. If you write a method which declares that it will return
something, I will assume there's a reason for that - that you're
providing me with more information than I had before. If I've passed
you a reference as a parameter, I clearly know what that reference is.
Therefore the implication is that you at least might return something
*other* than that reference - suggesting that you'd be copying the data
before modifying the copy and returning a reference to it.
(There is one exception to this, which is when a reference is returned
for the purposes of chaining, such as new
StringBuilder().Append("foo").Append("bar") etc. That's a different
case though.)
However every direct or indirect passed reference can be changed. That is
something that gives in my idea the misunderstandings and as I think about
it now should be prohibited. Because it is very easy to return any object or
structure.
So in order to effectively change *anything* in any parameter, you'd
have to copy the entirety of the data. Consider my StringBuilder
example again (I say "again" - you haven't even mentioned it yet).
Would you create a copy of the StringBuilder? I suspect you'll ignore
this paragraph too, but if you could address this issue it would really
get to the bottom of things, I think.
Note again that you specifically went against your own advice when you
suggested the change to Julie's method - you didn't suggest that the
data should be copied. You went ahead and changed the object - the only
difference was that you returned a reference at the end. How is that
any better?
Jon
