Re: Language enhancement idea: C# method instance fields
- From: WXS <WXS@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 15 May 2006 08:47:02 -0700
Actually the other methods suggested, like Restrict to method or Scoping may
improve the usability of the other variations. As it is VERY often that I
want to restrict access to a variable to a set of methods (many times too few
to break out to a seperate class).
So some variation of this allowing you to specify the set of methods the
variable should be allowed to be accessed in would be a great way to clearly
indicate in code, member variable intention which is lacking in many
languages including C#.
"Nicholas Paldino [.NET/C# MVP]" wrote:
I think that you are thinking a little bit too much into it. The.
feature would be for 99% of the use cases, where you are going to have that
state be applicable to only that method, nothing else.
It is intended to be very, very specialized. Granted, with the way that
the OP suggests, it leaves an option open to be expanded. I don't think
this is the right way to do this.
First, you can not apply attributes to variables inside of the method
body. To say that now you could do so would introduce a whole new set of
rules and conditions that have to be formulated (what are the conditions and
how does a variable in a method react, what are the changes to the CLR and
the Reflection namespace that have to be made) in order to accomidate this.
This is why the keyword is better (I recommended "static"). It doesn't
allow for expansion (you can pass parameters to an attribute, but the
keyword applies to what it is modifying, without the ability to
"parameterize" it like an attribute), and it is very specific in its
application.
Second, using the "static" keyword keeps feature in line with the same
feature in C++.
--
- Nicholas Paldino [.NET/C# MVP]
- mvp@xxxxxxxxxxxxxxxxxxxxxxxxxxx
"kh" <kh@xxxxxxxxxxxxxxxxx> wrote in message
news:D76B5835-BB99-4664-81BD-53E1C7682B50@xxxxxxxxxxxxxxxx
I'm still not convinced, although I recognise the issue you are
describing.
In many ways you are may just be creating a new set of problems with
regards
to the correct decoration of fields with your new attribute. For example,
what if I want one writer but multiple readers for this data? It starts to
get a bit messy, although not totally unmanageable.
Personally if I have state which is highly specialised but still related
to
my class as a whole I would implement as a nested class (for example,
think
Enumerators, which must own and manage the current position of the
enumeration).
Interesting suggestion though. Will be interesting to see how a discussion
on this topic progresses.
kh
- Follow-Ups:
- References:
- Language enhancement idea: C# method instance fields
- From: WXS
- RE: Language enhancement idea: C# method instance fields
- From: kh
- RE: Language enhancement idea: C# method instance fields
- From: WXS
- RE: Language enhancement idea: C# method instance fields
- From: WXS
- Re: Language enhancement idea: C# method instance fields
- From: Nicholas Paldino [.NET/C# MVP]
- Language enhancement idea: C# method instance fields
- Prev by Date: Re: Comparing objects
- Next by Date: Re: ADO C# VB Difference
- Previous by thread: Re: Language enhancement idea: C# method instance fields
- Next by thread: Re: Language enhancement idea: C# method instance fields
- Index(es):
Relevant Pages
|