Hi,
It would be nice and a natural way to use a property set by permitting it
to be set via a REF parameter on a method call.
Why this isnt being allowed is beyond me, yes I know they are wrappers for
get_ and set_ methods but if they are there to give the impression of a
FIELD, then they should have all the functionality of a field and not some
half brained implementation.
Thanks.
11  1219 
<di********@discussion.microsoft.com> wrote: It would be nice and a natural way to use a property set by permitting it
to be set via a REF parameter on a method call.
I'm afraid I don't agree...
Why this isnt being allowed is beyond me, yes I know they are wrappers for
get_ and set_ methods but if they are there to give the impression of a
FIELD, then they should have all the functionality of a field and not some
half brained implementation.
No, because they're simply *not* fields. Passing a variable by
reference creates another variable with the same memory slot - that
just isn't how properties work. Developers should have a clear view
that properties are really methods in disguise rather than fields in
disguise.
Passing variables by reference should usually be avoided anyway, to be
honest - it's usually a sign of a method trying to do too much.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
They are giving the impression of fields, thats why we can do a
SomeObj.SomeProperty = someValue just like a field assignment, same for get
someVal = SomeObj.SomeProperty; again justlike a FIELD.
They maybe implemented as methods, but thats not our problem as a developer
calling them, thats a lower level.
They are there to give more extensibility to fields and a greater way to
control fields.
They are wrappers for fields (conceptually), and wrappers for methods
(implentation).
So Yes, they are there to give an impression of fields.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <di********@discussion.microsoft.com> wrote: It would be nice and a natural way to use a property set by permitting
it to be set via a REF parameter on a method call.
I'm afraid I don't agree...
Why this isnt being allowed is beyond me, yes I know they are wrappers
for get_ and set_ methods but if they are there to give the impression of a
FIELD, then they should have all the functionality of a field and not
some half brained implementation.
No, because they're simply *not* fields. Passing a variable by
reference creates another variable with the same memory slot - that
just isn't how properties work. Developers should have a clear view
that properties are really methods in disguise rather than fields in
disguise.
Passing variables by reference should usually be avoided anyway, to be
honest - it's usually a sign of a method trying to do too much.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
<di********@discussion.microsoft.com> wrote: It would be nice and a natural way to use a property set by permitting it
to be set via a REF parameter on a method call.
I'm afraid I don't agree...
Why this isnt being allowed is beyond me, yes I know they are wrappers for
get_ and set_ methods but if they are there to give the impression of a
FIELD, then they should have all the functionality of a field and not some
half brained implementation.
No, because they're simply *not* fields. Passing a variable by
reference creates another variable with the same memory slot - that
just isn't how properties work. Developers should have a clear view
that properties are really methods in disguise rather than fields in
disguise.
Passing variables by reference should usually be avoided anyway, to be
honest - it's usually a sign of a method trying to do too much.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
They are giving the impression of fields, thats why we can do a
SomeObj.SomeProperty = someValue just like a field assignment, same for get
someVal = SomeObj.SomeProperty; again justlike a FIELD.
They maybe implemented as methods, but thats not our problem as a developer
calling them, thats a lower level.
They are there to give more extensibility to fields and a greater way to
control fields.
They are wrappers for fields (conceptually), and wrappers for methods
(implentation).
So Yes, they are there to give an impression of fields.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <di********@discussion.microsoft.com> wrote: It would be nice and a natural way to use a property set by permitting
it to be set via a REF parameter on a method call.
I'm afraid I don't agree...
Why this isnt being allowed is beyond me, yes I know they are wrappers
for get_ and set_ methods but if they are there to give the impression of a
FIELD, then they should have all the functionality of a field and not
some half brained implementation.
No, because they're simply *not* fields. Passing a variable by
reference creates another variable with the same memory slot - that
just isn't how properties work. Developers should have a clear view
that properties are really methods in disguise rather than fields in
disguise.
Passing variables by reference should usually be avoided anyway, to be
honest - it's usually a sign of a method trying to do too much.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
<di********@discussion.microsoft.com> wrote: They are giving the impression of fields, thats why we can do a
SomeObj.SomeProperty = someValue just like a field assignment, same for get
someVal = SomeObj.SomeProperty; again justlike a FIELD.
Yes, but that doesn't mean they should (or do) behave like fields in
every possible way.
They maybe implemented as methods, but thats not our problem as a developer
calling them, thats a lower level.
No it's not, really. It's all in the C# specification. Properties *are*
just methods in disguise, and any developer who doesn't get to grips
with that is going to get confused. For instance, have you ever heard
of a field you can assign to but not use the value of? And yet there
are properties which only have setters but no getters. Similarly,
straight assignment can't throw exceptions etc.
They are there to give more extensibility to fields and a greater way to
control fields.
They are wrappers for fields (conceptually), and wrappers for methods
(implentation).
No, they are wrappers for the state of the object, which needn't be
represented by fields.
So Yes, they are there to give an impression of fields.
They're there to give the easy syntax of fields, but that doesn't mean
they should be regarded as fields.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
<di********@discussion.microsoft.com> wrote: They are giving the impression of fields, thats why we can do a
SomeObj.SomeProperty = someValue just like a field assignment, same for get
someVal = SomeObj.SomeProperty; again justlike a FIELD.
Yes, but that doesn't mean they should (or do) behave like fields in
every possible way.
They maybe implemented as methods, but thats not our problem as a developer
calling them, thats a lower level.
No it's not, really. It's all in the C# specification. Properties *are*
just methods in disguise, and any developer who doesn't get to grips
with that is going to get confused. For instance, have you ever heard
of a field you can assign to but not use the value of? And yet there
are properties which only have setters but no getters. Similarly,
straight assignment can't throw exceptions etc.
They are there to give more extensibility to fields and a greater way to
control fields.
They are wrappers for fields (conceptually), and wrappers for methods
(implentation).
No, they are wrappers for the state of the object, which needn't be
represented by fields.
So Yes, they are there to give an impression of fields.
They're there to give the easy syntax of fields, but that doesn't mean
they should be regarded as fields.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
You're a tard in disguise.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <di********@discussion.microsoft.com> wrote: They are giving the impression of fields, thats why we can do a
SomeObj.SomeProperty = someValue just like a field assignment, same for
get someVal = SomeObj.SomeProperty; again justlike a FIELD.
Yes, but that doesn't mean they should (or do) behave like fields in
every possible way.
They maybe implemented as methods, but thats not our problem as a
developer calling them, thats a lower level.
No it's not, really. It's all in the C# specification. Properties *are*
just methods in disguise, and any developer who doesn't get to grips
with that is going to get confused. For instance, have you ever heard
of a field you can assign to but not use the value of? And yet there
are properties which only have setters but no getters. Similarly,
straight assignment can't throw exceptions etc.
They are there to give more extensibility to fields and a greater way to
control fields.
They are wrappers for fields (conceptually), and wrappers for methods
(implentation).
No, they are wrappers for the state of the object, which needn't be
represented by fields.
So Yes, they are there to give an impression of fields.
They're there to give the easy syntax of fields, but that doesn't mean
they should be regarded as fields.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
<di********@discussion.microsoft.com> skrev i en meddelelse
news:eK**************@TK2MSFTNGP11.phx.gbl... You're a tard in disguise.
and you are not really showing the nicest sides of you... hopefully
/Kim
And i care?
"Kim Nørby Andersen" <kn*@removethis.multihouse.dk> wrote in message
news:uY**************@TK2MSFTNGP12.phx.gbl... <di********@discussion.microsoft.com> skrev i en meddelelse
news:eK**************@TK2MSFTNGP11.phx.gbl... You're a tard in disguise.
and you are not really showing the nicest sides of you... hopefully
/Kim
Discussion@,
When you set a field, say; x = 3; the field is set, period.
When you set a property, alot of work can be done;
for example;
myObject.x = 3
inside myObject...
public property x
{
set
{
if(value == something)
{
call some method;
call another method;
}
else if(value == something else)
{
call some other method;
}
else
{
throw ThisValueIsRealyBadException;
}
}
}
you cant do that by just setting a field.
Properties aren't just for LowLevel programmers. Anyone who has to derive a
class or who creates custom Textbox because he/she needs more functionality
would need to know this.
Marco
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... <di********@discussion.microsoft.com> wrote: They are giving the impression of fields, thats why we can do a
SomeObj.SomeProperty = someValue just like a field assignment, same for
get someVal = SomeObj.SomeProperty; again justlike a FIELD.
Yes, but that doesn't mean they should (or do) behave like fields in
every possible way.
They maybe implemented as methods, but thats not our problem as a
developer calling them, thats a lower level.
No it's not, really. It's all in the C# specification. Properties *are*
just methods in disguise, and any developer who doesn't get to grips
with that is going to get confused. For instance, have you ever heard
of a field you can assign to but not use the value of? And yet there
are properties which only have setters but no getters. Similarly,
straight assignment can't throw exceptions etc.
They are there to give more extensibility to fields and a greater way to
control fields.
They are wrappers for fields (conceptually), and wrappers for methods
(implentation).
No, they are wrappers for the state of the object, which needn't be
represented by fields.
So Yes, they are there to give an impression of fields.
They're there to give the easy syntax of fields, but that doesn't mean
they should be regarded as fields.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too di********@discussion.microsoft.com wrote: Hi,
It would be nice and a natural way to use a property set by
permitting it to be set via a REF parameter on a method call.
Why this isnt being allowed is beyond me, yes I know they are
wrappers for get_ and set_ methods but if they are there to give the
impression of a FIELD, then they should have all the functionality of
a field and not some half brained implementation.
The normal reason for doing what you want is that the type of a value is
large, so passing a reference to it, rather than a copy of the value, is
faster and more memory efficient. However properties are almost always small
values, essentially value types of built-in types, so passing references is
unnecessary. Finally properties themselves do not hold references, and do
not even have to relate to actual data values, so there is no reason to pass
a reference to set them as if they were references to objects.
As others have mentioned, although a property may be thought of as a data
value, or a field in .NET terms, it doesn't have to be one at all. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Whitney |
last post by:
On the left side of the main webpage I have some menu options that
have a drop-down feature that is controlled with javascript. You click
on the main heading and the links for that section show up....
|
by: serge calderara |
last post by:
Dear all,
For my application I need to handle licencing as every software.
For that I have a demo licence and a runtime licence which can expired after 30 days for the demo and base on a date...
|
by: mews.microsoft.com |
last post by:
My ASP.NET pages record the referal url for each current page into session.
This is then being used by the cancel button to go back to the calling page.
Page Navigation is achieved thru'...
|
by: Jeroen Smits |
last post by:
To Microsoft or other people who are interested, I have a feature request:
I would really like to have an option to 'hide' a property or method from an
inherited class. For example when I create...
|
by: |
last post by:
Hi,
It would be nice and a natural way to use a property set by permitting it
to be set via a REF parameter on a method call.
Why this isnt being allowed is beyond me, yes I know they are...
|
by: Raymond Hettinger |
last post by:
Proposal
--------
I am gathering data to evaluate a request for an alternate version of
itertools.izip() with a None fill-in feature like that for the built-in
map() function:
>>> map(None,...
|
by: Ido Samuelson |
last post by:
Hello,
What do you think about the following features:
public class GenericDecorator<T: T
{
}
can leverage to a few things:
|
by: buntyindia |
last post by:
Hi,
I have a very strange problem with my application.
I have developed it using Struts.
I have a TextBox With Some fixed value in it and on Submit iam passing it to another page.
<html:form...
|
by: Doogie |
last post by:
Hi,
I'm writing Javascript code to parse out a query string. I want to
handle the case where a parameter value may not be sent.
So consider a parameter called "State". If the user doesn't pass...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
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: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
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...
| |
