>________________________________
>From: Steve Schveighoffer <schveiguy at yahoo.com>

>

>I need to file another enhancement request...


done: http://d.puremagic.com/issues/show_bug.cgi?id=5893

-Steve

On Tue, 26 Apr 2011 09:20:33 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> I'm consolidating responses here...
> ----- Original Message -----
>> From: Robert Jacques <sandford at jhu.edu>
>
>> On Mon, 25 Apr 2011 09:47:32 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>>>  It's impossible to improve the design when the compiler doesn't let
>> you enforce your design!
>>>
>>>  And no, the user is not always right.  That's why we have the compiler
>> to tell them so ;)
>>
>> Having D enforce your design, can not _ever_ improve a design. Every
>> single time
>> DMD rapts the user's knuckles enforcing your design, it is an instance
>> where
>> your design failed. It is a safety net. Nothing more.
>
> Incorrect.  DMD enforces you use the names the author designed, with the capitalization the author designed.  If you do not, it doesn't compile. It is no different with parentheses, which are part of the name.

Ahem. If they are no different, then could you please name a word that has parenthesis as part of it? No?

Even capitalization is limited to a very limited set of by convention rules, beCause wE caN't reMemBer hOw To tYpe namEs liKe thiS.

>> Have a safety net is important, but the more it extends out beyond the
>> concrete
>> of invalid and meaningless code, the more it encourages mediocre
>> design. And any
>> fall into the safety net still hurts.
>
> It hurts when you're not allowed to write confusing code?  That sounds like a pretty good design to me :)

The only time a corder writes confusing code is when your API confuses them. So not allowing 'confusing' code means the API doesn't have to be clear and meaningful, which is what I meant encouraging mediocre design.

And given that a coder doesn't ever try to write code that's confusing to them, whether or not it's confusing to you is a moot point, _unless_ at the same time the confusing way is a) invalid or meaningless and b) looks more valid than the non-confusing way.

>>>  What I meant was, the technicality that the function could be pure,
>>> and
>> that would remove the possibility of using it the "wrong way" does not
>> invalidate the property problem.  In fact, it does not necessarily
>> invalidate
>> the example, since it is D1 we are talking about here (Tango).
>>
>> I don't think in terms of a single property problem (I don't even know
>> what you mean by that). I think in terms of many small problems of
>> varying
>> severity. (And this solves the vast majority of the high severity
>> issues) And
>> any solution to the 'property problem' would be D2/D3 only, so I
>> don't know why you're mentioning D1.
>
> I'm referring to the ability to call any method with the right arguments as properties.  This exists in D1 and currently in D2 (to be deprecated).
>
>
>>>  But in any case, this is diverging into the obscure.  I don't think
>> rules that try to guess what the author is intending are as good as
>> annotations
>> which tell the compiler what the author is intending.
>>
>> Of course not, but there's a reason that most cars are automatics:
>> there is
>> a non-negligible cost to using a heavy annotation based system. The
>> question
>> isn't so much as is one 'better' or not, but is it good enough most
>> of the time?
>
> Most of the time isn't good enough.  Is it ok if the compiler's code generation works "most of the time"?  If the compiler allows me to get the design I want most of the time, and other times it's impossible, that is a half-ass flawed design, and it's actually worse than not having @property at all.

You are aware that the counter argument is to regurgitate this argument back to you with a name change? that aside, design is almost always about compromise (though sometimes you get synthesis). And to find a good compromise you must explore the solution space. That a particular solution might be worse than any of it neighbors may occur (and I thank you for pointing out the flaws in this one), but that doesn't mean we shouldn't look.

>> There are problems with using @property alone. There are problem with
>> using
>> Methods-as-Fields alone. This would indicate that some compromise is
>> needed, and
>> therefore every point of the synthesis/trade-off curve is valuable. (Or
>> alternatively that we need to scrape both and start a fresh)
>
> But the problem with enforcing @property is just that you don't want to
> name
>  your functions differently from the properties.  It's not that the
> functionality cannot be had.  Essentially, it's a bikeshed problem, not a
>  real problem.

Okay, first, I'm not sure you meant to imply this, but there are a host of other issues with enforcing @property, beyond the one we're discussing now, or even then ones mentioned in these threads.

Second, a large part of any design is nomenclature; bikesheds only occur when you've got a couple of reasonable, relatively equal solutions and multiple cooks/designers.

Third, 'not a real problem'? A) if we didn't think it was a 'real problem' we would not be discussing it. B) Please excuses the crassness, but that sounds suspiciously like 'my shit doesn't stink'

Forth, since you have asserted many times that parenthesis are part of the name, then isn't the problem with not-enforcing @property just that you don't want to name your functions clearly. It's not that the functionality cannot be had. Essentially, it's a bikeshed problem, not a real problem.

>>>  For you to reject my rebuttal of your obviously abstract example by
>>> saying
>> my rebuttal is too abstract is also fallacious.
>>
>> *sigh* The original argument was "Here is an API design, A, that you
>> can't express elegantly with @property alone". Your rebuttal was
>> "Well, your abstracted example is obviously of Poor Design (TM), you
>> should
>> use B instead. Therefore, this 'issue' with @property, isn't really
>> an issue". Your rebuttal introduced a new argument (that A was bad
>> design,
>> so use B instead) and I was pointing out the flaws in you making that
>> argument
>> based on abstracted information. The original argument was never about
>> the
>> 'goodness' of A, it was about the ability to express A in the first
>> place; the biggest flaw in your argument is that the ability to express
>> 'poor' design should warrant the removal of the ability to express it.
>
> *double sigh* So essentially, you put forth an argument showing how you are correct using abstract data, and you reject my rebuttal that uses the same abstract data because... it's abstract?  Give me a break!  Is your argument impervious to attack then, because it's abstract?

*sigh* (Now would that be a triple sigh, a quadruple sigh or a double double sigh?) Anyways, no it's not impervious to attack. The discussion began as a discussion of _existence_ of issues with strict- at property. You counter-argued against the _importance_ of the issue. Now the _importance_ of an issue is a valuable discussion, but responding with an _importance_ argument to an _existence_ discussion without making a clear change of topic, is bad form.

> In all concrete examples that exist, if this compiles:
>
> a = b.x = c;
>
> Where x is a property name, I would expect a == c.  Any reasonable programmer would.
>
> Look, the problem is not about what you are thinking when you write it, it's what you are thinking when you read it.  Essentially, your design promotes confusing/unreviewable code, i.e. it's design could be improved.

A coder doesn't naturally try to write confusing/unreviewable code. And what you're thinking when you read it, is very similar to what you're thinking when you write it. Besides, greater expression capabilities allow you to express high level constructs better, which promotes clear, reviewable code.

>>>  No they don't.  This is a common argument against larger APIs.  I know
>> many many APIs where I don't *know* the whole API, I just know what I
>> need
>> to get my work done, and lookup anything else.  If you want to use the
>> setX
>> version all the time, there is no need to learn the property
>> functions.  In
>> fact, there is no more learning required for the setX version and the
>> dual
>> property/function version -- both have the same number of API calls.
>>>
>>>  Bottom line, increasing the number of documented calls does not make
>>> it
>> harder to learn one of those calls.
>>
>> I'm not arguing for or against larger APIs. My issue is with inefficient
>> APIs. With dual property/function I can store a single entity in my
>> mind (or in
>> the docs) and then apply language rules to get 2 API calls. In the
>> alternative,
>> I have to store 3 entities, the two names and their relationship to
>> each other,
>> to get 2 API calls.
>
> No you don't.  You only have to store the relationship "if I want to use
>  this as a property, use x.  If I want to use it using fluent
> programming, use setX()", then you just have to remember the names for
> the properties.  It's no different than the relationship "If I want to
> use this as a property, use x.  If I want to use it using fluent
> programming use x()".  You actually will not notice a difference, I
> guarantee your brain will not run out of space because of this :)
>
> The docs can state the same relationship in one spot, or just use ///ditto to group both the property and the setter together.

Did you notice that you used two sentences in each example to explain it to me? With Method-as-Fields I only need to use one.

>>
>>>>  3) If setProp actually read better in real life, we'd use it. But
>> it
>>>>  doesn't, so we aren't. By the way, I would hazard that
>> setX/getX are one
>>>>  of the most famous/infamous pieces of API design out there and that
>> everyone
>>>>  can/does consider it.
>>>
>>>  Your opinion.  I have used it, and have had no complaints.
>>
>> I'm not sure what you're implying/responding to here.
>
> I was responding to "If setProp actually read better in real life, we'd use it.  But it doesn't, so we aren't."  Sorry, did you think that was a fact and not an opinion?

No, I thought you were dismissing my opinion as not valid because it differed from yours. (I may have misunderstood, but you were very terse)

>> My response was
>> was that I (and almost everyone else) has used setX/getX at some point
>> and
>> always considers whether its the best choice for job (or not) and that
>> implying
>> that we didn't consider it during API design seems a bit condescending,
>> nor
>> is it really helpful to the discussion.
>
> I do not know your reasons for your design.  All I can guess is that you
>  did not consider the possibilities for abuse, or the confusion of the
> reviewer, or thought they were not important, and thought "hey, I can do
> two things with one function!
> neat!"  It's a classic folly of software developers not considering the
> usability of what they are writing.  It is why you have people who
> aren't software engineers design or review UIs.

Yeah, I'm well aware of what happens when you let software engineers design your UIs. But your condescending tone isn't helpful to a level headed discussion and seems to speak to a general close-mindedness, which is also not helpful.

>>>>>   Without strict properties, the author of the code cannot enforce
>> usage
>>>>  semantics, and therefore, will lead to ambiguities.  The only
>>>> exception
>> I can
>>>>  see is calling a function with no arguments which returns void
>>>> without
>> the
>>>>  parentheses.  It cannot be mistaken for a property getter, because it
>> can't
>>>>  be used as a getter.
>>>>
>>>>  Could you please present an example of an ambiguity in the general
>> case? (i.e.
>>>>  excluding assignment to const/immutable/(static pure) functions and
>>>> the
>>>>  delegate() foo(){})
>>>
>>>  I mean semantic ambiguity, not compiler ambiguity.  I mean, the
>>> choice of
>> how the symbol can be used makes the symbol name ambiguous where it
>> wouldn't
>> be if the usage was locked to one way or the other.
>>
>> Sorry, I was implying examples of semantic ambiguity with my request.
>
> OK, when you referred to the delegate thing, I thought you meant functional ambiguity.
>
> Any term which could be confused as an action or a property.  For instance backup.  backup can be a noun ("do you have the backup?"), or it could be a verb ("did you backup the system?")
>
> So if I have a backup function, and you use it as a property, what happens:
>
>
> auto x = y.backup;
>
> Is x now a backup copy of y, or is it a return value from some backup process?  Contrast that with the function style:
>
> auto x = y.backup();
>
> it definitely reads more like backup is doing something on y (like backing it up) and x is some sort of status.

Well, since my experience with C taught be that status codes are evil, I'd never guess that. :) Anyways, since I'd never write y.backup() regardless, I can honestly say that I don't really see the difference anymore. Besides, the context and descriptive names for x and y are going to be an order of magnitude more important to clarity of meaning. i.e. status = db.backup; v.s. old_db = db.backup;

>>>>  TimeSpan.seconds(5); // looks ok to me, not great, but not misleading
>> either.It looks like a constructor, which it actually is.
>>
>> This looks unnatural to me, both as a reviewer and as a coder. The
>> reviewer
>> sorts the meaning quickly enough, after a little inference. But a coder
>> will not
>> naturally write this the first time, assuming they haven't read the
>> manual
>> recently.
>
> As a constructor it looks unnatural?  How would you expect a constructor to look?

Capitalized, because types are capitalized and those are used to call the ctors.

>>
>>>>  TimeSpan.seconds = 5; // absolutely misleading.
>>
>> And _looks_ absolutely natural ( therefore is absolutely misleading to
>> both
>> coder and reviewer :) ). By the way, a 'bug' like this is a good
>> indication that the user wants a way to set a TimeSpan's span(?)
>> outside of
>> the factory methods (i.e. an additional API feature).
>
> The problem is, I can only "solve" this bug by changing the name of seconds to be more explicit, I can't disallow this code.

And so long as the code is meaningful, why is disallow code inherently good?

>>>>  So I think even though it's somewhat of a combination of issues,
>> the
>>>>  property issue is not invalid.
>>>>
>>>>  The issue is more prevalent when talking about ambiguous words,
>> especially ones
>>>>  that can be both nouns/adjectives and verbs.  The issue I have with
>>>> not
>> being
>>>>  able to require parentheses is, lack of parentheses evoke an
>> expectation of a
>>>>  field, either setting or getting that field.  Parentheses evoke more
>>>> of
>> an
>>>>  action than a field, but that's not as strong, because you can
>> easily make a
>>>>  function that is a property.
>>
>> Yes, parentheses evoke actions more that data, and I would expect the
>> average
>> coder to use them in a natural (for them) way. Generally, coders do not
>> try to
>> make their code unnatural, except in sport. And differences in 'natural'
>> coding styles (i.e. ambiguities) are perfectly expected. To combat this
>> (among
>> other things), the designer writes documentation. Therefore confusion
>> and misuse
>> should only occur if the user a) hasn't fully read the docs or b) it has
>> been some time since they did read the docs, and they've forgotten
>> pertinent
>> information. And if a user has forgotten what 'seconds' does,
>> they've probably also forgotten whether it's const, or immutable, or
>> pure or @property. Mandating parentheses doesn't help the user remember
>> how
>> to call/use a function, because we Humans remember names extremely well,
>> purpose/behavior decently well and arbitrary tags poorly.
>
> Again, the enforcement is for the reader of the code, not the writer.If you had no idea what TimeSpan.seconds(5) does, you would probably know what it means if you saw:
>
> auto timeout = TimeSpan.seconds(5);
>
> It's self-documenting.

But since this is the only correct way to use this function, by the time it gets to the reviewer shouldn't already be in this form?

>>
>>>>  If you just require @properties to be called without parentheses, it
>> doesn't
>>>>  solve the largest problem with D's property system -- that is,
>> being able to
>>>>  omit parentheses for things that should clearly be viewed as actions.
>>
>> :) If it's clearly an action, then shouldn't it have a nice actiony
>> name? :)
>
> constructors usually don't have actiony names, they are named after the type they are constructing.  Factory methods are sort of a hybrid between actions and constructors, so I think it's ok to have nouns as factory method names.  But this is part of the design decision I should be able to make.  It should not be enforced on me to change the name because the language allows someone to misuse the library.

Well, if you want to use ctor like names, then you should use a capital, otherwise it isn't a ctor like name, it's a field like name.

>>
>>>>  Here is an artificial, but not so improbable example:
>>>>
>>>>  stream.read = buf;
>>>>
>>>>  what does this mean?  Does it mean, set the read buffer to buf?  Does
>> it mean
>>>>  read buf into the stream?  I have no idea.
>>
>> Really? I know it supposed to be a synthetic example, but read's a
>> verb. It
>> does stuff. If it was the read buffer, it would be named readBuffer; a
>> noun.
>
> read (pronounced like 'red') is also an adjective, which can be a property:
>
> book.read = true;
>
> But even readBuffer could be an action (read the buffer) or a noun  (the read buffer) :)
>
>>>>  But this is completely clear:
>>>>
>>>>  stream.read(buf);
>>>>
>>>>  it means, read the stream data into buf.
>>>>
>>>>  However, D treats them both equivalently, and throws no error on the
>>>>  super-confusing usage.
>>
>> You are aware that the 'stream.read = buf;' is logically correct? And that for whoever that wrote it that way, it had to be natural and non-confusing.
>
> I wouldn't be so sure.  If I wrote that, thinking I was clever, and then went back to read it, I'd have to look stuff up again.  And then when I figured it out, I'd change it to the other style.

But how often do you write something just to be clever? In production code?

> But in any case, it's the reader that I'm concerned about, not the writer.  The strict enforcement of properties helps the writer create maintainable code.  If you want to use a language that helps you write unmaintainable code, there's always perl :)

I would've thought that a code reviewer wouldn't want strict @property. That way the company can select their own, consistent style guide which everything is written in and reviewed in. Otherwise, every third party library embedded a different meaning into () and no-(), which makes code less maintainable, I would think.

>>>>  I understand that *most* people won't use it that
>>>>  way, but as a library designer, I want to patch all the holes, and
>>>> make
>> the API
>>>>  as tight as possible.
>>
>> But a hole isn't _always_ generated by 'unapproved' syntactic usage. A hole only occurs when the syntactic usage causes the code to become meaningless or invalid; and we can patch most (all?) of those.
>
> The translation of the code into binary form is not what's at stake here, it's the human interpretation of it.  A good design takes both into account.
>
>>
>>>>  I want code that uses the library to read as naturally as
>>>>  possible.  So I might rename the function "readTo" to ensure
>> the verb
>>>>  status of "read."  To me, this is a sucky compromise that
>> feels
>>>>  artificially created by the compiler.
>>
>> Improving the clarity of your library is a 'sucky compromise'?
>
> If the library does not allow:
>
> read = buffer;
>
> then read is clear enough, because read(buffer) is clear.
>
> The point is, the loose properties are forcing me to make something
> that's already clear in one context less clear in another context to
> discourage usage.  I
> want to make the user only call read using parentheses, I'd rather just
> have the compiler make them do it, not have to "hint" at it using a more
>  verbose term.

But if the meaning is clear is one context and not in the other, wouldn't a reasonable coder never use the un-clear one?

OK, I might be too late for the party, but if anyone can check my fixes for std.regex (Pull #22) in 64-bit build I would be grateful. It solves a bulk of problems people had had with it for something like 3 years now...

-- 
Dmitry Olshansky

Guys, you really hijacked this thread!

But since you have...
As an outsider to the property discussion, I feel that the key points
are lost under a sea of quite spurious stuff.
Here are the strong arguments as I see them:

1. The rationale for including @property with tight semantics is
strong (mainly coming from
disallowing property syntax on things which aren't properties). The
rationale is doubtful
with loose semantics that only disallows function syntax on properties.
2. Tight semantics prevent the use of the "fluent programming" idiom which is
reasonably widely-used.
3. If we go with tight semantics, we break existing code. If we don't,
we break TDPL.

I'm seeing a fair bit of argument AGAINST tight semantics.
But I'm seeing pretty much no argument FOR loose semantics.
I'm not seeing any reason to choose loose semantics over D1 semantics.

----- Original Message -----

> From: Don Clugston <dclugston at googlemail.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Cc:
> Sent: Wednesday, April 27, 2011 7:13 AM
> Subject: Re: [phobos] Time to get ready for the next release
> 
>G uys, you really hijacked this thread!

Sorry about that.? It's one of those things where, you don't want to leave arguments un-countered :)

I've decided to stop arguing, I'm pretty confident that things will be implemented as they are described in TDPL.

> 2. Tight semantics prevent the use of the "fluent programming" idiom
> which is
> reasonably widely-used.

This is not true.? There is nothing in fluent programming that says the functions one defines for fluent calls must also be properties.

For example, with tight semantics, one can define a property int x, and then a method typeof(this) setX, whereby the second method can be used in fluent programming.? In fact, I've used this exact design in Tango's sys.Process.

What is not supported is using the property name to do fluent programming, however, this requires the property setter to return this, which IMO is not a design we need to cater to.? If a setter returns anything, it should return the value set (for assignment chaining, e.g. x.prop1 = x.prop2 = 5).

> 3. If we go with tight semantics, we break existing code. If we don't, we break TDPL.

tight semantics is guaranteed to break existing code, because it restricts what was previously not restricted.? This is no argument to not implement it.

Now, it does break existing *designs*, but those designs can be had with minor changes to the code (see my above comment).? However, expect some backlash, because people don't like to change things that work for them.

> I'm seeing a fair bit of argument AGAINST tight semantics.
> But I'm seeing pretty much no argument FOR loose semantics.
> I'm not seeing any reason to choose loose semantics over D1 semantics.

Given that those arguing against tight semantics likely don't use @property, I think they are not really concerned with the semantics of @property functions, they only care about non- at property functions.? Likely, they would not care whether @property stays or goes, just as long as it doesn't affect how they call non- at property fucntions.? Correct me if I'm wrong, guys.

-Steve

On Wed, Apr 27, 2011 at 9:54 AM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

>
> Given that those arguing against tight semantics likely don't use @property, I think they are not really concerned with the semantics of @property functions, they only care about non- at property functions. Likely, they would not care whether @property stays or goes, just as long as it doesn't affect how they call non- at property fucntions.  Correct me if I'm wrong, guys.
>
>
Right.  I think @property solves a somewhat important problem by disambiguating the case of returning delegates, etc.  Whether solving this problem is worth the complexity it adds to the language is something I'm neutral on.  Basically, I really don't care what happens with @property as long as designs that rely on non- at property functions behaving as they do currently don't break.

I wouldn't care if we were only talking about breaking code in trivial ways, but we're talking, as you mention, about breaking existing *designs*, and designs I happen to like.  I understand you don't like them, but that's not the point.  The point is that we're talking about very non-trivial breakage of existing code, and @property could solve the main problem it was meant to solve without doing so by having loose semantics.  This is what really ticks me off about @property with strict semantics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110427/e7344ed0/attachment.html>

I don't want to keep arguing this, but I feel compelled to keep re-iterating:

The delegate return problem is nice to solve but is *NOT* the main thing that @property solves.? One can already call the delegate using a double set of parentheses, and it's not common to have a property that returns a delegate.

The main problem solved is that one cannot simply use property syntax where it was not intended.? This is the piece that is not yet implemented.

I understand it breaks your design.? But I've already said my opinion on why this is worth breaking those designs.? We differ in opinion, and I can't really say one way is 100% right, it's a compromise.

I would point out that if D adopted strict properties before you learned it, you probably would have? simply gravitated towards a different method of achieving the same design.? I don't have any proof that this is the case, except to look at other languages with strict properties that have achieved your designs without issue (just with slightly different semantics).

--------

I also thought of this last night, not sure if it is something you could live with.? But one way to allow fluent programming without explicitly having to enable it is to have a wrapper type that enables the fluent interface.

If we assume propN symbols are @property functions:


// before

mytype.prop1(1).prop2(2);

// after
fluent(mytype).prop1(1).prop2(2);

Essentially, the fluent template would create a wrapper that intercepts calls to @property functions and does something like:

typeof(this) prop1(int x)
{

?? wrapped.prop1 = x;
?? return this;
}

It would actually work on plain fields as well ;)


I've tried to write a wrapper type that did something like this, but I ran into some bugs with opDispatch.? I ended up making a wrapper type that wasn't as universal  (see dcollections' trackLength function).

However, with those bugs fixed, one then has the power to create a design that enforces proper property usage, and also is able to use the fluent method without having to define extra functions where one wants to use the fluent method.? This method at least informs the reader that you are overriding the default usage (via the fluent wrapper), and it is also DRY.


Does this sound reasonable?? I can agree with putting off strict properties until such a wrapper is implementable (I'd like to use this technique in dcollections anyways, see the trackLength function for my workaround-ish implementation of a similar wrapper).


-Steve


>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Wednesday, April 27, 2011 11:25 AM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>
>
>
>On Wed, Apr 27, 2011 at 9:54 AM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>
>>Given that those arguing against tight semantics likely don't use @property, I think they are not really concerned with the semantics of @property functions, they only care about non- at property functions.? Likely, they would not care whether @property stays or goes, just as long as it doesn't affect how they call non- at property fucntions.? Correct me if I'm wrong, guys.
>>
>>
>Right.? I think @property solves a somewhat important problem by disambiguating the case of returning delegates, etc.? Whether solving this problem is worth the complexity it adds to the language is something I'm neutral on.? Basically, I really don't care what happens with @property as long as designs that rely on non- at property functions behaving as they do currently don't break.?
>
>I wouldn't care if we were only talking about breaking code in trivial ways, but we're talking, as you mention, about breaking existing designs, and designs I happen to like.? I understand you don't like them, but that's not the point.? The point is that we're talking about very non-trivial breakage of existing code, and @property could solve the main problem it was meant to solve without doing so by having loose semantics.? This is what really ticks me off about @property with strict semantics.
>
>_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>

But such a proposal adds more complexity than is justified.

On Wed, Apr 27, 2011 at 12:00 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> I don't want to keep arguing this, but I feel compelled to keep re-iterating:
>
> The delegate return problem is nice to solve but is *NOT* the main thing that @property solves.  One can already call the delegate using a double set of parentheses, and it's not common to have a property that returns a delegate.
>
> The main problem solved is that one cannot simply use property syntax where it was not intended.  This is the piece that is not yet implemented.
>
> I understand it breaks your design.  But I've already said my opinion on why this is worth breaking those designs.  We differ in opinion, and I can't really say one way is 100% right, it's a compromise.
>
> I would point out that if D adopted strict properties before you learned it, you probably would have  simply gravitated towards a different method of achieving the same design.  I don't have any proof that this is the case, except to look at other languages with strict properties that have achieved your designs without issue (just with slightly different semantics).
>
> --------
>
> I also thought of this last night, not sure if it is something you could live with.  But one way to allow fluent programming without explicitly having to enable it is to have a wrapper type that enables the fluent interface.
>
> If we assume propN symbols are @property functions:
>
>
> // before
>
> mytype.prop1(1).prop2(2);
>
> // after
> fluent(mytype).prop1(1).prop2(2);
>
> Essentially, the fluent template would create a wrapper that intercepts calls to @property functions and does something like:
>
> typeof(this) prop1(int x)
> {
>
>    wrapped.prop1 = x;
>    return this;
> }
>
> It would actually work on plain fields as well ;)
>
>
> I've tried to write a wrapper type that did something like this, but I ran into some bugs with opDispatch.  I ended up making a wrapper type that wasn't as universal  (see dcollections' trackLength function).
>
> However, with those bugs fixed, one then has the power to create a design that enforces proper property usage, and also is able to use the fluent method without having to define extra functions where one wants to use the fluent method.  This method at least informs the reader that you are overriding the default usage (via the fluent wrapper), and it is also DRY.
>
>
> Does this sound reasonable?  I can agree with putting off strict properties until such a wrapper is implementable (I'd like to use this technique in dcollections anyways, see the trackLength function for my workaround-ish implementation of a similar wrapper).
>
>
> -Steve
>
>
> >________________________________
> >From: David Simcha <dsimcha at gmail.com>
> >To: Discuss the phobos library for D <phobos at puremagic.com>
> >Sent: Wednesday, April 27, 2011 11:25 AM
> >Subject: Re: [phobos] Time to get ready for the next release
> >
> >
> >
> >
> >
> >On Wed, Apr 27, 2011 at 9:54 AM, Steve Schveighoffer <schveiguy at yahoo.com>
> wrote:
> >
> >
> >>Given that those arguing against tight semantics likely don't use
> @property, I think they are not really concerned with the semantics of @property functions, they only care about non- at property functions. Likely, they would not care whether @property stays or goes, just as long as it doesn't affect how they call non- at property fucntions.  Correct me if I'm wrong, guys.
> >>
> >>
> >Right.  I think @property solves a somewhat important problem by
> disambiguating the case of returning delegates, etc.  Whether solving this problem is worth the complexity it adds to the language is something I'm neutral on.  Basically, I really don't care what happens with @property as long as designs that rely on non- at property functions behaving as they do currently don't break.
> >
> >I wouldn't care if we were only talking about breaking code in trivial
> ways, but we're talking, as you mention, about breaking existing designs, and designs I happen to like.  I understand you don't like them, but that's not the point.  The point is that we're talking about very non-trivial breakage of existing code, and @property could solve the main problem it was meant to solve without doing so by having loose semantics.  This is what really ticks me off about @property with strict semantics.
> >
> >_______________________________________________
> >phobos mailing list
> >phobos at puremagic.com
> >http://lists.puremagic.com/mailman/listinfo/phobos
> >
> >
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110427/497820a6/attachment-0001.html>

On Wed, Apr 27, 2011 at 12:00 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> I don't want to keep arguing this, but I feel compelled to keep re-iterating:
>
> The delegate return problem is nice to solve but is *NOT* the main thing that @property solves.  One can already call the delegate using a double set of parentheses, and it's not common to have a property that returns a delegate.
>
> The main problem solved is that one cannot simply use property syntax where it was not intended.  This is the piece that is not yet implemented.
>

Again, I just can't justify breaking existing designs for something that's such a non-issue in practice, except in a few straw-man cases where the function in question is poorly named.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110427/51235924/attachment.html>

>From your answer, it seems like a case where keeping the status quo is the only acceptable path for you.? I don't think I can get any closer to your desired API without eliminating strict properties, which is not acceptable to me.? Frankly this argument is starting to seem very trivial.


There is no sense in continuing debate.


We'll have to see what happens.

-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Wednesday, April 27, 2011 12:03 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>But such a proposal adds more complexity than is justified.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110427/7b4f4fb0/attachment.html>