On Thursday, January 24, 2013 15:45:42 Nick Sabalausky wrote: > On Thu, 24 Jan 2013 12:51:32 -0500 > Andrei Alexandrescu <[email protected]> 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
