On Tuesday, 29 January 2013 at 13:51:05 UTC, Chad Joan wrote:
On 01/29/2013 06:26 AM, eles wrote:
On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
to the one used for functions. That way, you can avoid
verbosity and
the need to use implicit parameters
IIRC, C# goes like this:
YRC.
property int foo
{
get
{
return m_foo;
}
set
{
m_foo = value;
}
}
C# properties have a couple disadvantages:
- They introduce an extra nesting level.
- There is a possible nonsense error if someone places code
outside of the get/set but inside the property scope.
The compiler will scream at you. This is why it analyses the
code, to make sure it understands it.
- You don't get to determine how the setter value is passed.
ref? auto ref? const?
Frankly? Why you would care? You only write a.x=b. How it is b
passed? It is the job of the compiler to pass b, not yours.
- They use 4 keywords, whereas we can get away with 2 probably.
Yes. This is why brainfuck become no.1 language ever invented,
because it uses very few keywords. And this is why Java never
really took off, just because it introduces new keywords like
extends and implements instead of our lovely :. Lovo of keywords
changed the world...
- Things get uglier when you add D's function pure and const
annotations to it.
*Everything* become uglier with that. Everything.
Semantically, they accomplish the same thing as D's properties:
they get lowered into two methods, one getter and one setter.
There has to be /some/ way to attach executable code to a
symbol for this properties concept to work at all.
If they are the same, why they are different to the point that
you love one but hate the other?
