private int foo; public int Foo { get { return foo; } set { foo = value; } }
int x = Foo; Foo = x+1;
So what you're saying is that you'd like automatic overloading of access methods in objects, and write these functions in sub-scopes near the variable itself?
It's not a bad idea, I think. It could make it easier to write OO code, without having to resort to "getFoo or setFoo".
You can do this in Pike today, with `-> and `->=, but there isn't any sugar around it, and you can only do it if you handle all the indices of the object yourself...
Since I like sugar, I like your idea...
/ Mirar
Previous text:
2003-12-20 10:24: Subject: C#-like properties
While working on my master thesis, I have once again discovered the many similarities between C# and Pike. With the C# spec 2.0, C# will become even more Pike-like and for example introduce lambda expressions.
At present, there is one thing in C# which I would very much like to see in Pike.
C# has a concept called property. It's a mix of a variable and methods to get and set that variable.
It is considered good OO-practise to hide variables and use methods to access them but this causes a lot of polution within the namespace of a class with a log of variables if each one must have a getFoo() and a setFoo() method. Here is how to do it the C# way:
private int foo; public int Foo { get { return foo; } set { foo = value; } }
To access the Foo property, one just uses it just like a normal variable:
int x = Foo; Foo = x+1;
C# appears to implement this by turning the property into two methods, which in the example above would be called get_Foo() and set_Foo(). These methods cannot be called directly by the code, attempts to do so causes a compilation error.
In my sample, there is not much use in having a property, since no processing of the value is done, but in real life situations, there are many times I found that I may want to limit the value set by the caller to a certain range or similar. This is easily done with properties in C#.
Ofcourse, the problem can be solved by implementing the get and set methods manually, as one does today, but I believe that the C# way is much better looking and, at least to me, feels more natural.
My suggestion is that we put implementation of a C#-like property concept on the TODO-list. Thoughts, other ideas?
/ Marcus Agehall (Scanian)