> -----Original Message-----
> From: Chris Day [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 21, 2003 7:27 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] Do properties need a 'holder' keyword?
>
> I know that when using properties there are a lot of read only (get
> accessor only) properties which would be useful to have auto-generated
> for me. Think of the Count property in a collection. Internally it's
> read/write but externally the property has a get accessor only.
>
> Having a short-hand way to do this would be cool.
>
> Chris
>
It would be nice if property getters/setters could have individual
access modifiers.
That way you can do something like:
public int Count { get { return _count; } }
private int Count { set { _count = value; } }
I think that internal code should also use properties instead of
directly accessing member variables because at some point extra code,
like validation, may be inserted in the property accessors and your
existing code will get the benefit (and prevent bugs).
This is the same reason I don't use public member fields either.
Although the compiler may inline simple getters/setters, if you use a
public field, the IL generated will always access the field directly.
This can cause versioning problems in the future.
For example, if I have a client that uses a property defined in an
EXTERNAL assembly, the IL that is generated MUST output a method call
for the property accessor and MUST NOT inline the accessor, even if it's
a simple one.
Why is this? Because if I add more code to the property accessor, the
client needs to make the method call so this new code runs. If it simply
inlined direct access to the member variable of an external assembly,
this would be a bug.
You may be thinking that assemblies are versioned so you would have to
recompile your client to access the updated assembly. True, this is
possible, but what if that was the only change you made (perhaps a bug
fix)? If so, then you should be able to create a Publisher Policy that
says the new assembly is compatible with the old one.
Now what if the original assembly used a public member field? Then
obviously the client will generate IL to access this field directly.
With the same scenario (a bug fix), I need to convert the public member
field to a property with some validation code in the accessor. Now the
client will definitely break because there is no longer a public member
field to access, although semantically the client is simply using what
appears to be a "property". This is why I think public member fields are
a bad idea.
Of course, this is not an issue for code within a given assembly. The
compiler is free to optimize property accessors in this case, since any
change would recompile the entire assembly.
Anyway, that's my 2 cents.
-- Michael
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
NEW! ASP.NET courses you may be interested in:
2 Days of ASP.NET, 29 Sept 2003, in Redmond
http://www.develop.com/courses/2daspdotnet
Guerrilla ASP.NET, 13 Oct 2003, in Boston
http://www.develop.com/courses/gaspdotnet
View archives and manage your subscription(s) at http://discuss.develop.com
