Language enhancement idea: C# method instance fields

[Guest]

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such that
from a maintenance stand point it is disconnected from the method, and also
affords the opportunity for other methods to mess with the variable when they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used by
another method not listed as a friend.

 

[Greg Young]

I agree that further granularization on instance fields would be nice ... in
fact I did it myself .. You can easily implement such behaviors using XC#
http://www.resolvecorp.com/ as it allows you to implement compiler
extensions. You can also do many other useful things like define invariants
as part of your contract.

Cheers,

Greg Young
MVP - C#

 

[Greg Young]

Also I might call it a [RestrictToMethod(method)] as it makes a bit more
sense than "Friend" which has a much different meaning.

Cheers,

Greg Young
MVP - C#

 

[Nicholas Paldino [.NET/C# MVP]]

I think that there are times that this would be helpful.

You should go to the Product Feedback Center and put in the suggestion,
then post the link to the suggestion here so that people can vote on it:

http://lab.msdn.microsoft.com/productfeedback/

It wouldn't be that hard to do really, it would just be some more
"compiler" magic. VB does this with the static keyword, where the compiler
mangles the name of the variable and then uses it as a field in the class.

Also, it would have to be a keyword that is applied to the variable
declaration, not an attribute, since attributes are not valid inside
methods. You would need something like:

public void DoSomething()
{
// Indicate that this should be static inside the method.
static int myVar = 0;
}

This would also probably indicate that this is set when the class is
created, not on its first use.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such
that
from a maintenance stand point it is disconnected from the method, and
also
affords the opportunity for other methods to mess with the variable when
they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used
by
another method not listed as a friend.

 

[Guest]

I think those are good ideas.

Here is the link for people to vote for this:
http://lab.msdn.microsoft.com/produ...edbackid=35ae1477-5eab-47e1-9129-372d0d89e479

I think that there are times that this would be helpful.

You should go to the Product Feedback Center and put in the suggestion,
then post the link to the suggestion here so that people can vote on it:

http://lab.msdn.microsoft.com/productfeedback/

It wouldn't be that hard to do really, it would just be some more
"compiler" magic. VB does this with the static keyword, where the compiler
mangles the name of the variable and then uses it as a field in the class.

Also, it would have to be a keyword that is applied to the variable
declaration, not an attribute, since attributes are not valid inside
methods. You would need something like:

public void DoSomething()
{
// Indicate that this should be static inside the method.
static int myVar = 0;
}

This would also probably indicate that this is set when the class is
created, not on its first use.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such
that
from a maintenance stand point it is disconnected from the method, and
also
affords the opportunity for other methods to mess with the variable when
they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used
by
another method not listed as a friend.

 

[Guest]

I agree that is a better name for it.

Also I might call it a [RestrictToMethod(method)] as it makes a bit more
sense than "Friend" which has a much different meaning.

Cheers,

Greg Young
MVP - C#

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such
that
from a maintenance stand point it is disconnected from the method, and
also
affords the opportunity for other methods to mess with the variable when
they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used
by
another method not listed as a friend.

 

[Guest]

Thanks for the pointer on XC# that is pretty cool. I will have to look into
that. Not sure if I could get all of our product teams to agree to use it
though, so having this in the base language would still be nice.

I definately need to look at XC# a more closely though.

Thanks

I agree that further granularization on instance fields would be nice ... in
fact I did it myself .. You can easily implement such behaviors using XC#
http://www.resolvecorp.com/ as it allows you to implement compiler
extensions. You can also do many other useful things like define invariants
as part of your contract.

Cheers,

Greg Young
MVP - C#

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such
that
from a maintenance stand point it is disconnected from the method, and
also
affords the opportunity for other methods to mess with the variable when
they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used
by
another method not listed as a friend.

 

[Guest]

I'm not convinced this is a requirement. In your example, the fact that the
data has been sent is object state just like any other field is object state,
even if, as you point out, it is only used by one method.

What if a field is only used by two methods? Another overload on the
RestrictToMethod() attribute? State is state, no matter how localised it's
usage.

Just my opinion

kh

 

[Guest]

The point is you want to limit access to that state to only methods that
should be using it. The only alternative to this is creating a base class or
seperate class for every even slightly different set of functionality to
ensure proper encapsulation, which would just be too heavy in the amount of
objects created or be limited by single class inheritance, or result in
proxies to many small internal classes.

The other point is how do you know as a developer what private field is used
by which methods? Find? If you have a nice third party tool "Find usages",
but those things just find present usages and don't limit scope.

From a maintenance standpoint those fields and methods are so disconnected
the only way you can link them now is throw some comments on them, and that
obviously isn't enforced by the compiler either.

I think this method would help better encapsulate sets of functionality.

Imagine you internally use an ArrayList but you don't want any old method in
your class to directly access it you want to protect it so that only two
methods can access it, Add() and Remove() methods.

So the example is:
public class MyClass{

[RestrictMethods(Add(object),Remove(object))]
ArrayList array_=new ArrayList();

protected void Add(object obj)
{
//Do some validation on the object here for example
array_.Add(obj);
}

protected void Remove(object obj)
{
//Do some validation on the object here
array_.Remove(obj);
}

}

One might argue if you are doing that create a seperate class or use a
generic array, but really those are often impractical. The generic class of
List<object> wouldn't do the validations I want. A seperate class could but
requires me to create a whole breakout class for something I just use
internally and most developers wouldn't do.

I'm not convinced this is a requirement. In your example, the fact that the
data has been sent is object state just like any other field is object state,
even if, as you point out, it is only used by one method.

What if a field is only used by two methods? Another overload on the
RestrictToMethod() attribute? State is state, no matter how localised it's
usage.

Just my opinion

kh

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such that
from a maintenance stand point it is disconnected from the method, and also
affords the opportunity for other methods to mess with the variable when they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used by
another method not listed as a friend.

 

[Guest]

Imagine some additional code in that class that does other things to but
other methods just use Add/Remove... I should have included that in the
example to clarify a bit better.

The point is you want to limit access to that state to only methods that
should be using it. The only alternative to this is creating a base class or
seperate class for every even slightly different set of functionality to
ensure proper encapsulation, which would just be too heavy in the amount of
objects created or be limited by single class inheritance, or result in
proxies to many small internal classes.

The other point is how do you know as a developer what private field is used
by which methods? Find? If you have a nice third party tool "Find usages",
but those things just find present usages and don't limit scope.

From a maintenance standpoint those fields and methods are so disconnected
the only way you can link them now is throw some comments on them, and that
obviously isn't enforced by the compiler either.

I think this method would help better encapsulate sets of functionality.

Imagine you internally use an ArrayList but you don't want any old method in
your class to directly access it you want to protect it so that only two
methods can access it, Add() and Remove() methods.

So the example is:
public class MyClass{

[RestrictMethods(Add(object),Remove(object))]
ArrayList array_=new ArrayList();

protected void Add(object obj)
{
//Do some validation on the object here for example
array_.Add(obj);
}

protected void Remove(object obj)
{
//Do some validation on the object here
array_.Remove(obj);
}

}

One might argue if you are doing that create a seperate class or use a
generic array, but really those are often impractical. The generic class of
List<object> wouldn't do the validations I want. A seperate class could but
requires me to create a whole breakout class for something I just use
internally and most developers wouldn't do.

I'm not convinced this is a requirement. In your example, the fact that the
data has been sent is object state just like any other field is object state,
even if, as you point out, it is only used by one method.

What if a field is only used by two methods? Another overload on the
RestrictToMethod() attribute? State is state, no matter how localised it's
usage.

Just my opinion

kh

Sometimes a method in a class requires the use of class instance
variables/fields that will not be used outside of the method itself.
Currently this means you must create a instance field in the class such that
from a maintenance stand point it is disconnected from the method, and also
affords the opportunity for other methods to mess with the variable when they
never should.

For example:

public class MyClass
{

bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}

Notice out method has no connection to the field even though it is
the only method that should be using it. So there is both a maintenance
issue and a chance for accidentally mucking with the state external from
the method.
--------------------------------------------------------------------
Instead what if we could declare the class/method like this.

public class MyClass
{

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
[InstanceField]
bool dataSent_=false;

if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

}


The beauty of this solution is the field that is used only by the method

is directly connected to and only accessible from the method that uses

it. This clarifies the field usage clearly and prevents mucking with

this value elsewhere.

The only issues I see with this are if you needed to clone the object

state it could be a problem depending on your objects usage.

An Alternative to this pattern that is not quite as encapsulated but is

more flexible is to explictly tag the variable with friend methods.


Such as:

public class MyClass
{

[FriendMethods(SendDataFirstTimeOnly,Clone)]
bool dataSent_=false;

/* IMAGINE TONS OF OTHER CODE HERE */

public void SendDataFirstTimeOnly()
{
if (!dataSent_)
{
Do this();
dataSent_=true;
}
}

public object Clone()
{
MyClass clone=new MyClass()
clone.dataSent_=dataSent_;
return clone;
}

}


This clearly defines/associates which methods are allowed to use the
instance field AND enforces it, as a compiler error should result if used by
another method not listed as a friend.

 

[Guest]

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

 

[Guest]

Actually the reader writer may be a perfect example of a good usage. Imagine
I want a reader/writer lock and I really only want this used by two critical
methods one reads and one writes in the class. This technique would limit
the scope of that sync object to those methods, this would help avoid
inappropriate usage. You are correct a seperate class could encapsulate
this, but think of the number of associations you may have like this in an
individual class and the number of internal classes you would have to create
would either become unmanageable from a maintenance standpoint or from a
memory allocation standpoint you are creating lots of classes. Not to
mention the performance hit of going through another class. And in my line
of development performance is critical.

I have seen this maintenance nightmare time and again, and just thought this
might be a practical solution to the problem, as the marjority of developers
I have seen do not have your rigour in terms of creating abstracted classes
for these things. While definately that encapsulates the functionality
better I think the granularity involved here is too granular to require
potentially many classes to get those associations.

From a XP development style principle the code becomes the documentation,
and right now rarely do I see the code descriptive enough to establish
linkage of a method to an instance variable.

I do understand your point though and I do think that is the right solution
for larger less granular functionality sets.

Thanks for the comments

 

[Nicholas Paldino [.NET/C# MVP]]

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++.

 

[Guest]

Actually you spawned a related idea I think would really be cool, if we could
figure out how to make it work (though I can't at present).

In a similar threading vain I often wish I could express in code:
You MUST lock this lock object to access this variable. This is not often
easy to encapsulate in methods because sometimes granularity of the lock is
at issue.

If we had something like:
class MyClass
{

[RequireLockThisWhenUsing(myCounter_)]
object myCounterLock_=new object();

object otherLock_=new object();

int myCounter_=0;

public void IncrementCounter()
{
lock(otherLock_)
{
myCounter++; //Would be nice if this were a compiler error
}
}

}

Obviously there are A LOT of problems with this, as sometimes locks would
not be scoped to a function, and there would be no way at compile time to
discern this so it would have to be a runtime detection (which still wouldn't
be bad). But sure there are performance overheads and many other issues like
that.

But the point is from this you can see how important it could be if you
could associate fields, with methods or potential other fields in some way as
in this case.

 

[Guest]

I like the keyword idea. Probably something other than static would be good
as we don't want to imply type variable we want to mean instance variable.

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]
- (e-mail address removed)

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

 

[cody]

maybe you can use the private keyword for that. here I demonstrate it for a
property:

public int A
{
private int a = 0;
get {return a;}
set {a=value;}
}

it is already a reserved word but currently has no meaning / is illegal in
methods so things do not brake.
also we imply that the variable is "private" to that method.

maybe we can use "protected" to allow overriders to allow acces to that
variable too.

...and static to make it static. or volatile. at the end we can allow almost
all modifiers that are also allowed for normal instance members. why not

--

I like the keyword idea. Probably something other than static would be
good
as we don't want to imply type variable we want to mean instance variable.

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]
- (e-mail address removed)

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

 

[Guest]

Actually everyone's thoughts gave me an alternative idea that I think would
have some merit in certain cases.

What if I could write:

class MyClass
{

scope {
bool sentData_=false;

public void SendData()
{
if (!sentData_)
{
//DoSend()
sentData_=true;
}
}

}

Where scope can organize a set of methods with access to particular variables.

Obviously there are isssues and concerns about overlap, an what if a method
needed access to only one of the variables in that scope but not all and
something from another scope. So not sure how viable this is but something
to think about if there is some way to improve... ideas?

}

Actually you spawned a related idea I think would really be cool, if we could
figure out how to make it work (though I can't at present).

In a similar threading vain I often wish I could express in code:
You MUST lock this lock object to access this variable. This is not often
easy to encapsulate in methods because sometimes granularity of the lock is
at issue.

If we had something like:
class MyClass
{

[RequireLockThisWhenUsing(myCounter_)]
object myCounterLock_=new object();

object otherLock_=new object();

int myCounter_=0;

public void IncrementCounter()
{
lock(otherLock_)
{
myCounter++; //Would be nice if this were a compiler error
}
}

}

Obviously there are A LOT of problems with this, as sometimes locks would
not be scoped to a function, and there would be no way at compile time to
discern this so it would have to be a runtime detection (which still wouldn't
be bad). But sure there are performance overheads and many other issues like
that.

But the point is from this you can see how important it could be if you
could associate fields, with methods or potential other fields in some way as
in this case.

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

 

[Guest]

Something along these lines feels more embedded into the language which would
be nice if there were a way to work out the, union cases and others.

Actually everyone's thoughts gave me an alternative idea that I think would
have some merit in certain cases.

What if I could write:

class MyClass
{

scope {
bool sentData_=false;

public void SendData()
{
if (!sentData_)
{
//DoSend()
sentData_=true;
}
}

}

Where scope can organize a set of methods with access to particular variables.

Obviously there are isssues and concerns about overlap, an what if a method
needed access to only one of the variables in that scope but not all and
something from another scope. So not sure how viable this is but something
to think about if there is some way to improve... ideas?

}

Actually you spawned a related idea I think would really be cool, if we could
figure out how to make it work (though I can't at present).

In a similar threading vain I often wish I could express in code:
You MUST lock this lock object to access this variable. This is not often
easy to encapsulate in methods because sometimes granularity of the lock is
at issue.

If we had something like:
class MyClass
{

[RequireLockThisWhenUsing(myCounter_)]
object myCounterLock_=new object();

object otherLock_=new object();

int myCounter_=0;

public void IncrementCounter()
{
lock(otherLock_)
{
myCounter++; //Would be nice if this were a compiler error
}
}

}

Obviously there are A LOT of problems with this, as sometimes locks would
not be scoped to a function, and there would be no way at compile time to
discern this so it would have to be a runtime detection (which still wouldn't
be bad). But sure there are performance overheads and many other issues like
that.

But the point is from this you can see how important it could be if you
could associate fields, with methods or potential other fields in some way as
in this case.

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

 

[Guest]

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#.

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]
- (e-mail address removed)

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

 

[cody]

You forgot that in 99% of the usual cases you just want to restrict *one*
variable to its *single* encapsulating property in which case a scope block
would be a bit overkill.
Additionally you will soon notice that things start to overlap and you'll
soon find yourself moving methods and variables around, from one scope block
to another or out of scopeblocks because you encountered overlaps.
This feature will certainly not increase any productivity

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#.

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]
- (e-mail address removed)

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