Language improvement: Add scope to class member fields

[Guest]

Vote for this idea if you like it here
http://lab.msdn.microsoft.com/produ...edbackid=5fee280d-085e-4fe2-af35-254fbbe96ee9
-----------------------------------------------------------------------------
This is a consortium of ideas from another thread on topic
-----------------------------------------------------------------------------

One of the big issues of organizing items within a class, is there are many
times subsets of functionality where only certain methods should have access
to certain variables, and there is currently no declarative way to state or
maintain this in the language.

Here is just one example, but imagine other variations of member
variable/method associations:
So for example if you had a complex class that internally maintained an
array for its own private use, and you added methods Add, Remove and Get and
wanted to make sure those were the only methods that had access to that
variable because it needed to be locked for multithreading purposes, there is
no way to enforce or ensure this in the language and results in numerous
accidental, or even purposeful uses of the underlying variables
inappropriately counter to the original design.

Note this suggestion along these lines has received positive feedback in the
newsgroups. This is a variation on another suggestion that I think makes it
more broadly applicable and appropriate. I can assure you this type of thing
has come up constantly in development, not having a declaritive way to
associate variables with the methods that should use them.


Proposed Solution:
What if I we 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?

}

Compiler errors WXS123, 2006-05-25

Any uses of the variables outside of the scoped variables/methods should
result in compiler errors.


--------------------------------------------------------------------------------

Very common scenario WXS123, 2006-05-25

In any reasonably sized class it is probably very rare that every method
needs access to, or even should have access to every variable in the class.
Given that, it makes sense to scope the variables to a set of methods that
are allowed access. This organizes both mentally for the developer and
deterministically for compilation. It is common to have internal subsets of
functionality within a class that are used as private helpers to other
methods. Currently all variables and all methods are fare game. It may even
make sense to find some way to scope methods in such a way that they should
only be used by a small subset of other methods. Otherwise with current
functionality once you are inside a class, it is the wild west, anybody can
party on anything. One could try to argue to break out subsets into other
classes. But many times the set of functionality is so limited, it would be
like a micro class... making it available as a class would require possibly
more functionality and interface thought to make it right, thus most
developers rarely would do that and instead just create the few methods that
work with some member fields in the class and be done with it. And with
several of those subsets it is not only hard to discern what variables work
with which methods, but can be functionally disasterous if a variable that is
supposed to be protected by locking before accessing is used directly in
another method. When you have a team of developers adding functionality to
classes this becomes a major issue in organization and use.


--------------------------------------------------------------------------------

Example of compiler error WXS123, 2006-05-26

class MyClass { scope { bool sentData_=false; public void SendData() { if
(!sentData_) { //DoSend() sentData_=true; } } public void
TryToUseVariableInappropriately() { sendData_=true; //Compiler error, this
method not scoped for this variable } }

 

[Barry Kelly]

So for example if you had a complex class that internally maintained an
array for its own private use, and you added methods Add, Remove and Get and
wanted to make sure those were the only methods that had access to that
variable because it needed to be locked for multithreading purposes,

This is where I part company with your approach. If the class is getting
complex, and it requires a set of methods to work on a subset of data,
then I think those methods and data should be refactored into another
class - a private inner class if necessary.

So not sure how viable this is but something
to think about if there is some way to improve... ideas?

Allowing classes to become more complex is not a terrific design goal,
IMHO. The two biggest problems in existing class library design I see on
a day to day basis are:

1) Classes that do too much. (User interfaces are a major culprit here,
especially ones designed with the IDE control surface designer.)

2) Classes, inheritance, interfaces, polymorphism etc. introduced for
"flexibility" or "extensibility" before it's a proven requirement.

Too few classes is often a symptom of the first, too many a symptom of
the second.

One could try to argue to break out subsets into other
classes. But many times the set of functionality is so limited, it would be
like a micro class...

I don't see the trade-off here. Either the functionality is trivial so
that scoping is overkill, or it is complex enough to put in a separate
class.

And with
several of those subsets it is not only hard to discern what variables work
with which methods

If you have several confusing sub-sets of state inside your class that
make implementing the class more difficult, all the more reason to
factor them into another class! In fact, I would consider this pain
point to be the motivating factor in creating the new class -
recognizing that a lump of behaviour and state needs to be encapsulated.
That's what classes are for.

but can be functionally disasterous if a variable that is
supposed to be protected by locking before accessing is used directly in
another method.

And a reference to an inner class gives you a handy thing to lock
against

-- Barry

 

[Ignacio Machin \( .NET/ C# MVP \)]

This is where I part company with your approach. If the class is getting
complex, and it requires a set of methods to work on a subset of data,
then I think those methods and data should be refactored into another
class - a private inner class if necessary.

Agree 100% with you !!!

Dont remember if you have this pattern in 2005 already though.

 

[Guest]

(Sorry if this is a dupe it timed out when sending it the first time and it
doesn't seem to be showing up yet)

The normal scenario is 90% of coding is done this way and does not break
every small subset of functionality into seperate classes. Should it? I'd
say depends on the usage. Sometimes having lots of other small
objects/classes being allocated can put a heavy burden on the GC, so is not
desireable. Sometimes wrapping and having every variable needed for those
methods is making it too isolated and requiring convoluted accessors to get
at the information/variables in a logical way.

This mechanism just adds an extra level of granularity. An example of this
general philosophy is MS for example adding anonymous delegates. The regular
delegates were perfectly fine right... better abstracted? But the reality is
the usage patterns called for it and for the majority of development work it
made it easier to work with and manage/understand the code.

Should the class be the end all boundary for scoping? Of course not, thats
why classes have methods that scope locals, methods that are public, private,
protected, protected internal, etc. Scoping helps clarify the meaning and
usage of things. The problem is there is little scoping for class fields and
methods in the same class. This party-on everything in your own class
approach rarely survives well in real world software cycle where tens of
developers are continually adding functionality with little if any time left
for refactoring and the testing that would be needed to do that.

In the ideal world everyone would buckle their seatbelt too... but real
world dilemas, schedules and timeframes unfortunately are a bit messy.
Having an extra mechnism that is easy in place for developers to isolate code
even within the same class could prove extremely useful.

..NET's single inheritance doesn't help the situation here, as it may have
made sense to abstract another class to derive from but that is not possible
in .NET would need to use proxies...etc.

A recent example I hit along these lines, was a multithreading timer
scenario where one function could potentially be called multiple times. So I
created a class member field like bool inMyMethod=false; This needed to be
protected by a lock as well.

MyMethod() would check this flag first within a lock and only run the method
if it was the first time through.

A second method called something like ResetFlagForMyMethod() can be called
within the class for other events and inside it just did lock(lockObject_) {
inMyMethod=false; }

I don't want any other methods using either the lock object I am using there
or the inMyMethod flag. This is so trivial it would make almost zero sense
to make a seperate class out of it, and because MyMethod requires some access
to other member variables in the current class would be problematic and too
coupled/confusing.

Within this class there are probably several little helpers with similar
types of variable usages, if I could scope those variables I could ensure no
one would use them inappropriately outside the intended methods. As it
currently stands there is no protection.

Very few, if any of the developers I know would abstract such small subset
of functionality for organizational purposes. Would you?

I agree with the general principle of class seperation but I think these
micro classes would just be too much for developers to deal with, and given
the code I have seen over the years I know that not doing that is the norm.

Don't get me wrong in the right cases I'm all for abstraction into other
classes, I just think there are these subsets of functionality even with
classes that I have seen consistently in real world code that cause problems
and confusion.

 

[Guest]

One could try to argue to break out subsets into other

I don't see the trade-off here. Either the functionality is trivial so
that scoping is overkill, or it is complex enough to put in a separate
class.

The functionality for the small subset of functionality is trivial but if
you have several of these small subsets of functionality within the class,
and allowing other methods to have access to variables that don't need is
sloppy and inappropriate but too trivial to warrant a class abstraction.
Also the code other than a naming convention or comments has no way to show
the "intention" of those variables as they are only intended for a specific
method/uses. And naming and commenting are not enforcing which could be
dangerous when you really needed a lock to use a specific variable or some
methods have side effects relative to member fields thus access to the fields
should be isolated from allowing other methods to use them inappropriately.

A language should have a way to express intention, just like in SQL you can
express constraints for fields. You should be able to express constraints for
access to fields (granted a different sort of constraint but hopefully you
see the general idea).

 

[Paul E Collins]

A language should have a way to express intention,
just like in SQL you can express constraints for fields.
You should be able to express constraints for access
to fields

You can constrain access to fields - by making them private, or by
exposing a property that does custom access checking when get/set is
called. You're just not breaking down your design into enough classes.

Eq.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

You can constrain access to fields - by making them private, or by
exposing a property that does custom access checking when get/set is
called. You're just not breaking down your design into enough classes.

The OP wants to restrict the access to members from another members in the
same class.

 

[Guest]

The idea is to restrict access even from other methods in the same class so
making things private does not help. Read the chain.. small subsets of
functionality within the same class often use a set of fields only for that
small subset of functionality. The functionality subset is so small that
breaking out to another class is unwarranted. But there are enough of these
small subsets of functionality (or even sometimes one is enough), that having
this type of isolation is helpful to people doing maintenance know the
intention of variables/methods. Currently it is a free for wall and every
method can access every variable/field. The only way a developer can relate
methods together with fields, is through comments, regions, etc, but no
compilation restriction which would provide the intention in the language
similar to that when you abstract classes.