On Fri, 24 Jul 2009 17:12:39 -0400, Nick Sabalausky <[email protected]> wrote:
"Nick Sabalausky" <[email protected]> wrote in message
news:[email protected]...
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?
