Properties

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:h4c202$283l$1 at digitalmars.com...
> Now that I've finally gotten my ng client to play nice and actually show 
> me
> my own DIP4 thread (unsubscribed digitalmars.D and then re-subscribed), 
> I'm
> moving the comment that was left on the Wiki over here:
>
> ------------------------------------
>
> RobertJacques says:
>
> Cons:
>

Ok, now I finally have a moment to respond to at least one set of comments:

> * Verbosity is an issue (i.e. the addition of extra boiler-plate code)
>

I'm not sure I see how the proposed syntax is verbose. And I specifically 
designed it to minimize boilerplate. With the current style, you have to 
(typically) define a private variable, and then one or two functions for 
getting/setting. This proposal isn't really much more than that even in the 
worst case. Maybe you could elaborate on what you mean?

> * keyword increase: both set and get become keywords. Perhaps re-using in
> and out in a manner similar to contract programming might work.
>

I indicated in the proposal that they would not be keywords. Someone 
indicated in the "Reddit: Why aren't people using D?" thread that that would 
be possible. Maybe they could explain here?

I suppose it might be required to make "value" and "set" keywords because of 
their use as implicit variables, but I'm not convinced. Maybe a language 
expert could shed some light on this?

Also, regarding in/out contracts, something like this was one of my earlier 
ideas, but I decided against it because I wasn't sure if it would cause 
parsing problems, and I wanted to leave the door open for (I forget who's) 
suggestion of allowing operator overloading for a property if that ended up 
being deemed necissary. But, I may as well stick it on the table here for 
open discussion:

-----------------------------
// Viable? Preferable?
int width = 7
get { return value; }
set { value = set; }
-----------------------------

> * +=, -=, etc. : The suggested syntactic sugar is good, but could be
> implemented with current properties. Separate?
>

Perhaps. What does everyone else think?

> * bondage and discipline: Different programmers have different coding
> styles. Hence the suggested syntactic sugar of func(class, value) <=>
> class.func(value) <=> class.func = value in other proposals and currently
> valid for arrays. Flexibility is a virtue
>

I'm sorry, but I have to strongly disagree with this one. Saying that 
"class.func(value) <=> class.func = value" is a matter of style is like 
saying that "2 + 2" vs "2 ~ 2" to do addition is a matter of style. (And I 
question the "func(class, value) <=> class.func(value)" part as well, albiet 
not quite as strongly) Within a language, each syntax and operator has it's 
own meaning. Allowing them to be switched around interchangably serves no 
purpose besides obfuscation.

> * IDE's, and doc-generators: Could all be well served with a appropriate 
> set
> of DDoc tags

In the case of doc-generators, yes, that could be done and would not be 
unreasonable. However, any information that a doc-generator can get directly 
from the code instead of an additional doc-generator-specific syntax (let's 
not forget, that would add extra verbosity/boilerplate!) can only be an 
improvement.

In the case of debuggers, it's probably possible, but it's a bad idea. A 
debugging feature should not be dependant on any specific doc-generator. 
DDoc may be built into DMD, but it is expected that any standard doc 
generator can be used instead. The only way for a debugger to get around 
that is to try to support every doc-generator that someone might want to use 
(and just for the sake of properties alone?), which may be possible, but not 
the right approach.