I'm supporting an application at work. Below are some code segments
that I can't understand how they work. First let me say, I would never
code this standard. I'm just really creeped out that it works.
Here's the setup. I have a function, called GetEmployeeCertifications,
that is going to make a call to a SQL DB and return a result set. This
module calls another function, called FillParameters, to determine if
SQL parameters need to be appended to the command object. The
FillParameters function...
does not have a return value
the command object is not globally defined
and the command object is passed by value not reference
But yet the command object, in the GetEmployeeCertifications function,
has appended to it the parameter objects from the FillParameters
function. How can that be?
Public Shared Function GetEmployeeCertifications(ByVal criteria As
SearchCriteria) As EmployeeCertificationCollection
Dim tblEmployees As New DataTable
Dim connection As New SqlConnection(connectionString)
Dim cmdGetEmployees As New SqlCommand
Dim myDataAdapter As New SqlDataAdapter
Dim employees As New EmployeeCertificationCollection
Try
connection.Open()
cmdGetEmployees.Connection = connection
cmdGetEmployees.CommandText = "GetEmployeeCertifications"
cmdGetEmployees.CommandType = CommandType.StoredProcedure
FillParameters(criteria, cmdGetEmployees) '<---Here is the
call with no assignment
myDataAdapter.SelectCommand = cmdGetEmployees
myDataAdapter.Fill(tblEmployees)
Catch ex As Exception
Finally
'convert the matching data rows to an
EmployeeCertificationCollection
If Not tblEmployees Is Nothing Then
Dim row As DataRow
For Each row In tblEmployees.Rows
employees.Add(GetEmployeeCertification(row))
Next
End If
End Try
'If they searched by cost center, then return the results
sorted by cost center.
'The results come back from the database ordered by last name.
If criteria.CostCenterFrom.Length 0 Or
criteria.CostCenterTo.Length 0 Then
employees.ApplySort("CostCenter",
ComponentModel.ListSortDirection.Ascending)
End If
Return employees
End Function
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand)
If criteria.LastName.Length 0 Then
cmd.Parameters.Add(New SqlParameter("@LastName",
SqlEscape(criteria.LastName)))
End If
If Not (criteria.SiteCode = "ALL" Or criteria.SiteCode.Length =
0) Then
cmd.Parameters.Add(New SqlParameter("@SiteCode",
criteria.SiteCode))
End If
End Function
52  3147 
Julie <ju**********@yahoo.comwrote:
I'm supporting an application at work. Below are some code segments
that I can't understand how they work. First let me say, I would never
code this standard. I'm just really creeped out that it works.
Here's the setup. I have a function, called GetEmployeeCertifications,
that is going to make a call to a SQL DB and return a result set. This
module calls another function, called FillParameters, to determine if
SQL parameters need to be appended to the command object. The
FillParameters function...
does not have a return value
the command object is not globally defined
and the command object is passed by value not reference
You're confused about parameter passing, basically. See http://www.pobox.com/~skeet/csharp/parameters.html
It's written in terms of C#, but the principle is the same - even when
a parameter is passed by value, if it's a reference type (such as
SqlCommand) it's the *reference* which is passed. Changes to the object
made via that reference are still visible to the caller after the
method has terminated.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
FillParameters(criteria, cmdGetEmployees) '<---Here is the
call with no assignment
This is a call by reference. A Command object is by reference always.
So the parameters are filled using the reference.
Jesse
Jesse Houwing <je***********@nospam-sogeti.nlwrote:
FillParameters(criteria, cmdGetEmployees) '<---Here is the
call with no assignment
This is a call by reference. A Command object is by reference always.
No, the object isn't passed at all. There's a different between passing
an object by reference and passing a reference by value. See http://www.pobox.com/~skeet/csharp/parameters.html for more on this.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
Thanks for the refresher on reference types vs value types. The
confusion comes in on the variable definition in the function name with
the explicit ByVal keyword.
A variable can be assigned a reference. A second variable can be
assigned the value of first. "They are still, however, independent
variables themselves. Changing the value of first will not change the
value of second". But change the value of the object using the first
variable will change the second.
StringBuilder first = new StringBuilder();
StringBuilder second = first;
first.Append ("hello");
first = null;
Console.WriteLine (second);
Hello will still print because second is a variable whose address
points to an area in core that contains hello. While first has
released its address.
HERE IS MY DISCONNECT
The variable cmd is defined as a SQL command type object. But the
ByValue keyword threw me as we are passing the pointer not creating a
duplicate object. It is possible to create and object in memory that
has the same contents as another object in memory. Thus cmd and
cmdGetEmployees are two different variables pointing to the same
object.
So in the FillParameters function what would have happened if I had
ByVal with a new keyword?
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As new SqlCommand)
Thanks for the whack upside the head.
J
Jon wrote:
Jesse Houwing <je***********@nospam-sogeti.nlwrote:
FillParameters(criteria, cmdGetEmployees) '<---Here is the
call with no assignment
This is a call by reference. A Command object is by reference always.
No, the object isn't passed at all. There's a different between passing
an object by reference and passing a reference by value. See
http://www.pobox.com/~skeet/csharp/parameters.html for more on this.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Julie <ju**********@yahoo.comwrote:
<snip>
So in the FillParameters function what would have happened if I had
ByVal with a new keyword?
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As new SqlCommand)
I'm afraid I don't know enough VB.NET to understand that syntax - it
doesn't seem to make sense judging by the documentation.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
No, the object isn't passed at all. There's a different between passing
an object by reference and passing a reference by value. See
That was in my idea not written by Jesse. I think that we are blind as soon
as we read "reference".
A reference type is always passing in any way an address as the reference
not the complete object.
:-)
Cor
Julie,
Do you know why this methode declaration bellow does not give an error. You
write this as a Sub, which should work, but better is it to avoid this in
this kind of situations where you are changing values inside a Sub.
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand)
Try to avoid this, try to return what has to be returned, that makes your
program at least more readable.
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand) as SqlCommand
....
return cmd
And than in your code
cmdGetEmloyees = FillParameters(criteria, cmdGetEmployees)
However the strangest in your code is for me that function whithout return
value.
I hope this helps,
"Julie" <ju**********@yahoo.comschreef in bericht
news:11*********************@m73g2000cwd.googlegro ups.com...
I'm supporting an application at work. Below are some code segments
that I can't understand how they work. First let me say, I would never
code this standard. I'm just really creeped out that it works.
Here's the setup. I have a function, called GetEmployeeCertifications,
that is going to make a call to a SQL DB and return a result set. This
module calls another function, called FillParameters, to determine if
SQL parameters need to be appended to the command object. The
FillParameters function...
does not have a return value
the command object is not globally defined
and the command object is passed by value not reference
But yet the command object, in the GetEmployeeCertifications function,
has appended to it the parameter objects from the FillParameters
function. How can that be?
Public Shared Function GetEmployeeCertifications(ByVal criteria As
SearchCriteria) As EmployeeCertificationCollection
Dim tblEmployees As New DataTable
Dim connection As New SqlConnection(connectionString)
Dim cmdGetEmployees As New SqlCommand
Dim myDataAdapter As New SqlDataAdapter
Dim employees As New EmployeeCertificationCollection
Try
connection.Open()
cmdGetEmployees.Connection = connection
cmdGetEmployees.CommandText = "GetEmployeeCertifications"
cmdGetEmployees.CommandType = CommandType.StoredProcedure
FillParameters(criteria, cmdGetEmployees) '<---Here is the
call with no assignment
myDataAdapter.SelectCommand = cmdGetEmployees
myDataAdapter.Fill(tblEmployees)
Catch ex As Exception
Finally
'convert the matching data rows to an
EmployeeCertificationCollection
If Not tblEmployees Is Nothing Then
Dim row As DataRow
For Each row In tblEmployees.Rows
employees.Add(GetEmployeeCertification(row))
Next
End If
End Try
'If they searched by cost center, then return the results
sorted by cost center.
'The results come back from the database ordered by last name.
If criteria.CostCenterFrom.Length 0 Or
criteria.CostCenterTo.Length 0 Then
employees.ApplySort("CostCenter",
ComponentModel.ListSortDirection.Ascending)
End If
Return employees
End Function
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand)
If criteria.LastName.Length 0 Then
cmd.Parameters.Add(New SqlParameter("@LastName",
SqlEscape(criteria.LastName)))
End If
If Not (criteria.SiteCode = "ALL" Or criteria.SiteCode.Length =
0) Then
cmd.Parameters.Add(New SqlParameter("@SiteCode",
criteria.SiteCode))
End If
End Function
Cor Ligthert [MVP] <no************@planet.nlwrote:
No, the object isn't passed at all. There's a different between passing
an object by reference and passing a reference by value. See
That was in my idea not written by Jesse. I think that we are blind as soon
as we read "reference".
A reference type is always passing in any way an address as the reference
not the complete object.
Yes, but Jesse claimed that the object was passed by reference. It
isn't. It isn't passed at all. There are well-defined meaning to "pass
by reference", and ByVal semantics aren't the same, even when what is
passed is a reference.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
Do you know why this methode declaration bellow does not give an error. You
write this as a Sub, which should work, but better is it to avoid this in
this kind of situations where you are changing values inside a Sub.
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand)
Try to avoid this, try to return what has to be returned, that makes your
program at least more readable.
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand) as SqlCommand
...
return cmd
And than in your code
cmdGetEmloyees = FillParameters(criteria, cmdGetEmployees)
However the strangest in your code is for me that function whithout return
value.
Why is that strange? To me, it would be very odd to return the command
when there's no need for it. Why have a return value when it's
unnecessary? *That* would make the code less readable IMO.
Rather than pretending that the return value is important, it's better
to understand reference type semantics. What would you do when the
method modified the objects referred to by two of its parameters? You
can't return them both, so you get back to the same problem of
understanding.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
Did you try this ever in C: to call a function
Void(Skeet skeet){}
in VB as I have this right almost the same as
Function(byval skeet as Skeet)
Maybe this goes in C# but it is no VB code
(As many things in VB it goes with Option Strict Off but that I have in my
opions already set on On)
In VB you use for the void methods SUB
(There are voices to change that and make a return with an empty return a
Sub)
But there is very much nostaligy in VB. By instance I don't see any reason
to use the Dim.
In 20% of the syntax it is told already by the "As" keyword.
(For a as integer etc)
To return more parameters,
Use a class object
What would you do if this class is a seperate DLL how do you decribe your
intelisence.
Something as "your values are changed in the DLL".
Cor
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Cor Ligthert [MVP] <no************@planet.nlwrote:
>Do you know why this methode declaration bellow does not give an error.
You
write this as a Sub, which should work, but better is it to avoid this in
this kind of situations where you are changing values inside a Sub.
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand)
Try to avoid this, try to return what has to be returned, that makes your
program at least more readable.
Private Shared Function FillParameters(ByVal criteria As
SearchCriteria, ByVal cmd As SqlCommand) as SqlCommand
...
return cmd
And than in your code
cmdGetEmloyees = FillParameters(criteria, cmdGetEmployees)
However the strangest in your code is for me that function whithout
return
value.
Why is that strange? To me, it would be very odd to return the command
when there's no need for it. Why have a return value when it's
unnecessary? *That* would make the code less readable IMO.
Rather than pretending that the return value is important, it's better
to understand reference type semantics. What would you do when the
method modified the objects referred to by two of its parameters? You
can't return them both, so you get back to the same problem of
understanding.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] wrote:
<snip>
It seems that you have two concerns:
1) The contents of the parameter being modified.
2) A function being used instead of a sub.
The second point is reasonable, but the best approach is to turn the
function into a sub, rather than to add a pointless return value. Now,
for the first point:
To return more parameters,
Use a class object
So you'd start encapsulating every permutation of types which change,
just for the sake of returning them *when they don't even need to be
returned in the first place*?
Moreover, you're then confusing things, because it *looks* like you
won't actually change the objects which are referred to by the
parameters. Suppose I did this:
filledCommand = FillParameters (unfilledCommand)
That looks like unfilledCommand won't be changed, even though it will!
What would you do if this class is a seperate DLL how do you decribe your
intelisence.
Something as "your values are changed in the DLL".
Well, they're not changed "in the DLL" but the values of the object are
indeed changed, wherever the type has been loaded from. Look at the
documentation for DataAdapter.Fill for a perfect example of this. You
pass in a reference to a DataSet, and that DataSet gets filled. The
number of rows added or refreshed happens to be returned, but that's
pretty much incidental. Why is that any different to filling a Command
object?
Jon
Jon,
Look at the
documentation for DataAdapter.Fill for a perfect example of this. You
pass in a reference to a DataSet, and that DataSet gets filled. The
number of rows added or refreshed happens to be returned, but that's
pretty much incidental. Why is that any different to filling a Command
object?
Exactly.
While with filling is meant in this black box adding and not returning the
asked resultset as one of the misunderstanding of this black box, but it
keeps the newsgroups and forums filled.
:-)
Cor
Jon/Cor
Thank you both for your input. Remember I did write this code, but I
do have to support it. And the one thing I LOVE about this industry is
your always learning.
I believe at this point, the thread has become more about programming
style. Should the Function be a Subroutine? Yes, IMO it should be
because it doesn't return a value but does affect the area of core
being pointed to by two different variables. Having been an Assembler
programmer (and yes I did do C/C++/Java a lifetime ago), I can
appreciate not duplicating stored values and using reference. But
there were two other programmers at the site that were confused by the
code (one of them has is roots in C#.Net and is trying to learn VB.Net)
In the technical design and construction of any application there is
the bread vs. bullets syndrome, except its call Maintainability verses
Efficiency. Is it more readable to have a return type even if the
values are modified by reference? Yes. Again, IMO it is more readable
and helps the other developers visual see the flow. I have used
reference before, so I should have figured this out without the slap
upside the head =).
If there is one thing I want to take away from this is "it doesn't take
a genius to know everything, just know where to find the right
answers". And if you do get an answer, learn from it. If you still
don't understand the answer, look at the question again.
Thank you both. I love this group.
J
Jon Skeet [C# MVP] wrote:
Cor Ligthert [MVP] wrote:
<snip>
It seems that you have two concerns:
1) The contents of the parameter being modified.
2) A function being used instead of a sub.
The second point is reasonable, but the best approach is to turn the
function into a sub, rather than to add a pointless return value. Now,
for the first point:
To return more parameters,
Use a class object
So you'd start encapsulating every permutation of types which change,
just for the sake of returning them *when they don't even need to be
returned in the first place*?
Moreover, you're then confusing things, because it *looks* like you
won't actually change the objects which are referred to by the
parameters. Suppose I did this:
filledCommand = FillParameters (unfilledCommand)
That looks like unfilledCommand won't be changed, even though it will!
What would you do if this class is a seperate DLL how do you decribe your
intelisence.
Something as "your values are changed in the DLL".
Well, they're not changed "in the DLL" but the values of the object are
indeed changed, wherever the type has been loaded from. Look at the
documentation for DataAdapter.Fill for a perfect example of this. You
pass in a reference to a DataSet, and that DataSet gets filled. The
number of rows added or refreshed happens to be returned, but that's
pretty much incidental. Why is that any different to filling a Command
object?
Jon
Cor Ligthert [MVP] wrote:
Look at the
documentation for DataAdapter.Fill for a perfect example of this. You
pass in a reference to a DataSet, and that DataSet gets filled. The
number of rows added or refreshed happens to be returned, but that's
pretty much incidental. Why is that any different to filling a Command
object?
Exactly.
While with filling is meant in this black box adding and not returning the
asked resultset as one of the misunderstanding of this black box, but it
keeps the newsgroups and forums filled.
Whereas pretending that you're going to only return a different object
while keeping the original one pristine, but actually modifying it
in-place to keep things efficient would be better, would it?
It's fair enough that people don't always understand parameter passing
semantics, but they're good semantics which aren't that hard to explain
when people *do* misunderstand them, and which allow much more
efficient designs than would otherwise be possible. Not using those
semantics is flying in the face of the philosophy of .NET.
Jon
Julie wrote:
In the technical design and construction of any application there is
the bread vs. bullets syndrome, except its call Maintainability verses
Efficiency. Is it more readable to have a return type even if the
values are modified by reference? Yes. Again, IMO it is more readable
and helps the other developers visual see the flow. I have used
reference before, so I should have figured this out without the slap
upside the head =).
I still find it hard to accept that it's more readable. If a method
returns something, I will assume there's a reason for it returning it -
that it gives me more information than I had before. If a method is
returning an object which is of the same type as one of the parameters,
I may make an assumption that it's returning a reference to a *new*
object, and that the "old" has remained untouched. That wouldn't be the
case here. At this point, you've effectively misled the caller - which
is exactly what readable code is meant to avoid.
The idiom of modifying parameters is pretty common, and I don't think
we should try to avoid people having to learn it by pretending we're
doing something we're not.
Jon
Jon,
What do I always write about maintainability and you about effeciency?
That efficiency is probably here however even a piece of not to measurable
time, even if you do it a million time. As you wrote yourself, you are only
passing a reference.
I am with those who find this not so a nice philosopyy of .Net.
But I thought that I once read that it is the toy of the the architect of
that.
Cor
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:11**********************@b68g2000cwa.googlegr oups.com...
Cor Ligthert [MVP] wrote:
> Look at the
documentation for DataAdapter.Fill for a perfect example of this. You
pass in a reference to a DataSet, and that DataSet gets filled. The
number of rows added or refreshed happens to be returned, but that's
pretty much incidental. Why is that any different to filling a Command
object?
Exactly.
While with filling is meant in this black box adding and not returning
the
asked resultset as one of the misunderstanding of this black box, but
it
keeps the newsgroups and forums filled.
Whereas pretending that you're going to only return a different object
while keeping the original one pristine, but actually modifying it
in-place to keep things efficient would be better, would it?
It's fair enough that people don't always understand parameter passing
semantics, but they're good semantics which aren't that hard to explain
when people *do* misunderstand them, and which allow much more
efficient designs than would otherwise be possible. Not using those
semantics is flying in the face of the philosophy of .NET.
Jon
Cor Ligthert [MVP] <no************@planet.nlwrote:
What do I always write about maintainability and you about effeciency?
I think you must have missed the many, many times I've written about
maintainability and readability. I am interested in efficiency in
coarse terms (like not copying objects unnecessarily) but
maintainability is key. I think your suggestion *reduces*
maintainability rather than increasing it though.
That efficiency is probably here however even a piece of not to measurable
time, even if you do it a million time. As you wrote yourself, you are only
passing a reference.
But in order to make the method do what you *imply* it does (i.e. leave
the original object alone) you need to clone the object. If you do
that, it's inefficient. If you don't do that, your method is
effectively lying to the reader, which is reducing the readbility.
I am with those who find this not so a nice philosopyy of .Net.
What, reference type semantics? Can you find any articles on the web
suggesting that .NET shouldn't have reference types, or be able to
modify objects whose references are passed as parameters?
But I thought that I once read that it is the toy of the the architect of
that.
Not sure what you mean by that.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
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.
You can call this inefficiency. I thinkt that consistent use makes programs
it better to understand.
I have used that black box method myself until I forgot what I was doing in
a method.
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 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).
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.
Just my idea,
Cor
..
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Cor Ligthert [MVP] <no************@planet.nlwrote:
>What do I always write about maintainability and you about effeciency?
I think you must have missed the many, many times I've written about
maintainability and readability. I am interested in efficiency in
coarse terms (like not copying objects unnecessarily) but
maintainability is key. I think your suggestion *reduces*
maintainability rather than increasing it though.
>That efficiency is probably here however even a piece of not to
measurable
time, even if you do it a million time. As you wrote yourself, you are
only
passing a reference.
But in order to make the method do what you *imply* it does (i.e. leave
the original object alone) you need to clone the object. If you do
that, it's inefficient. If you don't do that, your method is
effectively lying to the reader, which is reducing the readbility.
>I am with those who find this not so a nice philosopyy of .Net.
What, reference type semantics? Can you find any articles on the web
suggesting that .NET shouldn't have reference types, or be able to
modify objects whose references are passed as parameters?
>But I thought that I once read that it is the toy of the the architect of
that.
Not sure what you mean by that.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
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 - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
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.
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.
:-)
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.
:-)
Cor
Cor Ligthert [MVP] <no************@planet.nlwrote:
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 - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Cor Ligthert [MVP] <no************@planet.nlwrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] wrote:
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.
I'm not off the point at all. My StringBuilder analogy is *exactly*
equivalent to the SqlCommand situation - and I note you didn't say
whether or not you'd make a copy.
Do you not accept that if people assume incorrectly that if the
parameter is ByVal then the object can't be changed, then appending to
the StringBuilder that's passed in may surprise them - possibly late?
Why pretend anything is happening other than what is *truly* happening?
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.
But if you assume that people don't understand reference types, and try
to work round that lack of knowledge by returning things unnecessarily,
you tie yourself in knots as I think I've demonstrated.
Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."
See how instead of increasing readability it's actually reducing it?
It's obscuring the true nature of the method. At some point or another,
people *have* to learn reference type semantics, or they will flounder.
I would prefer to make them learn the truth early rather than postpone
that time by pretending that they don't need to know anything, and that
the way they might incorrectly think things are passed is in fact the
truth.
Jon
Jon,
Maybe I disappoint you, I know what a reference type is and others do
probably as well (at least Juli showed that as well), but that is not the
question.
The question is if you should in our eyes misuse the behaviour of the
reference type.
However,
Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."
It has nothing to do with understand it.
As there is in a void something (in a large program) that changes the
referenced object, than if that is not expected, it can take a long time to
find that. If the reference is returned you have a hint that it can be (and
mostly is) changed.
Cor
..
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:11**********************@p79g2000cwp.googlegr oups.com...
Cor Ligthert [MVP] wrote:
>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.
I'm not off the point at all. My StringBuilder analogy is *exactly*
equivalent to the SqlCommand situation - and I note you didn't say
whether or not you'd make a copy.
Do you not accept that if people assume incorrectly that if the
parameter is ByVal then the object can't be changed, then appending to
the StringBuilder that's passed in may surprise them - possibly late?
Why pretend anything is happening other than what is *truly* happening?
>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.
But if you assume that people don't understand reference types, and try
to work round that lack of knowledge by returning things unnecessarily,
you tie yourself in knots as I think I've demonstrated.
Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."
See how instead of increasing readability it's actually reducing it?
It's obscuring the true nature of the method. At some point or another,
people *have* to learn reference type semantics, or they will flounder.
I would prefer to make them learn the truth early rather than postpone
that time by pretending that they don't need to know anything, and that
the way they might incorrectly think things are passed is in fact the
truth.
Jon
Cor Ligthert [MVP] wrote:
Maybe I disappoint you, I know what a reference type is and others do
probably as well (at least Juli showed that as well), but that is not the
question.
I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.
The question is if you should in our eyes misuse the behaviour of the
reference type.
The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.
Tell me, do you think the Array.Copy method is "misuse"?
However,
Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."
It has nothing to do with understand it.
Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.
As there is in a void something (in a large program) that changes the
referenced object, than if that is not expected, it can take a long time to
find that.
But it *should* be expected due to the method name and documentation.
If the reference is returned you have a hint that it can be (and
mostly is) changed.
On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.
Jon
Jon,
I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.
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?
I try all the time to tell you in this thread that reference type itself is
not the topic.
>The question is if you should in our eyes misuse the behaviour of the
reference type.
The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.
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..
Tell me, do you think the Array.Copy method is "misuse"?
Yes
I like it more as this (but this one is newer) http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx
>However,
Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."
It has nothing to do with understand it.
Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.
You can pass 5 parameters to a sub and do nothing with it that has to be
returned.
\\\
Option strict off
Private sub A (byval a as integer, byval b as integer, byval c as integer,
byval d as object, byval f as object)
Messagebox.show (a * b * c * d * f) 'can be write, print, sent or whatever
End sub
///
' that is where a sub in my opinion has to be 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.
>As there is in a void something (in a large program) that changes the
referenced object, than if that is not expected, it can take a long time
to
find that.
But it *should* be expected due to the method name and documentation.
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.
>If the reference is returned you have a hint that it can be (and
mostly is) changed.
On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.
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.
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.
Cor
Jon,
Before you misunderstand me, that is as I think about it now.
Because of backwards compatibility it is of course impossible still to
implement this in VBNet or C#.
Cor
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:11**********************@v61g2000cwv.googlegr oups.com...
Cor Ligthert [MVP] wrote:
>Maybe I disappoint you, I know what a reference type is and others do
probably as well (at least Juli showed that as well), but that is not the
question.
I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.
>The question is if you should in our eyes misuse the behaviour of the
reference type.
The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.
Tell me, do you think the Array.Copy method is "misuse"?
>However,
Furthermore, it only goes to confuse people who *do* understand
reference types. The first question I'd be asking myself is, "Why is
this returning anything? There's no point if it's just modifying the
object whose reference I'm passing in. Maybe it's copying the object
instead..."
It has nothing to do with understand it.
Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.
>As there is in a void something (in a large program) that changes the
referenced object, than if that is not expected, it can take a long time
to
find that.
But it *should* be expected due to the method name and documentation.
>If the reference is returned you have a hint that it can be (and
mostly is) changed.
On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.
Jon
Cor Ligthert [MVP] wrote:
I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.
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.
The question is if you should in our eyes misuse the behaviour of the
reference type.
The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.
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?
Tell me, do you think the Array.Copy method is "misuse"?
Yes
Wow. I suspect we'll have to agree to disagree on this then.
I like it more as this (but this one is newer)
http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx
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?
Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.
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).
But it *should* be expected due to the method name and documentation.
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.
If the reference is returned you have a hint that it can be (and
mostly is) changed.
On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.
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
Barry,
DataView.ToTable() instance method - it doesn't take any arguments, so
it appears not to be relevant to the discussion as I understood it.
May I asked why you did not answer this to Jon when he did the same with the
CopyTo method, but your statement is wrong. http://msdn2.microsoft.com/en-us/library/h2b6ehaa.aspx
Cor
"Barry Kelly" <ba***********@gmail.comschreef in bericht
news:kr********************************@4ax.com...
"Cor Ligthert [MVP]" <no************@planet.nlwrote:
>I like it more as this (but this one is newer)
http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx
DataView.ToTable() instance method - it doesn't take any arguments, so
it appears not to be relevant to the discussion as I understood it.
-- Barry
--
http://barrkel.blogspot.com/
Jon,
See my other answer in this thread, it becomes to long, for me is it "I
wished it was".
Therefore I stop with this.
Maybe we discuss this again in future when we both have given our thoughts
some time.
Cor
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:11**********************@l70g2000cwa.googlegr oups.com...
Cor Ligthert [MVP] wrote:
I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.
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.
>The question is if you should in our eyes misuse the behaviour of the
reference type.
The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.
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?
Tell me, do you think the Array.Copy method is "misuse"?
Yes
Wow. I suspect we'll have to agree to disagree on this then.
>I like it more as this (but this one is newer)
http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx
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?
Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.
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).
But it *should* be expected due to the method name and documentation.
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.
>If the reference is returned you have a hint that it can be (and
mostly is) changed.
On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.
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
Jon,
A single addition, this has nothing to do with C# or VBNet, if my wishes are
right, than they both suffer from legacy in this.
Cor
"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:11**********************@l70g2000cwa.googlegr oups.com...
Cor Ligthert [MVP] wrote:
I've never suggested that you didn't understand reference type
semantics. However, you've said that you don't think people ought to
*need* to understand them - and that I take issue with.
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.
>The question is if you should in our eyes misuse the behaviour of the
reference type.
The ability to read and modify data within an object via a reference is
part of the crucial semantics of a reference type.
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?
Tell me, do you think the Array.Copy method is "misuse"?
Yes
Wow. I suspect we'll have to agree to disagree on this then.
>I like it more as this (but this one is newer)
http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx
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?
Of course it does. It has everything to do with it, because I expect
that every part of a method signature is there for a purpose. If I
declare a method which takes 5 parameters, I expect all those
parameters to be useful. Likewise, if I declare that a method will
return something, there'd better be a good *reason* for it returning
it.
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).
But it *should* be expected due to the method name and documentation.
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.
>If the reference is returned you have a hint that it can be (and
mostly is) changed.
On the contrary - if something returns a reference, I'd expect that any
new data is in the object whose reference is returned. Returning a
reference in *no* way hints that one of the parameters has had its
contents changed. It just confuses the matter.
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
"Cor Ligthert [MVP]" <no************@planet.nlwrote:
Barry wrote:
DataView.ToTable() instance method - it doesn't take any arguments, so
it appears not to be relevant to the discussion as I understood it.
May I asked why you did not answer this to Jon when he did the same with the
CopyTo method, but your statement is wrong.
http://msdn2.microsoft.com/en-us/library/h2b6ehaa.aspx
This is a different overload - as far as I know, the factual statement I
made ( http://msdn2.microsoft.com/en-us/library/a8ycds2f.aspx referring
to DataView.ToTable() instance method not taking any arguments) was
correct.
This one you now point to has no need to modify its arguments - its
purpose is to create a new instance. It doesn't mutate the values that
the caller passes it, so as far as I understood the discussion, I still
don't see how it's relevant.
Not to worry.
-- Barry
-- http://barrkel.blogspot.com/
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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
>Cor Ligthert [MVP] <no************@planet.nlwrote:
>>>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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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" <gu***@guffa.comschreef in bericht
news:Oa*************@TK2MSFTNGP03.phx.gbl...
>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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft. com...
>>Cor Ligthert [MVP] <no************@planet.nlwrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
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.
But the problem is that your reason is that it would be good to do if
it weren't for backward compatibility - whereas Goran and I think that
it's good that it's possible to modify the object an argument refers
to.
Furthermore, Goran's main point, it seemed to me, was that without a
return value it's pretty obvious that the method modifies the object.
*With* a return value it's a lot less obvious exactly what's going to
happen.
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...)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Doh,
My latest message can be misunderstood, I stated that I wished that it was
in another way but that it is impossible to do now with the languages C# and
VBNet because of backward compatibility.
Cor
"Göran Andersson" <gu***@guffa.comschreef in bericht
news:Oa*************@TK2MSFTNGP03.phx.gbl...
>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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft. com...
>>Cor Ligthert [MVP] <no************@planet.nlwrote:
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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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" <gu***@guffa.comschreef in bericht
news:Oa*************@TK2MSFTNGP03.phx.gbl...
>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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft .com...
Cor Ligthert [MVP] <no************@planet.nlwrote:
>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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Jon,
Furthermore, Goran's main point, it seemed to me, was that without a
return value it's pretty obvious that the method modifies the object.
*With* a return value it's a lot less obvious exactly what's going to
happen.
I have no idea why you state this, it is in my opinion not true, it is
possible to do in both exactly the same with a referenced object. I *wished*
that it was in both probihited
>
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 think you are mixing me up with somebody else, this is typical Herfried.
Maybe it was that in my opinion using static/shared classes is not real OOP
beside the main module. (I said *my opinion* everybody may have another
opinion).
I think that the module in VBNet is better to use for shared classes, but
than not as dumb written as mostly is done, I find this is a much nicer
resolution in VBNet. (This is an opinion just from the last month).
Module mymodule
Public Sub whatever(byval myobject as object) 'I Would normally never use
object but to keep it short.
messagebox.show(myobject.ToString)
End sub.
end module
This can be referenced as mymodule.whatever("I find this nicer")
Cor
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
"Göran Andersson" <gu***@guffa.comschreef in bericht
news:OX**************@TK2MSFTNGP05.phx.gbl...
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" <gu***@guffa.comschreef in bericht
news:Oa*************@TK2MSFTNGP03.phx.gbl...
>>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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsof t.com...
Cor Ligthert [MVP] <no************@planet.nlwrote:
>>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 - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
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 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/micro...nguages.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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] wrote:
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
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" <gu***@guffa.comschreef in bericht
news:OX**************@TK2MSFTNGP05.phx.gbl...
>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" <gu***@guffa.comschreef in bericht
news:Oa*************@TK2MSFTNGP03.phx.gbl...
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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microso ft.com...
>Cor Ligthert [MVP] <no************@planet.nlwrote:
>>>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 - <sk***@pobox.com>
>http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
>If replying to the group, please do not mail me too
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/micro...nguages.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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Cor Ligthert [MVP] <no************@planet.nlwrote:
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 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/micro...nguages.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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
http://groups.google.com/group/micro...nguages.vb/bro
wse_frm/thread/4ae51a3df8cf5165/258510a78bdd119f
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.
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.
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/micro...nguages.vb/msg
/794fa45690ccec72
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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
>>
>>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" <gu***@guffa.comschreef in bericht
news:OX**************@TK2MSFTNGP05.phx.gbl...
>>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" <gu***@guffa.comschreef in bericht
news:Oa*************@TK2MSFTNGP03.phx.gbl...
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]" <sk***@pobox.comschreef in bericht
>news:MP************************@msnews.micros oft.com...
>>Cor Ligthert [MVP] <no************@planet.nlwrote:
>>>>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 - <sk***@pobox.com>
>>http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
>>If replying to the group, please do not mail me too
Jon,
>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/micro...nguages.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]" <sk***@pobox.comschreef in bericht
news:MP************************@msnews.microsoft.c om...
Cor Ligthert [MVP] <no************@planet.nlwrote:
http://groups.google.com/group/micro...nguages.vb/bro
wse_frm/thread/4ae51a3df8cf5165/258510a78bdd119f
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.
>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.
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/micro...nguages.vb/msg
/794fa45690ccec72
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Cor Ligthert [MVP] <no************@planet.nlwrote:
You couldn't find the text I quoted? See
http://groups.google.com/group/micro...nguages.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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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 wrote:
Cor Ligthert [MVP] <no************@planet.nlwrote:
You couldn't find the text I quoted? See
>
http://groups.google.com/group/micro...nguages.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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jonas |
last post by:
This works fine in Win XP but does not work at all in Win 98.
Private WithEvents objIExplorer As InternetExplorer
I have to do it like this to get it to work in Win 98
Dim objIExplorer As...
|
by: Paul THompson |
last post by:
I have a piece of code something like the following:
START OF CODE
<html><head><title>The Wizard</title></head>
<body> <h1>Welcome to Joe's Vet Clinic</h1>
<div id="part1"...
|
by: Isaac Grover |
last post by:
Hi everyone,
Just out of curiosity I recently pointed one of my hand-typed pages at the W3
Validator, and my hand-typed code was just ripped to shreds. Then I pointed
some major sites...
|
by: me |
last post by:
I have a Class Library that contains a Form and several helper classes. A
thread gets created that performs processing of data behind the scenes and
the Form never gets displayed (it is for debug...
|
by: rick |
last post by:
The following basic script works fine in firefox by not in IE. Can anyone
spot the problem? In IE I can only delete the first line but not the lines
created by javascript. Also, look at the HTML...
|
by: benb |
last post by:
I have form that looks a lot like a search bar for the user to search
for records matching specified criteria (e.g. first names containing
"ben"). For robust results, an intermediary form displays...
|
by: Anoop |
last post by:
Hi,
I am new to this newsgroup and need help in the following questions.
1. I am workin' on a GUI application. Does C# provides Layout Managers the
way Java does to design GUI? I know that it...
|
by: Cuthbert |
last post by:
After compiling the source code with gcc v.4.1.1, I got a warning
message:
"/tmp/ccixzSIL.o: In function 'main';ex.c: (.text+0x9a): warning: the
'gets' function is dangerous and should not be...
|
by: webEater |
last post by:
I have a problem, it's not browser specific, and I don't get a
solution. I have an (X)HTML document, I show you a part of it:
....
<!--<div class="pad">-->
<div id="eventImages"><img src=""...
|
by: =?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?= |
last post by:
I get the above error in some of the ASP.NET web applications on a
server, and I need some help figuring out how to deal with it.
This is a rather long post, and I hope I have enough details that...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
