@property - take it behind the woodshed and shoot it?

[Jonathan M Davis]

On Thursday, January 24, 2013 15:45:42 Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 12:51:32 -0500
> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> > No. The complications come from the fact that (a) nobody could agree
> > what should be a @property and what shouldn't;
> 
> No, you merely came up with *some* specific cherry-picked examples that
> sparked *some* debate (with most of the disagreing coming from
> you).
> 
> Stop mischaracterizing what really happened:
> 
> It's well known that you never liked or fully understood the idea of
> properties in the first place, even by your own admission. So you made a
> post some number of months back attempting to drum up dissent for
> properties by stirring up the notion, which just about only you
> believed, that the choice between property and function is inherently
> unclear.
> 
> So to "prove" this you cherry-picked some grey area cases (gee,
> occasional grey judgement calls when mapping ideas into code,
> yea, there's something that doesn't happen without @property). You
> succeeded ONLY in proving that there exist *some* cases which may be
> grey-area judgement calls (again, big surprise, occasional grey-area
> judgement calls when writing code). But then you - and ONLY you - took
> this proof that "*some* cases exist" and declared "Look, look, everyone!
> I proved that *nobody* can agree on property vs function *in general*!
> QED!"
> 
> And you continue declaring that non-sequitur to this day.

I've never understood what's so hard about knowing what should and shouldn't 
be considered a property. It's generally very clear IMHO, and if clarification 
is needed, C# has some excellent guidelines for it, as a number of people keep 
pointing out. Really, it comes down primarily to whether a function would make 
sense as a variable.

> > (b) @property adds
> > noise for everybody for the sake of a corner case (functions
> > returning delegates);
> 
> The only reason functions returning delegates have *ever* been an
> any issue at all is *purely* because of the insistence on
> optional parens on arbitrary function calls.

Indeed.

> > (c) the @property discipline failed to align
> > itself in any way with better code quality.
> 
> Ok, now *that* argument is just pure unadulterated bullshit. In
> languages like C# that have *real* and *completed* property support,
> yes, the general consensus IS that they DO definitely help. Please take
> your blinders off, and you'll see that.
> 
> But then there's D, which adds a half-baked and
> incompletely-implemented "properties" - and did so *reluctantly* I
> should add. Leaves it in that broken state untouched for a year or two.
> And now here you are effectively saying "This
> half-designed/half-implemented feature is causing dissent and not
> helping people, therefore the problem must be the whole idea of
> properties and couldn't possibly be due to our broken version of
> them" (for the record - I *do* find D's current properties helpful,
> just not as helpful as they would be if they weren't broken).

I think that you're being too extreme in your language and tone here, but I 
have to agree.

- Jonathan M Davis