Re: fields for methods?


"Arthur J. O'Dwyer" <ajonospam@xxxxxxxxxxxxxx> wrote in message
news:Pine.LNX.4.61-042.0610121842060.11979@xxxxxxxxxxxxxxxxxxxxxxxx

[microsoft.public.dotnet.languages.csharp dropped because my server
doesn't carry it; feel free to repost this post over there]

On Thu, 12 Oct 2006, Jon Slaughter wrote:

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 equivalent to passing arguments to the method
or equivalent to local variables... but these arguments or variables
always have the same run-time values in the method's scope.

So you're talking about the behavior that can be produced in C++ by

struct A {
int i;
void foo();
};

void A::foo() {
printf("%d\n", i);
++i;
}

--- that is, there's one instance 'i' for each different instance of 'A',
and it is used inside 'foo', and it maintains its value between calls.
Except, for documentary purposes and to avoid bugs, you want to make
sure 'i' is visible only inside 'foo', so you want to write

struct A {
void foo();
};

void A::foo() {
static_instance i;
printf("%d\n", i);
++i;
}

Notice my choice of magic keyword! I had incorrectly thought that
C++'s "static" would do exactly what you asked for, but it turns out
that "static" always creates exactly one instance of 'i', shared by
all the instances of 'A'. So if you don't want 'i' visible outside
of 'foo', then I think you really are asking for something that's
not in C++, or any other language I know.


I don't think this is what I'm after. The struct you give above is correct
in that it is equivilent to my idea but here I want to remove the duplicate
information.

If we think of a function as a static class with fields and methods then it
approximates the idea. But here we only want the class to contain one
method. And instead of having to access that method through the class the
class and the method are the same. Its kinda short hand of notation.

I think it would be useful, and something I'd like to see in a new
C++-style language, but I can think of one big drawback right off
the top of my head --- it would totally bork the C linker model,
where you're allowed to compile source files separately and then
link them together later on. You'd have to compile, or at least scan
through, every member function of 'A' before you knew the size of an
instance of 'A'. The loss of separate compilation, IMVHO, would be a
big drawback for a lot of customers.


I'm not quite sure its exactly what I want but I do see your point. The way
I see it though is that we are just making a notational convience(Which is
how I see most of C++ compared to C) to simplify coding. Why I think about
it this way is because my ideas are always easily translated into pure C#(or
C++ or whatever were talking about). So its more about convenience than
anything. It does have "side effects" though such as encapsulation and such
and thats half the reason for it.


[big snip]
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.

I have absolutely no idea what "this" is. It looks to me like you're
just trying to define a new class 'O' which is local to 'SomeFunc'; I
believe C++, C#, and Java already have that capability, so you don't
need to make extra provisions for it in your syntax.


The idea is that instead of having to create a global variable w.r.t to the
function you create it inside the function. The variable has the same life
time as the function(Which means forever). You can access the variable
though through the function if you need to. Its very similar to classes but
with a different syntax. Its extending the idea of a function to allow
fields in it. (almost exactly like a class but a class is more general
purpose)

HTH,
-Arthur

P.S.: It's spelled "equivalent." I see programmers spell it wrong all
the time now, for some reason. Think "equi-", equal; "valent", value.
Like "valence electrons" from high-school chemistry. Not "equivilent",
"equivilant", "equuvulunt", or any other combination of vowels.

lol. Ok, I'll try to remember that.

Thanks,
Jon


.

Relevant Pages

  • Re: Library bug or my fault?
    ... void memcpy ... struct Foo { ... 29 void cp(const Foo *foo) ... You have no definition for cp2so the code above won't compile. ...
    (comp.lang.c)
  • Re: fields for methods?
    ... void A::foo{ ... and it is used inside 'foo', and it maintains its value between calls. ... You'd have to compile, or at least scan ... methods to do this but it seems that one looses the ability to encapsulate. ...
    (comp.programming)
  • ifstream as parameter
    ... The code below does not compile with the message ... It's the function call to "foo" that does not work. ... (It works fine if I use void foo(ifstream& fil) ...
    (comp.lang.cpp)
  • Re: menu-based console application
    ... typedef void; ... struct MenuEntry ... Compile everything, fix typing errors and run the program. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: pass by Reference/value ???
    ... > void foo ... this would be called "passing by reference". ... foo receives a local copy of s and any changes that it makes to s only ... Since s is a pointer, a variable storing the address of s is a pointer to ...
    (comp.lang.cpp)