Re: fields for methods?


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

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.


yes, but I'm saying that A and foo are the same thing and hence you can't
define them seperately. The language syntax makes it such that


struct A { void foo(); };

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

Is not possible because foo is the only member of A... so why not just call
it A? i.e.

function void A()
{
int static_instance i = 0;
printf("%d\n", i);
++i;
}

The two codes are identical but there syntax/grammar is different. It
doesn't matter how the compiler internally reprsents "function" if it is a
struct like you have shown or makes an "anonymous" global variable i such as


int i238483288394 = 0;
void A()
{
printf("%d\n", i238483288394);
++i238483288394;
}

but the above code is slightly different from what I want in the sense that
I do want in some way to get at the variable. Since the compiler generates
an anonymous variable(the i238483288394) at compile time theres no way to
know what it is. Instead I define it using some keyword or syntax like in
the 2nd example and reference it through the '.' (or some other method).

Now the point is though that you can encapsulate the fields of the function
if you want such as

function void A()
{
int private static_instance i = 0; (completely hidden to anything
outside A)
printf("%d\n", i);
++i;
}

function void A()
{
int friends static_instance i = 0; (only visible to friends and uses
A().i to reference)
printf("%d\n", i);
++i;
}

etc...

I suppose some of these methods would break re entrance though and cause
major problems.. I'm not sure if thats acceptable or not.



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.


If I understand what you mean then its only because the syntax you are using
to define the concept I am talking about? You are allowing for the
implementation of the function to be outside its declaration. Here I am not.

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.


I'm not quite sure. It does support seperate compilation but it uses
assemblies and stuff so I'm not quite sure of the internals.


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

Yes, but one can declare i private and hence not allow foo.i. The reason is
that there might be a case where i needs to change for some reason.. but
rarely this will happen. When it does then you need some way to get at i to
influence the behavior of foo. You could pass i as a parameter every time
but I see this as a waste. I think this idea might be called polymorphic
functions. Functions that have "states". These states can be manipulated to
control the functions behavior. This is no different from a standard
function in that we can do the same thing. Its all about syntax and
conceptualization. If we put those "states" outside the function then they
are not really part of the function conceptually but if we don't allow
access to them then we don't really have states(atleast states that can
allow polymorphism).


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


yes, this is basically what I'm talking about. But a here the functor should
be defined as a very special class... a class with only one method... since
its special we can reduce the overhead of defining it. I see no need to
define something like above when its very easy for the compiler to recognize
that the following is equivalent(except more convient).

void function A(const char *name)
{
public int i = 0;

printf("%s: %d\n", name, i);
++i;
}

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

(would print "a:0", "b:1", "0")

Notice that you are using the struct A as a class while I'm using it as a
function. A function only has one "instantiation". So you would have to
declare your class as static. i.e, when any compiler instantiates a
function/method now days there is only one place in memory where it goes.
Theres no reason to have duplicate code when you know that through the whole
run-time the function will not change. Since we add data we might want this
ability(or use pointers to the fields so we can just have one code block
instantiated and not waste memory) but I was thinking of the fields to the
functions as being static. They represent the state of the function.

One could simply do the following for an equivalent code above:

void A(const char *name, int i = 0)
{

printf("%s: %d\n", name, i);
++i;
}

int main()
{
A("a",0);
A("b",0);
A(?) = 1; // how to set state of i in A?
printf("%d\n", A().i); // how to retrieve state of i in A?
return 0;
}

We would have to remeber the state ourself. Its obvious what it is in this
code though. We also have to pass the state(in most cases) every time we use
A.

The difference between my idea of a function and a static class is 99%
notation(as far as I can see). A function is a very simple static class that
behaves just like a function. i.e., instead of object.method() do call the
method you just have to do object() (and the compiler knows we are refering
to method() because theres only one). Also because its "static" its really
not an object(not sure what to call it) so we don't have to create it.

Anyways, I hope that clears up some things.

Thanks,
Jon




.

Relevant Pages

  • Re: fields for methods?
    ... but only by a compiler that is allowed to ... struct A {void foo();}; ... int static_instance i = 0; ... Is not possible because foo is the only member of A... ...
    (comp.programming)
  • Re: C Programming
    ... > reason for why it matters. ... There are books around that carefully do not teach bad practice, ... this book doesn't use void main. ... is int mainor int main. ...
    (Fedora)
  • Re: Virtual Machine implementation problem, Please help me to spot the bug
    ... This is non-standard (Conceivably your compiler allows it ... tmp1 might not be correctly aligned for u32. ... void change_endian{ ... typedef unsigned int u32; ...
    (comp.lang.c)
  • Re: C Questions
    ... No prototype is given for this function, so the compiler cannot ... To prototype a function with no parameters, use void: ... %d takes an int argument, ...
    (comp.lang.c)
  • Re: The_Sage & void main()
    ... shall have a return type of type int but otherwise in all other respects ... > main may have the return type void then main may indeed have the ... If the compiler accepts void main, then you may use void main ... about whether void mainis conforming or not. ...
    (comp.lang.cpp)