473,382 Members | 1,086 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,382 software developers and data experts.

Language improvement: Add scope to class member fields

WXS
Vote for this idea if you like it here:
http://lab.msdn.microsoft.com/produc...5-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 } }
May 26 '06 #1
7 2087
WXS <WX*@discussions.microsoft.com> wrote:
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

--
http://barrkel.blogspot.com/
May 26 '06 #2

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:10********************************@4ax.com...
WXS <WX*@discussions.microsoft.com> wrote:
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.


Agree 100% with you !!!

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

--
http://barrkel.blogspot.com/

May 26 '06 #3
WXS
(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.

"Barry Kelly" wrote:
WXS <WX*@discussions.microsoft.com> wrote:
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

--
http://barrkel.blogspot.com/


"Barry Kelly" wrote:
WXS <WX*@discussions.microsoft.com> wrote:
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

--
http://barrkel.blogspot.com/

May 26 '06 #4
WXS
>> 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.
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).

"Barry Kelly" wrote:
WXS <WX*@discussions.microsoft.com> wrote:
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

--
http://barrkel.blogspot.com/

May 26 '06 #5
WXS wrote:
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.
May 28 '06 #6
Hi,

"Paul E Collins" <fi******************@CL4.org> wrote in message
news:Tr********************@bt.com...
WXS wrote:
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.

The OP wants to restrict the access to members from another members in the
same class.
--
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
May 30 '06 #7
WXS
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.

"Paul E Collins" wrote:
WXS wrote:
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.

May 30 '06 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: wwight | last post by:
As many people have noticed by now, PHP exhibits some frustrating behavior when it comes to static fields and methods. For instance, when a static method is defined in a parent class, but called...
6
by: Razvan | last post by:
Hi, I took a C++ test and I found the following question: Q. Inside a class member function definition, which scope is searched
8
by: Adam | last post by:
I've seen lots of mentions of the scope of an "internal" class. What's the scope of an "internal" method. Why would one use it as opposed to an "internal" class? Thanks in advance. Adam
14
by: Magius | last post by:
Hello, I have a question about the correctness of the language grammar for the C# 2.0 specification. I am working with the grammar specified in the June 2005 ECMA-334 standard. Basically, a...
39
by: utab | last post by:
Dear all, Is there a clear distinction how to decide which functions to be members of a class and which not How is your attitude (Your general way from your experiences ...) "If the...
22
by: WXS | last post by:
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...
5
by: Jeff | last post by:
Hey Below is a C# program I've made.... it's an app where I experiment with variable scope. In this code you see two variables named i (one is a local variable and the other is a member of the...
5
by: Steven T. Hatton | last post by:
If find the following excerpt from the Standard a bit confusing: <quote> 3.3.6 - Class scope -1- The following rules describe the scope of names declared in classes. 1) The potential scope...
7
by: The Cool Giraffe | last post by:
Usually, when i declare a method and a variable in the header file i go as follows. public: int number; void doSome (); Then, in the CPP-file i will define it as follows. int number;
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.