Properties

[Robert Jacques]

On Fri, 24 Jul 2009 17:12:39 -0400, Nick Sabalausky <a at a.a> wrote:

> "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?

Your syntax seems very C# inspired. After doing a class project in C# a  
while ago, which heavily used properties, I breathed a major sigh of  
relief coming back to D properties. If I had to pick something concrete,  
I'd say the lack of clean one-liners is an issue as is the extra  
indentation.

I'd also note I almost never do the private var, public method pattern.  
(Really, only when I want a expose a read-only view of something) Most of  
the time I'm doing some kind of transform and storing the data in a  
seperate internal format.

>> * 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; }
> -----------------------------

Hmm... Here's some random ideas

int width = 7         /// Property with storage
out                   { return width;           }
in(int   i)           { width = i;              }
inout(alias op)(int i){ return width op i;      }

auto high_five        /// Property with no storage
out(float)     { return 5.99; }

>> * +=, -=, 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.

Well, actually "func(class, value) <=> class.func(value)" is extremely  
valuable for extending third party structs/classes. It's also very much  
about programmer style. Some people prefer/understand one better than the  
other. It can also help make porting/refactoring go smoother. I've also  
used "class.func = value" several times even when according to the style  
of the library I shouldn't; In each case, it increased the readability and  
understandability of my code as a whole, despite "class.func = value" not  
making much sense in isolation.

Anyways, enforcing style for style's sake is always bondage and discipline  
programming. I mean, people have issues with restrictions even when they  
buy safety and robustness.

BTW, I think you meant "2 + 2" vs "2 ~ 2" to do concatenation. And if you  
really meant addition, then well that's just bad function name choice.  
It's got nothing to do with style.

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

Curiosity, how would a debugger set a watch on a property since it doesn't  
acually exist?