Language enhancement idea: C# method instance fields

[William Stacey [MVP]]

I think if they did something like this, that method sounds pretty good at
first glance. Not sure all the different factors that could torpedo the
idea, but it looks interesting. After all, Powershell has different kinds
of scoping too, so maybe the two can rub on each other to share some ideas.

--
William Stacey [MVP]

| 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?
|
| }
|
|
| "WXS" wrote:
|
| > 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.
| >
| >
| >
| > "kh" wrote:
| >
| > > 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
| > >

 

[William Stacey [MVP]]

Possibly that method could also be used to define "invariant sets/groups"
and access levels such as some form of locking rules and other properties.

--
William Stacey [MVP]

|I think if they did something like this, that method sounds pretty good at
| first glance. Not sure all the different factors that could torpedo the
| idea, but it looks interesting. After all, Powershell has different kinds
| of scoping too, so maybe the two can rub on each other to share some
ideas.

 

[Guest]

That would be a good idea. I would suggest some more people file the
suggestion MS closed the initial one... I don't think they read the followups