"Nick Sabalausky" <a...@a.a> wrote in message news:h4c202$283...@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.