Why doesn't ToString require ()

  • Thread starter Thread starter tshad
  • Start date Start date
T

tshad

In VS 2008, why doesn't ToString require "()".

If I have Option Strict On on why can I do both:

selectedIndex.ToString()
selectedIndex.ToString

or

sQuery = temp.ToUpper().IndexOf("friend")
sQuery = temp.ToUpper.IndexOf("friend")

Aren't the parenthesis required?

I can understand that if Option Strict Off, but if it is Option Strict On, I
would have thought you would need the parenthesis as you do in C#.

Thanks,

Tom
 
Why,

The () for an not paramarized procedure is in a way rudimentair, from the
time that programs were entered with a teletype typewriter. There is a lot
more retro in C# then in VB.

Cor
 
tshad said:
In VS 2008, why doesn't ToString require "()".

If I have Option Strict On on why can I do both:

selectedIndex.ToString()
selectedIndex.ToString

or

sQuery = temp.ToUpper().IndexOf("friend")
sQuery = temp.ToUpper.IndexOf("friend")

Aren't the parenthesis required?
Click to expand...

To enclose which parameters?
I can understand that if Option Strict Off, but if it is Option
Strict On, I would have thought you would need the parenthesis as
you do in C#.
Click to expand...

Option Strict is about strict type handling and has nothing to do with this.


Armin
 
VB allows you to omit parentheses in there are no arguments.
VB allows you to add parentheses to property calls that can't have arguments.

VB has a long standing tradition of trying to make sense of any weird quirks
you feel like fostering. It's friendly to you, but not to the programmers
who have to read your code ("why did they put parentheses on this property
call?", "why did they use an instance for this static method call?", etc.).
--
http://www.tangiblesoftwaresolutions.com
C++ to C#
C++ to VB
C++ to Java
VB & C# to Java
Java to VB & C#
Instant C#: VB to C#
Instant VB: C# to VB
Instant C++: VB, C#, or Java to C++/CLI
 
tshad said:
In VS 2008, why doesn't ToString require "()".

If I have Option Strict On on why can I do both:

selectedIndex.ToString()
selectedIndex.ToString

or

sQuery = temp.ToUpper().IndexOf("friend")
sQuery = temp.ToUpper.IndexOf("friend")

Aren't the parenthesis required?
Click to expand...

It's a BASIC thing.

It allows you to use a parameterless method as if it was a property,
eventhough it doesn't really make sense.

It's something that lives on since the time before properties even
existed. In VB (prior to VB.NET) you have always been able to call a
subroutine without the parentheses. Function calls has always needed
parentheses, as there weren't really any parameterless functions before
object orentation.

For some reason this was allowed to live on when VB became VB.NET and
got object oriented.
I can understand that if Option Strict Off, but if it is Option Strict On, I
would have thought you would need the parenthesis as you do in C#.
Click to expand...

Option Strict On doesn't fix every quirk in VB.NET... ;)
 
Göran Andersson said:
It's a BASIC thing.

It allows you to use a parameterless method as if it was a property,
eventhough it doesn't really make sense.

It's something that lives on since the time before properties even
existed. In VB (prior to VB.NET) you have always been able to call a
subroutine without the parentheses. Function calls has always needed
parentheses, as there weren't really any parameterless functions
before object orentation.

For some reason this was allowed to live on when VB became VB.NET and
got object oriented.


Option Strict On doesn't fix every quirk in VB.NET... ;)
Click to expand...

I agree.

and the same thing about C#. We have these discussions at work all the
time. Why doesn't C# to this like VB does or why doesn't VB do that like C#
does.

Thanks,

Tom
 
and the same thing about C#. We have these discussions at work all the
time. Why doesn't C# to this like VB does or why doesn't VB do that like
C# does.
Click to expand...


Maybe because

VB IsNot C#

( !( C# is VB ) )

And so there are a lot more examples :-)

regards

Michel Posseth
 
Michel Posseth said:
Maybe because

VB IsNot C#

( !( C# is VB ) )
Click to expand...

'C# != VB;'. BTW, C# "overloads" the comparison operators ('==', '!=') with
two meanings: Reference comparison for reference types (value comparison
can be achieved using '.Equals(...)') and value comparison for value types.
In this case VB is more consistent and strict than C#.
 
It's a BASIC thing.
It allows you to use a parameterless method as if it was a property,
eventhough it doesn't really make sense.
Click to expand...

And what is a property? Underneath the skin, the "Get" part of a property
is nothing more than a function call with no parameters that returns the
expected value. Makes perfect sense to me.

In all truth, I've never looked at two lines of code like so:

MyStr = SomeClass.Name

and

MyStr = SomeClass.Name()

and thought "oh my, I don't understand the one with/without parentheses,
it's completely unreadable". I doubt that I'd even notice, because I
subconsciously know that both lines do the same thing. I'd much rather just
focus on the code's own readability, use meaningful variable names, and not
have curly braces in so many places that my code looks like ASCII art.

In that sense, I find that VB makes much more sense. :-)
 
Goran,

Who gave you this wisdom?

Cor

Göran Andersson said:
It's a BASIC thing.

It allows you to use a parameterless method as if it was a property,
eventhough it doesn't really make sense.

It's something that lives on since the time before properties even
existed. In VB (prior to VB.NET) you have always been able to call a
subroutine without the parentheses. Function calls has always needed
parentheses, as there weren't really any parameterless functions before
object orentation.

For some reason this was allowed to live on when VB became VB.NET and got
object oriented.


Option Strict On doesn't fix every quirk in VB.NET... ;)
Click to expand...
 
Tom,

An procedure with empty paramaters is most times confusing in C#, "What is a
method and a property?

You can mostly as the method does not tell by instance by words as
"ToString" not do that without using the intelicense, to read the
documentation or to build.

And you don't need to know it at all, it is just returning something, as a
property or by a method.

In my idea those who want those empty parentesis have a cripled mind
foltered by the C doctrine.

Cor
 
Herfried said:
'C# != VB;'. BTW, C# "overloads" the comparison operators ('==', '!=')
with two meanings: Reference comparison for reference types (value
comparison can be achieved using '.Equals(...)') and value comparison
for value types. In this case VB is more consistent and strict than C#.
Click to expand...

Well, that's only half the truth, and hardly even that...

It's not C# that overrides (not overloads) the operators, it's the .NET
framework. The same overrides is used by VB for any classes where it
hasn't implemented it's own custom comparison.

Most reference types doesn't override the comparison operators, so they
use the default comparison for object, which compares the references.
The reference types that does override the comparisons, like the String
class, does it to use value comparison. The Equals method is overridden
to have the same meaning as the == operator.

C# consistently uses the comparisons defined in the framework, while VB
uses it's own comparison for some types, and the framework comparison
for others.
 
Cor said:
Tom,

An procedure with empty paramaters is most times confusing in C#, "What
is a method and a property?
Click to expand...

Methods and properties have different semantics and different purposes.
It's logical that they are used differently.
You can mostly as the method does not tell by instance by words as
"ToString" not do that without using the intelicense, to read the
documentation or to build.
Click to expand...

I see not how you what saying do?
;)
 
"Göran Andersson"
Methods and properties have different semantics and different purposes.
It's logical that they are used differently.
Click to expand...

Seriously Goran, I don't see that logic?

It is the same logic as that you go in a black suit to church.

Cor
 
Cor said:
"Göran Andersson"

Seriously Goran, I don't see that logic?
Click to expand...

Ok, I'll try to explain the difference.

A property of an object is just what it sounds like. It's a value that
you can read and write. Reading or writing a property should generally
not cause any significant work to be done.

A method is where you put code that does some work. You send some values
to the method, it does something, and you get the result back.

To use a method as if it was a property hides the fact that some
significant work might be done.
It is the same logic as that you go in a black suit to church.
Click to expand...

I don't understand what you mean by that. What is it that you are
comparing that to?
 
Goran,

The way you describe a property is in my idea a little bit useless way.
By instance as I set the property of the backcolour of a textbox, then it is
something more then only setting a value, I know that most persons mostly
use it (including I) only as you wrote.

However, why do I need to know on the invoking side what it is a property or
a method, the work that is done in the invoked class does absolute not
interest me.

I simple get something back (or am changing something in a sub (void in C#))

That is what where about to tell me the logic you wrote about that it should
be written..

In my idea go people in a black suit to the church, no one know why, but it
is always done like that.

Cor
 
And what is a property?  Underneath the skin, the "Get" part of a property
is nothing more than a function call with no parameters that returns the
expected value.  Makes perfect sense to me.

In all truth, I've never looked at two lines of code like so:

MyStr = SomeClass.Name

and

MyStr = SomeClass.Name()

and thought "oh my, I don't understand the one with/without parentheses,
it's completely unreadable".  I doubt that I'd even notice, because I
subconsciously know that both lines do the same thing.  I'd much ratherjust
focus on the code's own readability, use meaningful variable names, and not
have curly braces in so many places that my code looks like ASCII art.

In that sense, I find that VB makes much more sense. :-)
Click to expand...

I sort of feel the opposite, the lack of standardization tends to
cause me to have to do a "double take" and reread code to figure out
what it was doing. This could be because I switch between languages
often, but I find it very annoying when parentheses are left off
method calls or constructors.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Rowe,

In this case I agree with you, they should remove it in C# as well.

Like we know does a property and a method withouth parameters for the
calling program exactly the same..

Cor

"rowe_newsgroups" <[email protected]> schreef in bericht
And what is a property? Underneath the skin, the "Get" part of a property
is nothing more than a function call with no parameters that returns the
expected value. Makes perfect sense to me.

In all truth, I've never looked at two lines of code like so:

MyStr = SomeClass.Name

and

MyStr = SomeClass.Name()

and thought "oh my, I don't understand the one with/without parentheses,
it's completely unreadable". I doubt that I'd even notice, because I
subconsciously know that both lines do the same thing. I'd much rather
just
focus on the code's own readability, use meaningful variable names, and
not
have curly braces in so many places that my code looks like ASCII art.

In that sense, I find that VB makes much more sense. :-)
Click to expand...

I sort of feel the opposite, the lack of standardization tends to
cause me to have to do a "double take" and reread code to figure out
what it was doing. This could be because I switch between languages
often, but I find it very annoying when parentheses are left off
method calls or constructors.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
In this case I agree with you, they should remove it in C# as well.

Well, I hate to remove the rare instance of us agreeing, but
personally I think that they should be required in VB, I like the way
that C# does it better :-)
Like we know does a  property and a method withouth parameters for the
calling program exactly the same..
Click to expand...

Not sure exactly what you mean here, but I'll attempt to respond
anyways. To me I like knowing whether a property or a method is being
called. Strictly speaking you can do the same functionality in either,
but many / most coding guidelines recommend not having much, if any,
functionality inside properties. When reading code that clearly calls
a property (i.e. no parentheses) I don't need to be on my guard for
unexpected behind-the-scenes behaviors as I do with methods.

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
 
Before you simple write that you did not understand my message.
That is what where about to tell me the logic you wrote about that it
should be written..
Click to expand...
The above is little bit to quick typed. I hope I make it better by writing:

That is why I asked you to tell me the logic, in other words, why do we
need on the caller side to know what work is done on the sender side.

AFAIK is one of the principles of Oop that nobody should care how something
is returned, only that it is returned.

Cor
 
Back
Top