fields for methods?

[Jon Slaughter]

I was wondering if maybe allowing "fields" for methods. The reason is to
encapsulate the data that is mainly used by the method and to prevent the
need of having to create new variables every time the function is called if
you know they need not change within the method.

In a sense these would be equivilent to passing arguments to the method or
equivilent to local variables... but these arguments or variables always
have the same run-time values in the method's scope.

So we could have

public void SomeFunc(Some Params, object O)
{
....
}

public void SomeFunc(Some Params)
{
object O = new Object;
....
}
(would waste cycles because we allocate and deallocate O every function call
even if O if O is some constant value w.r.t to the method. )

object O;
public void SomeFunc(Some Params)
{
(uses object O)
....
}

etc..

But we know that 99% of the time object O does not change in the methods
call.

Why not have something like

public void SomeFunc(Some Params)
[Object O = some value]
{
(uses object O)
....
}

and we can access O by SomeFunc.O or SomeFunc().O or whatever. (I'm not
saying the syntax has to be strictly as I have shown).

One could even has getters and setters for O with an ability for default
initialization

public void SomeFunc(Some Params)
[ private Object o;
public Object O
{
init {o = initial value;}
get {return o;}
set {o = value;}
}
}
{
(uses object O)
....
}

or how ever one really wants to do this. I know you can use the above
methods to do this but it seems that one looses the ability to encapsulate.
Ofcourse with a lot of variables it could get messy quick.

In essense a method would be very similar to a class but we wouldn't have to
do something like

public static class MyFunc
{
public return value;
private Object o;
public Object O
{
init {o = initial value;}
get {return o;}
set {o = value;}
}
MyFunc(some Params)
{
(uses O)
return value;
}
}

which is essentially what the above would be equivilent to. Here we can use
MyFunc.O and call MyFunc just like a method but the return value is hard to
use(although maybe the ability to return it directly or indirectly like this
would be could so one could do MyFunc.Result or MyResult = MyFunc()... and
one has to declare the constructur and stuff so its a little extra work.

Just seems like there could be some room for improvement?

Any ideas?

Thanks,
Jon

 

[Bruce Wood]

I was wondering if maybe allowing "fields" for methods. The reason is to
encapsulate the data that is mainly used by the method and to prevent the
need of having to create new variables every time the function is called if
you know they need not change within the method.

One can already do this, simply by making the field a field of the
class and having the method be the only one that uses it. All of the
behaviour that you describe can be produced using class fields.

The only difference, therefore, is scope: in your proposed extension,
the field is local to the method and cannot be used outside the method.
In the current C# the field is local to the class and can be used by
any method / property in the class.

Jon Skeet has proposed something similar: a field that is local to a
property, which is a much more common scenario: a property wraps a
field that is not used anywhere else in the class. However, the
motivation behind this is different: the idea is to encapsulate more
information about how the field is meant to be used, so that the
compiler can enforce the rule: this field is read / written only via
this property, even within this class.

In your case, you're wanting to avoid the overhead of allocating and
collecting objects across method calls. Unfortunately, it's rather more
complicated than you stated.

First, it should be a given that allowing a "temporary variable" to
live from one method call to another makes sense in only two
situations. 1) The variable is part of the class state (in which case
it's not really "temporary" at all); in this case, it belongs at the
class scope, not the method scope. 2) The variable is unchangeable, and
so will not cause different results for subsequent method calls.

Ignoring case #1 (which already has a solution), case #2 is first of
all not a common scenario, and second of all can't be guaranteed by the
language except by creating an instance of an immutable class. While
you can use the "readonly" modifier to guarantee that a particular
reference will always point to the same object instance, you cannot
guarantee that the state of that instance cannot change--that depends
entirely upon its type (class) definition. If the type definition
allows the instance's state to change, then you have the classic case
of a method call that can return different things with the same inputs
depending upon what's happening with this "temporary" variable. In
effect, the "temporary" object becomes part of the instance state and
belongs at the class scope.

This leads into the whole problem of "constant" versions of objects,
which the C# team has chosen not to address thusfar because it means
support in the CLR (and thus modifications to the runtime).

Just seems like there could be some room for improvement?

Well, there's always room for improvement, but the question is whether
the problem is common enough and causes enough grief to warrant the
added complexity that the solution would introduce into the language.
In this case, the problem seems uncommon and easy to solve using other
means, although the solution is not 100% satisfactory. The solution
would seem to require complicated modifications to the runtime and the
compiler.

 

[Jon Slaughter]

One can already do this, simply by making the field a field of the
class and having the method be the only one that uses it. All of the
behaviour that you describe can be produced using class fields.

yeah, but you have to describe the class differently than the method I
stated. You are declaring a global variable w.r.t to the method. You cannot
enforce encapsulation of the field and other methods could change it. By
making the field local only to the method and allowing access rights you do
not have to worry about this. You also get the benifit of the similar
declarations being defined in the same place instead of possibily having
them get sepeated.

The only difference, therefore, is scope: in your proposed extension,
the field is local to the method and cannot be used outside the method.
In the current C# the field is local to the class and can be used by
any method / property in the class.

yes... and I think this is a bad idea. You have to declare the field
somewhere where its not used, you have to initalize it somewhere else and
then use it somewhere else. Why not do that all in one place instead of
them down?

Jon Skeet has proposed something similar: a field that is local to a
property, which is a much more common scenario: a property wraps a
field that is not used anywhere else in the class. However, the
motivation behind this is different: the idea is to encapsulate more
information about how the field is meant to be used, so that the
compiler can enforce the rule: this field is read / written only via
this property, even within this class.

I thought of this earlier too and asked about it but just got a lot of
nonsense replies. I think the idea is very similar to what you just said
though. You are just including a property in the method to encapsulate it.
Within the scope of the method the property is global but it is not visual
outside as a normal property is. It can be accessed though if it has the
property modifiers through the function itself so it can be changed as if it
were a global field. The point is that one would use these types of
properties when the it won't often be used as like a global field.

In your case, you're wanting to avoid the overhead of allocating and
collecting objects across method calls. Unfortunately, it's rather more
complicated than you stated.

First, it should be a given that allowing a "temporary variable" to
live from one method call to another makes sense in only two
situations. 1) The variable is part of the class state (in which case
it's not really "temporary" at all); in this case, it belongs at the
class scope, not the method scope. 2) The variable is unchangeable, and
so will not cause different results for subsequent method calls.

Actually I'm refering to case 1. It maybe be true that it has a solution.
This does not nessarily mean that is the best solution. Sure the language
allows for what I'm talking about... just as you can do C++ templates
without C++ by doing everything "manually". Its not necessarily the case
that it does it better though. Now my idea is not such a grand leap as
templates was but it does offer just an extra bit. Ofcourse it doesn't
prevent one from using the old ways but just allows for one to do something
in a new way that might be potentially better. IMO the argument that just
cause you can do it now already is not a valid one. You can do just about
anything you want in any language if you tried hard enough. Its about ease
of use and creating features that make programming in it easier. I think if
one had the mentality that you seem to be proposing(and a lot of people seem
to say the same thing) then we still would be using machine language or
punch cards. Ofcourse what I'm saying is not a big deal. It doesn't offer
much but does offer something new. It might not be worth it for many though
as I suppose that tradition and habits are much stronger.

Ignoring case #1 (which already has a solution), case #2 is first of
all not a common scenario, and second of all can't be guaranteed by the
language except by creating an instance of an immutable class. While
you can use the "readonly" modifier to guarantee that a particular
reference will always point to the same object instance, you cannot
guarantee that the state of that instance cannot change--that depends
entirely upon its type (class) definition. If the type definition
allows the instance's state to change, then you have the classic case
of a method call that can return different things with the same inputs
depending upon what's happening with this "temporary" variable. In
effect, the "temporary" object becomes part of the instance state and
belongs at the class scope.

This leads into the whole problem of "constant" versions of objects,
which the C# team has chosen not to address thusfar because it means
support in the CLR (and thus modifications to the runtime).

I really don't see how 2 is any different from a static variable?

Well, there's always room for improvement, but the question is whether
the problem is common enough and causes enough grief to warrant the
added complexity that the solution would introduce into the language.
In this case, the problem seems uncommon and easy to solve using other
means, although the solution is not 100% satisfactory. The solution
would seem to require complicated modifications to the runtime and the
compiler.

I understand. What I feel is an improvement might not be to someone else.
And I suppose if your used to doing it one way and even if there comes about
a slightly better way you still will use the old way rather than learn the
new. Ofcourse I think this does limit potential growth I do understand it.
You can't keep learning new things because then you never get to use them.

Thanks,
Jon