FEATURE REQUEST: Property set via ref parameter

[Guest]

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.

[Jon Skeet [C# MVP]]

Re: FEATURE REQUEST: Property set via ref parameter

<discussion@dis cussion.microso ft.com> wrote:[color=blue]
> 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.[/color]

I'm afraid I don't agree...
[color=blue]
> 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.[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Guest]

Re: FEATURE REQUEST: Property set via ref parameter

They are giving the impression of fields, thats why we can do a
SomeObj.SomePro perty = someValue just like a field assignment, same for get
someVal = SomeObj.SomePro perty; 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]" <skeet@pobox.co m> wrote in message
news:MPG.1a4bb4 2af720ebac989c7 5@msnews.micros oft.com...[color=blue]
> <discussion@dis cussion.microso ft.com> wrote:[color=green]
> > It would be nice and a natural way to use a property set by permitting[/color][/color]
it[color=blue][color=green]
> > to be set via a REF parameter on a method call.[/color]
>
> I'm afraid I don't agree...
>[color=green]
> > Why this isnt being allowed is beyond me, yes I know they are wrappers[/color][/color]
for[color=blue][color=green]
> > 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[/color][/color]
some[color=blue][color=green]
> > half brained implementation.[/color]
>
> 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 - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: FEATURE REQUEST: Property set via ref parameter

<discussion@dis cussion.microso ft.com> wrote:[color=blue]
> 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.[/color]

I'm afraid I don't agree...
[color=blue]
> 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.[/color]

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 - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Guest]

Re: FEATURE REQUEST: Property set via ref parameter

They are giving the impression of fields, thats why we can do a
SomeObj.SomePro perty = someValue just like a field assignment, same for get
someVal = SomeObj.SomePro perty; 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]" <skeet@pobox.co m> wrote in message
news:MPG.1a4bb4 2af720ebac989c7 5@msnews.micros oft.com...[color=blue]
> <discussion@dis cussion.microso ft.com> wrote:[color=green]
> > It would be nice and a natural way to use a property set by permitting[/color][/color]
it[color=blue][color=green]
> > to be set via a REF parameter on a method call.[/color]
>
> I'm afraid I don't agree...
>[color=green]
> > Why this isnt being allowed is beyond me, yes I know they are wrappers[/color][/color]
for[color=blue][color=green]
> > 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[/color][/color]
some[color=blue][color=green]
> > half brained implementation.[/color]
>
> 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 - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Jon Skeet [C# MVP]]

Re: FEATURE REQUEST: Property set via ref parameter

<discussion@dis cussion.microso ft.com> wrote:[color=blue]
> They are giving the impression of fields, thats why we can do a
> SomeObj.SomePro perty = someValue just like a field assignment, same for get
> someVal = SomeObj.SomePro perty; again justlike a FIELD.[/color]

Yes, but that doesn't mean they should (or do) behave like fields in
every possible way.
[color=blue]
> They maybe implemented as methods, but thats not our problem as a developer
> calling them, thats a lower level.[/color]

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.
[color=blue]
> 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).[/color]

No, they are wrappers for the state of the object, which needn't be
represented by fields.
[color=blue]
> So Yes, they are there to give an impression of fields.[/color]

They're there to give the easy syntax of fields, but that doesn't mean
they should be regarded as fields.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Re: FEATURE REQUEST: Property set via ref parameter

<discussion@dis cussion.microso ft.com> wrote:[color=blue]
> They are giving the impression of fields, thats why we can do a
> SomeObj.SomePro perty = someValue just like a field assignment, same for get
> someVal = SomeObj.SomePro perty; again justlike a FIELD.[/color]

Yes, but that doesn't mean they should (or do) behave like fields in
every possible way.
[color=blue]
> They maybe implemented as methods, but thats not our problem as a developer
> calling them, thats a lower level.[/color]

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.
[color=blue]
> 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).[/color]

No, they are wrappers for the state of the object, which needn't be
represented by fields.
[color=blue]
> So Yes, they are there to give an impression of fields.[/color]

They're there to give the easy syntax of fields, but that doesn't mean
they should be regarded as fields.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Guest]

Re: FEATURE REQUEST: Property set via ref parameter

You're a tard in disguise.


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a4bc2 3dd08e6c6f989c7 7@msnews.micros oft.com...[color=blue]
> <discussion@dis cussion.microso ft.com> wrote:[color=green]
> > They are giving the impression of fields, thats why we can do a
> > SomeObj.SomePro perty = someValue just like a field assignment, same for[/color][/color]
get[color=blue][color=green]
> > someVal = SomeObj.SomePro perty; again justlike a FIELD.[/color]
>
> Yes, but that doesn't mean they should (or do) behave like fields in
> every possible way.
>[color=green]
> > They maybe implemented as methods, but thats not our problem as a[/color][/color]
developer[color=blue][color=green]
> > calling them, thats a lower level.[/color]
>
> 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.
>[color=green]
> > 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).[/color]
>
> No, they are wrappers for the state of the object, which needn't be
> represented by fields.
>[color=green]
> > So Yes, they are there to give an impression of fields.[/color]
>
> They're there to give the easy syntax of fields, but that doesn't mean
> they should be regarded as fields.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Kim Nørby Andersen]

Re: FEATURE REQUEST: Property set via ref parameter

<discussion@dis cussion.microso ft.com> skrev i en meddelelse
news:eKq$gCXxDH A.3468@TK2MSFTN GP11.phx.gbl...[color=blue]
> You're a tard in disguise.[/color]

and you are not really showing the nicest sides of you... hopefully

/Kim

[Guest]

Re: FEATURE REQUEST: Property set via ref parameter

And i care?


"Kim Nørby Andersen" <kna@removethis .multihouse.dk> wrote in message
news:uY6QlMXxDH A.2440@TK2MSFTN GP12.phx.gbl...[color=blue]
> <discussion@dis cussion.microso ft.com> skrev i en meddelelse
> news:eKq$gCXxDH A.3468@TK2MSFTN GP11.phx.gbl...[color=green]
> > You're a tard in disguise.[/color]
>
> and you are not really showing the nicest sides of you... hopefully
>
> /Kim
>
>
>[/color]

[Marco Martin]

Re: FEATURE REQUEST: Property set via ref parameter

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 ThisValueIsReal yBadException;
}
}
}

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]" <skeet@pobox.co m> wrote in message
news:MPG.1a4bc2 3dd08e6c6f989c7 7@msnews.micros oft.com...[color=blue]
> <discussion@dis cussion.microso ft.com> wrote:[color=green]
> > They are giving the impression of fields, thats why we can do a
> > SomeObj.SomePro perty = someValue just like a field assignment, same for[/color][/color]
get[color=blue][color=green]
> > someVal = SomeObj.SomePro perty; again justlike a FIELD.[/color]
>
> Yes, but that doesn't mean they should (or do) behave like fields in
> every possible way.
>[color=green]
> > They maybe implemented as methods, but thats not our problem as a[/color][/color]
developer[color=blue][color=green]
> > calling them, thats a lower level.[/color]
>
> 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.
>[color=green]
> > 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).[/color]
>
> No, they are wrappers for the state of the object, which needn't be
> represented by fields.
>[color=green]
> > So Yes, they are there to give an impression of fields.[/color]
>
> They're there to give the easy syntax of fields, but that doesn't mean
> they should be regarded as fields.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[Edward Diener]

Re: FEATURE REQUEST: Property set via ref parameter

discussion@disc ussion.microsof t.com wrote:[color=blue]
> 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.[/color]

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.