Re: fields for methods?


On Fri, 13 Oct 2006, Jon Slaughter wrote:
"Arthur J. O'Dwyer" <ajonospam@xxxxxxxxxxxxxx> wrote...
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.
[fantasy C++ code]
struct A {
void foo();
};

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

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

Yes; there's no "duplicate information" in the fantasy code I posted.
(I've snipped the real-life C++ code that did contain duplication, or
at least a definition of 'i' far separated from its use.)

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.

But did you understand my "big drawback" above? I didn't explain it
very explicitly, I guess. The objection is that your idea can be
translated directly into C++, but only by a compiler that is allowed to
see all of your source code at once. You can't define 'A' in one module
and 'A::foo' in another module, and then compile each module separately
and link them together ("separate compilation", a cornerstone of the
C/C++/Unix-in-general programming model), because the definition of
'A::foo' actually adds the data field 'i' to the struct 'A', changing
the size of an 'A' object.

So my objection was essentially that your idea /cannot/ be "easily
translated" to C++, not by a traditional separate-compilation system.
You'll need a different programming model entirely.

Maybe C# doesn't support separate compilation already; I'm not that
familiar with the language. In that case, it wouldn't be a big deal,
and my objection would disappear.


[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).

Right, that's what I thought, and what I addressed in my comments above.

You can access the variable though through the function if you need to.

Whoa! You mean you want to write 'foo.i' to get at the value of
the variable 'i' in function 'foo'? I wouldn't want that; it seems like
it totally breaks the idea of encapsulation, which is the reason a lot
of people use OO in the first place. 'i' is local to 'foo', and shouldn't
be visible outside it unless the programmer wants it to be. (And the
programmer shouldn't want it to be.)

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)

Well, you keep saying "almost exactly like a class" --- so why not
just use a class? In C++, you'd be describing "a class that implements
a public operator() method", also known (IIRC) as a "functor".
Real-life C++ code:


struct A;

struct FooFunction {
private:
A *my_a;
public:
int i;
void operator() (void);
FooFunction(A *a): i(0), my_a(a) {}
};

struct A {
const char *name;
FooFunction foo;
A(const char *n): name(n), foo(this) {}
};

void FooFunction::operator() (void)
{
printf("%s: %d\n", my_a->name, i);
++i;
}

int main()
{
A a("a");
A b("b");
a.foo();
a.foo();
b.foo();
b.foo();
printf("%d %d\n", a.foo.i, b.foo.i);
return 0;
}

This seems to do exactly what you're asking for, but in terms of
existing primitives, and in a way that doesn't break separate compilation.
(So I guess you could make a compiler that implemented all methods
as functors, and it would satisfy your need for convenient syntax
without breaking separate compilation, but at a terrible cost in
efficiency. I wouldn't recommend it.)

-Arthur
.