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
38  1754 
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" <tf*@dslextreme.comschreef in bericht
news:OD**************@TK2MSFTNGP02.phx.gbl...
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
"tshad" <tf*@dslextreme.comschrieb
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?
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#.
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" wrote:
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
tshad wrote:
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?
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#.
Option Strict On doesn't fix every quirk in VB.NET... ;)
--
Göran Andersson
_____ http://www.guffa.com
Göran Andersson wrote:
tshad wrote:
>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?
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#.
Option Strict On doesn't fix every quirk in VB.NET... ;)
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.
Maybe because
VB IsNot C#
( !( C# is VB ) )
And so there are a lot more examples :-)
regards
Michel Posseth
"tshad" <tf*@dslextreme.comschreef in bericht
news:ul*************@TK2MSFTNGP06.phx.gbl...
Göran Andersson wrote:
>tshad wrote:
>>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?
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#.
Option Strict On doesn't fix every quirk in VB.NET... ;)
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
"Michel Posseth [MCP]" <MS**@posseth.comschrieb:
>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.
Maybe because
VB IsNot C#
( !( C# is VB ) )
'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#.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
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.
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" <gu***@guffa.comschreef in bericht
news:uL**************@TK2MSFTNGP04.phx.gbl...
tshad wrote:
>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?
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#.
Option Strict On doesn't fix every quirk in VB.NET... ;)
--
Göran Andersson
_____
http://www.guffa.com
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 K. Wagner [MVP] wrote:
"Michel Posseth [MCP]" <MS**@posseth.comschrieb:
>>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.
Maybe because
VB IsNot C#
( !( C# is VB ) )
'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#.
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.
--
Göran Andersson
_____ http://www.guffa.com
Cor Ligthert[MVP] wrote:
Tom,
An procedure with empty paramaters is most times confusing in C#, "What
is a method and a property?
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.
I see not how you what saying do?
;)
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
--
Göran Andersson
_____ http://www.guffa.com
"Göran Andersson"
Methods and properties have different semantics and different purposes.
It's logical that they are used differently.
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 Ligthert [MVP] wrote:
"Göran Andersson"
>Methods and properties have different semantics and different purposes.
It's logical that they are used differently.
Seriously Goran, I don't see that logic?
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.
I don't understand what you mean by that. What is it that you are
comparing that to?
--
Göran Andersson
_____ http://www.guffa.com
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..
>It is the same logic as that you go in a black suit to church.
In my idea go people in a black suit to the church, no one know why, but it
is always done like that.
Cor
"Göran Andersson" <gu***@guffa.comschreef in bericht
news:ew**************@TK2MSFTNGP04.phx.gbl...
Cor Ligthert [MVP] wrote:
>"Göran Andersson"
>>Methods and properties have different semantics and different purposes.
It's logical that they are used differently.
Seriously Goran, I don't see that logic?
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.
I don't understand what you mean by that. What is it that you are
comparing that to?
--
Göran Andersson
_____
http://www.guffa.com
On Sep 14, 9:07*pm, "Alex Clark" <qua...@noemail.noemailwrote:
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.
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. :-)
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" <ro********@yahoo.comschreef in bericht
news:0b**********************************@t54g2000 hsg.googlegroups.com...
On Sep 14, 9:07 pm, "Alex Clark" <qua...@noemail.noemailwrote:
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.
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. :-)
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..
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.
Cor wrote:
That is what where about to tell me the logic you wrote about that it
should be written..
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
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.
You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).
In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.
(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)
Thanks,
Seth Rowe [MVP] http://sethrowe.blogspot.com/
But isn't the '"usually", "imo", "generally", etc' exactly the point? There
is no logical distinction between a property and a method. Should a call
that has previously been a method now become a property because the
developer has found a way to safely persist the value and has done away with
the query back to the data base? I certainly want to know that the
performance has been improved in this way, but why should this hidden
internal detail cause me to now think about the item in a completely
different way? And if I'm not thinking about it quite differently, why do
we have the two separate concepts?
"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:91**********************************@b1g2000h sg.googlegroups.com...
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.
You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).
In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.
(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)
Thanks,
Seth Rowe [MVP] http://sethrowe.blogspot.com/
"Göran Andersson" <gu***@guffa.comschrieb:
>>>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.
Maybe because
VB IsNot C#
( !( C# is VB ) )
'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#.
Well, that's only half the truth, and hardly even that...
It's not C# that overrides (not overloads) the operators
It overloads the operators (overloading in the sense of language, not
programming)! The meaning of the '==' operator is ambiguous. You can't
answer the question if the '==' operator in the 'a == b' expression compares
the values or the references without knowing the types of the variables 'a'
and 'b' respectively. That's IMO a huge design problem leading to
confusion, because it requires exact knowledge about the types involved even
when attempting to perform a type-agnostic reference comparison.
C# consistently uses the comparisons defined in the framework
That's true, but it exposes these comparisons in an inconsistent way, making
the use of 'ReferenceEquals' even necessary for reference types overriding
'Equals'. C# does not have distinct operators for value and reference
comparison. It only has a dubious '==' operator which changes its meaning
depending on the types and makes the use of 'ReferenceEquals' necessary in
cases where it performs value comparison although reference comparison is
desired. Even JavaScript' does not have such an awkward comparison operator
design.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
To me the biggest difference is the syntax when the property or method
is used.
If I use a property I can say:
val = obj.Prop
obj.Prop = val
If I use a method I need two methods, something like:
val = obj.GetProp()
obj.SetProp(val)
For things that have a single value, the property syntax makes more
sense to me, and the code in the class is cleaner - the Set and Get
code is together.
For something more complicated, either because the Set has no values,
multiple values or the Set needs to return a status then I would use
the method syntax. The processing time isn't that important to me in
deciding which to use. If you are using a property or method it is
your responsibility to know the ramifications of that use (can it
block for a long time, what are the side effects, etc.). To me a
property is appropriate when you are setting a single value that you
will want to examine later, or a readonly property for a value that
you only want to look at.
And don't forget that something like a property is needed for
databinding, unless you want to specify two methods for the binding,
one to set and one to get.
There will always be gray areas, no matter what your criteria is for
deciding between the two.
On Tue, 16 Sep 2008 07:58:37 +1000, "James Hahn" <jh***@yahoo.com>
wrote:
>But isn't the '"usually", "imo", "generally", etc' exactly the point? There
is no logical distinction between a property and a method. Should a call
that has previously been a method now become a property because the
developer has found a way to safely persist the value and has done away with
the query back to the data base? I certainly want to know that the
performance has been improved in this way, but why should this hidden
internal detail cause me to now think about the item in a completely
different way? And if I'm not thinking about it quite differently, why do
we have the two separate concepts?
"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:91**********************************@b1g2000 hsg.googlegroups.com...
>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.
You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).
In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.
(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)
Thanks,
Seth Rowe [MVP]
http://sethrowe.blogspot.com/
>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.
I personally find the opposite is true, particularly in terms of assuming
how much behind-the-scenes work is going on. Because VB doesn't really
differentiate in terms of parenthesising, I just view every property set/get
call as a sub/function respectively and try not to make assumptions as to
what's going on behind the scenes. If it's my own code I'll generally know
anyway, and if it's not then I won't be trusting of it regardless, lol.
In terms of languages, it's the usual "each to his own" choice. I prefer
VB's easy going nature and it's explicit notations for ending blocks, but I
can see why many prefer the stricter punctuation rules of C# and the
"elegance" of the curly braces.
Seth
You cannot change the method ToString in a property in an existing
situation.
Cor
"rowe_newsgroups" <ro********@yahoo.comschreef in bericht
news:91**********************************@b1g2000h sg.googlegroups.com...
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.
You're correct that we shouldn't care how the value is returned, but
in practice it's rather important (you wouldn't want the Get of a
property doing a 15 second return every time you called it).
In my experience it is generally safer to bet that a property will do
less work than a function when it comes to returning a value. This of
course isn't always true, as it relates to coding styles and (imo)
skill level and experience of the developer who wrote the library. In
most cases it is assumed that a property usually returns a simple
value, where as a function does something in the background to get
that value. For example it's common for a function to end up querying
a database, but I would beat any of the developers I work with for
doing this from a property unless they had an extremely good reason.
(I wonder if I put enough words like "usually", "imo", "generally",
etc to cover myself?)
Thanks,
Seth Rowe [MVP] http://sethrowe.blogspot.com/
You cannot change the method ToString in a property in an existing
situation.
I think we lost something in translation - where did I say I was
trying to do this?
Thanks,
Seth Rowe [MVP] http://sethrowe.blogspot.com/
In terms of languages, it's the usual "each to his own" choice. *
Personally, I prefer "boo" as a language. Simple, elegant, and non-
intrusive to the programmer.
Thanks,
Seth Rowe [MVP] http://sethrowe.blogspot.com/
Göran Andersson <gu***@guffa.comwrote:
Cor Ligthert [MVP] wrote:
"Göran Andersson"
Methods and properties have different semantics and different purposes.
It's logical that they are used differently.
Seriously Goran, I don't see that logic?
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.
The whole point of having a property versus having a field is that the
property at least potentially encapsulates logic.
If the property is "number of legs" then it should be quick and not
require much work if it's "current net value" then it might require
quite a lot of work.
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.
Except when profiling, you shouldn't be giving a lot of thought to how
much work a piece of code does.
It is the same logic as that you go in a black suit to church.
I don't understand what you mean by that. What is it that you are
comparing that to?
He's calling it religious/tradition, not logic.
--
J.B. Moreno
Cor Ligthert [MVP] wrote:
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.
The background colour of a text box is clearly a property. You can set
the value, and you can get the value. It doesn't make sense to implement
it as anything else.
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.
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do. http://en.wikipedia.org/wiki/Object-...ed_programming
>>It is the same logic as that you go in a black suit to church.
In my idea go people in a black suit to the church, no one know why, but it
is always done like that.
Well, you can either accept object oriented programming and "wear the
black suit", or you can reject it. In that case you should probably
choose a different language that isn't object oriented...
--
Göran Andersson
_____ http://www.guffa.com
In article <#$**************@TK2MSFTNGP06.phx.gbl>,
Göran Andersson <gu***@guffa.comwrote:
Cor Ligthert [MVP] 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.
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.
http://en.wikipedia.org/wiki/Object-...ed_programming
Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.
And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.
For instance, the total net worth of a person, may not be a simple
matter of adding the checking and saving accounts together and then
subtracting outstanding debts, so you might have a parent class called
People and then sub-classes RichPeople and PoorPeople where the
property CurrentNetValue is calculated differently.
--
J.B. Moreno
So if an object can be instructed to change a characteristic of itself (such
as a user control instructed to change its background color) should that
instruction be implemented as a property or as a method?
If we really maintained the distinction you refer to we would need two steps
in the process - a change of the property value and an invocation of a
method to force the object to do whatever the change in the property
requires. That doesn't happen, and there is no reason that it should. So
what purpose is served by the distinction between changing the value of a
property and performing some action in response to that change?
From the other viewpoint, in many cases when the object does something we
want to know the result of that action. If we maintained the distinction
that you refer to we would need two steps in the process - a method to
instruct the object to carry out the action, and then retrieve the property
that indicates the result.
In practice, the distinction you refer to does not exist, and the
classification of an process as property or method seems to be pretty much
arbitrary.
For example, why are we still saying
myVar += 1
when the OOP terminology is surely
mvVar.Math.Add(1)
"Göran Andersson" <gu***@guffa.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>snip
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.
http://en.wikipedia.org/wiki/Object-...ed_programming
>>>It is the same logic as that you go in a black suit to church.
In my idea go people in a black suit to the church, no one know why, but
it is always done like that.
Well, you can either accept object oriented programming and "wear the
black suit", or you can reject it. In that case you should probably choose
a different language that isn't object oriented...
--
Göran Andersson
_____
http://www.guffa.com
J.B. Moreno wrote:
In article <#$**************@TK2MSFTNGP06.phx.gbl>,
Göran Andersson <gu***@guffa.comwrote:
>Cor Ligthert [MVP] 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.
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.
http://en.wikipedia.org/wiki/Object-...ed_programming
Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.
Of course you should.
There is a distinct difference between a method and a property. Reading
a property should not change the object, while calling a method often
does change the object.
And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.
If there is some lengthy process to calculate the value of a property,
the property should cache the value so that it only has to be calculated
once. A method on the other hand should usually not do that, as you
expect it to actually do something each time it's called.
The debugger in Visual Studio, for example, relies heavily on this
difference between properties and methods. When displaying an object it
reads all the properties to get their values, but it doesn't call all
the methods to get their return values.
--
Göran Andersson
_____ http://www.guffa.com
James Hahn wrote:
So if an object can be instructed to change a characteristic of itself
(such as a user control instructed to change its background color)
should that instruction be implemented as a property or as a method?
If it's a characteristic of the object that you can access, it should
usually be a property.
If we really maintained the distinction you refer to we would need two
steps in the process - a change of the property value and an invocation
of a method to force the object to do whatever the change in the
property requires. That doesn't happen, and there is no reason that it
should. So what purpose is served by the distinction between changing
the value of a property and performing some action in response to that
change?
From the other viewpoint, in many cases when the object does something
we want to know the result of that action. If we maintained the
distinction that you refer to we would need two steps in the process - a
method to instruct the object to carry out the action, and then retrieve
the property that indicates the result.
That is logical if the result of the operation determines a
characteristic of the object. Then you would already have the property,
and it would only be natural that the method changed the state of the
object.
For example, you can call the Open method of the SqlConnection class.
The open method doesn't have a return value, but if it succeded the
State property will change.
In practice, the distinction you refer to does not exist, and the
classification of an process as property or method seems to be pretty
much arbitrary.
It does exist, and I showed you an example of how it's used in the
framework.
For example, why are we still saying
myVar += 1
when the OOP terminology is surely
mvVar.Math.Add(1)
That is just syntactic sugar for using the addition operator. What it
actually does is reading the value, adding one to it and assigning the
result to the variable:
myVar = myVar + 1;
The addition operator actually works as a static method (and can be
overloaded like one for your own classes), so what it actually does is:
myVar = Int32.operator+(myVar, 1);
This is of course optimised by the JIT compiler into the ADD
instruction, so it will not be a method call when adding the built-in types.
--
Göran Andersson
_____ http://www.guffa.com
Göran Andersson <gu***@guffa.comwrote:
J.B. Moreno wrote:
In article <#$**************@TK2MSFTNGP06.phx.gbl>,
Göran Andersson <gu***@guffa.comwrote:
Cor Ligthert [MVP] 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.
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.
http://en.wikipedia.org/wiki/Object-...ed_programming
Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.
Of course you should.
There is a distinct difference between a method and a property. Reading
a property should not change the object, while calling a method often
does change the object.
That depends upon what you are doing (for instance you might be
modeling a Heisenberg object where the position or velocity can be
known, but not both).
But in general I consider it good programming practice to (a) document
side effects, (b) minimize side-effects. You can't rely upon the
property/method distinction to determine whether or not there were
side-effects (a pet object might have an owners property that hit the
database for instance with all that implies).
This isn't about OOP, it's about what you consider best practice, for
your own code, not something you can even begin to rely upon as best
practice for someone else's code.
And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.
If there is some lengthy process to calculate the value of a property,
the property should cache the value so that it only has to be calculated
once. A method on the other hand should usually not do that, as you
expect it to actually do something each time it's called.
Caching should be used whenever it makes sense, and not used when it
doesn't (for instance DateTime values all have a Now Property, caching
that wouldn't make any sense).
--
J.B. Moreno
In article <uf*************@TK2MSFTNGP03.phx.gbl>,
James Hahn <jh***@yahoo.comwrote:
So if an object can be instructed to change a characteristic of itself (such
as a user control instructed to change its background color) should that
instruction be implemented as a property or as a method?
As a property.
The distinction between the a method and a property is a useful
conceptional tool -- see bundle theory of objecthood.
Methods are abilities, properties are characteristics -- while you can
have some overlap, that's because we are writing code not dealing with
fundamental truths of the universe.
If we really maintained the distinction you refer to we would need two steps
in the process - a change of the property value and an invocation of a
method to force the object to do whatever the change in the property
requires. That doesn't happen, and there is no reason that it should. So
what purpose is served by the distinction between changing the value of a
property and performing some action in response to that change?
No. If an object has a property, then changing the property changes
the expression (after a bit of time delay because computers can't do
everything at once) of that property. If you have a class Dogs and
amputate a particular dog's leg, then when displaying that dog, it
should have the correct number of legs.
Or to put it in database terms, changing a property is a transaction,
that either succeeds or fails -- if you set the background color of an
object to blue and the background continues to display in yellow, then
your object is broken.
This is not to say the distinction isn't useful, it is. With an
object, we want to know what it *is* as well as what it can *do*. We
will make use of this when classifying it and interfacing with it.
--
J.B. Moreno
J.B. Moreno wrote:
Göran Andersson <gu***@guffa.comwrote:
>J.B. Moreno wrote:
>>In article <#$**************@TK2MSFTNGP06.phx.gbl>,
Göran Andersson <gu***@guffa.comwrote:
Cor Ligthert [MVP] 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.
In OOP the difference between a method and a property is very clear. A
property represents the characteristics of an object, while a method
represents what the object can do.
http://en.wikipedia.org/wiki/Object-...ed_programming
Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.
Of course you should.
There is a distinct difference between a method and a property. Reading
a property should not change the object, while calling a method often
does change the object.
That depends upon what you are doing (for instance you might be
modeling a Heisenberg object where the position or velocity can be
known, but not both).
But in general I consider it good programming practice to (a) document
side effects, (b) minimize side-effects. You can't rely upon the
property/method distinction to determine whether or not there were
side-effects (a pet object might have an owners property that hit the
database for instance with all that implies).
This isn't about OOP, it's about what you consider best practice, for
your own code, not something you can even begin to rely upon as best
practice for someone else's code.
This is general OOP guidelines. If I inherit code from someone else, and
I find a class where reading properties changes the state of the object,
I would definitely consider that as a bug.
>>And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.
If there is some lengthy process to calculate the value of a property,
the property should cache the value so that it only has to be calculated
once. A method on the other hand should usually not do that, as you
expect it to actually do something each time it's called.
Caching should be used whenever it makes sense, and not used when it
doesn't (for instance DateTime values all have a Now Property, caching
that wouldn't make any sense).
The Now property is static, so it's not an example of an object property.
If getting the value of a property is a lengthy process, it should
always be cached if possible. If it takes a few seconds to get the
value, you can cache it for another few seconds. If you want to perform
the lengthy process every time, it should be a method rather than a
property.
--
Göran Andersson
_____ http://www.guffa.com
On Sep 23, 7:22*am, Göran Andersson <gu...@guffa.comwrote:
J.B. Moreno wrote:
Göran Andersson <gu...@guffa.comwrote:
J.B. Moreno wrote:
In article <#$OyGhNHJHA.4...@TK2MSFTNGP06.phx.gbl>,
Göran Andersson <gu...@guffa.comwrote:
>>Cor Ligthert [MVP] 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.
In OOP the difference between a method and a property is very clear.A
property represents the characteristics of an object, while a method
represents what the object can do.
>>>http://en.wikipedia.org/wiki/Object-...ed_programming
Which helps you organize and structure the code, and tells you what
things should and should not be in a class, but doesn't mean that you
should care about the difference when consuming the class.
Of course you should.
There is a distinct difference between a method and a property. Reading
a property should not change the object, while calling a method often
does change the object.
That depends upon what you are doing (for instance you might be
modeling a Heisenberg object where the position or velocity can be
known, but not both).
But in general I consider it good programming practice to (a) document
side effects, (b) minimize side-effects. *You can't rely upon the
property/method distinction to determine whether or not there were
side-effects (a pet object might have an owners property that hit the
database for instance with all that implies).
This isn't about OOP, it's about what you consider best practice, for
your own code, not something you can even begin to rely upon as best
practice for someone else's code.
This is general OOP guidelines. If I inherit code from someone else, and
I find a class where reading properties changes the state of the object,
I would definitely consider that as a bug.
>And in particular there's nothing in there even suggesting that the
characteristic that is a property must be a simple value that is
fetched, instead of a complex calculation that takes a long time to
process.
If there is some lengthy process to calculate the value of a property,
the property should cache the value so that it only has to be calculated
once. A method on the other hand should usually not do that, as you
expect it to actually do something each time it's called.
Caching should be used whenever it makes sense, and not used when it
doesn't (for instance DateTime values all have a Now Property, caching
that wouldn't make any sense).
The Now property is static, so it's not an example of an object property.
If getting the value of a property is a lengthy process, it should
always be cached if possible. If it takes a few seconds to get the
value, you can cache it for another few seconds. If you want to perform
the lengthy process every time, it should be a method rather than a
property.
--
Göran Andersson
_____http://www.guffa.com
In addition, from a testing standpoint, having properties that
encapsulate a great deal of logic can be a shear nightmare. Especially
if you try to use many of the various mocking platforms, where it is
nigh impossible to set expectations and monitor behaviors when the
logic lives inside properties. My personal favorite, Rhino.Mocks,
(afaik) treats properties as simple get, set blocks and will blow up
trying to set an expectation on them. You can set expectations on
readonly properties, but even then there tends to be some "gotchas"
you wouldn't get with functions.
Most of the times that I see developers adding functionality to
properties, it's on a project with zero unit tests and is done out of
laziness. There is a development stigma against functions; functions
are "expected" to be complex routines that are fully tested, and most
bugs are blamed on poor implementation of the logic inside a function.
To me it seems that many people think that putting the logic into a
property, particularly readonly properties, makes their code safer and
less likely to break. In other words it's a security blanket of
sorts.
If it were up to me, all properties would be defined as C#
autoimplemented properties (public string MyProperty { get; set; }) so
that you couldn't add any additional functionality. Sure there are
cases where you need more functionality, such as firing XChanging
XChanged events or caching, but those could be done with attributes,
etc. I firmly believe that any logic that needs to be tested (yes
everything should be tested, but simple properties normally don't have
a good ROI from testing) should live in a method.
Thanks,
Seth Rowe [MVP] http://sethrowe.blogspot.com/
"Göran Andersson" <gu***@guffa.comwrote in message
news:eg**************@TK2MSFTNGP03.phx.gbl...
James Hahn wrote:
>So if an object can be instructed to change a characteristic of itself
(such as a user control instructed to change its background color) should
that instruction be implemented as a property or as a method?
If it's a characteristic of the object that you can access, it should
usually be a property.
But my point was that your definition does not provide a basis for deciding
this. Surely changing its appearance is 'something an object can do'. Why
have you chosen the 'characteristic' side of the definition instead of the
'change' side? For a more dramatic example, consider the view property of a
ListView - a change in one enumerated property casuses major changes to the
display and functionality of the control.
I am not arguing that these things shouldn't be properties, but simply
wondering whether there is a more rigorous basis for making the distinction
between properties and methods that can effectively guide the programmer
(which I think was the origianl question in the thread). It must be a
problem for workgroups having this decision decided at the team level
without adequate guidance for the programmer to make the decision
themselves. In my own case, I know that I am frequently inconsistent. For
instance,
myRobot.Speed += 3
but
myRobot.Direction(Left, 10)
simply because of the way I expected to be passing the arguments. I can
easily imagine someone else thinking exactly the opposite.
I suspect the real distinction has nothing to do with characteristics and
actions, but rather is in the compiler and IDE technical detail - issues
with initialization, overloading, shadowing, context, optimization,
protection and so on. Or, that there is no real distinction and the
programmer is free to use whatever is most convenient in the circumstances. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Olaf |
last post by:
I have a frameset page witch contains the myFuc() function. The
function is accessed from a page in one of the frames in the frameset.
An example is shown below.
<input...
|
by: nick |
last post by:
I have the following code:
var ocevent = function(v)
{
alert('javascript event: u clicked '+v);
return false;
};
|
by: Alex Sedow |
last post by:
Example 1
interface I
{
string ToString();
}
public class C : I
{
public void f()
{
|
by: Sam |
last post by:
I have an application that sits in the traybar that calls a msde sp3a
database to verify that the connection to the sql server instance exists.
If the sql server is up obviously the application...
|
by: |
last post by:
The following code:
Private Sub ClearControls(ByVal ctrl As Control)
Dim i As Int32
For i = ctrl.Controls.Count - 1 To 0 Step -1
ClearControls(ctrl.Controls(i))
|
by: darrel |
last post by:
I've built a control. At the top of my control, I have this:
Imports Microsoft.VisualBasic
Then, later, I call a function like this:
DateTime.Now.Year.ToString()
This works fine on my...
|
by: Jed |
last post by:
I have looked everywhere and cannot find a resolution for this. I have read
several post on this forum that allude to similar issues but I have not found
a solution.
I am sending dynamic...
|
by: Mike S |
last post by:
Maybe I'm missing some fundamental unwritten law of OOP, but I was
wondering why the VB.NET compiler doesn't take advantage of the fact
that all .NET objects, being derived from the Object base...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
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:
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: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
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...
| |
