Ok, then old operator overloading should stay in until these bugs are resolved.  Then, a mixin should be provided to make it trivial to fix old code and to automate dealing with the virtual function issue.

On Fri, Apr 22, 2011 at 4:43 PM, Steve Schveighoffer <schveiguy at yahoo.com>wrote:

> It doesn't work for me.  See:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=4174 http://d.puremagic.com/issues/show_bug.cgi?id=4182
>
> I should say, 4174 is due to using interfaces.
>
> -Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/d3fe0fee/attachment.html>

How do you automate 4182?? That is, how does the wrapper know that I want the result to be covariant in derived classes?


-Steve




>________________________________
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Friday, April 22, 2011 4:56 PM
>Subject: Re: [phobos] Time to get ready for the next release
>
>
>Ok, then old operator overloading should stay in until these bugs are resolved.? Then, a mixin should be provided to make it trivial to fix old code and to automate dealing with the virtual function issue.
>
>
>On Fri, Apr 22, 2011 at 4:43 PM, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>
>It doesn't work for me.? See:
>>
>>
>>http://d.puremagic.com/issues/show_bug.cgi?id=4174 http://d.puremagic.com/issues/show_bug.cgi?id=4182
>>
>>
>>I should say, 4174 is due to using interfaces.
>>
>>
>>-Steve
>>
>>
>
>_______________________________________________
>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/20110422/4d2f2393/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/57f24bf5/attachment.html>

An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110422/674c93ae/attachment-0001.html>

On Fri, 22 Apr 2011 00:26:40 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> > Allowing for @property functions to be called with parens or
>> > non- at property
>> > functions to be called without parens leads to major inconsistencies
>> in
>> > usage
>> > of functions, and generally makes @property pointless. Even if you
>> make
>> > it so
>> > that @property functions can't be called with parens while allowing
>> non-
>> > @property functions to be called without them, then that leads to
>> > inconsistent
>> > syntax for function calls and makes it harder to know whether
>> something
>> > is
>> > actually a property function or not.
>>
>> Why is this a benefit? Since your concept of a 'property' differs from
>> mine, @property can only muddy the waters (unless we're both writing
>> code
>> using the same standards document). Being able to switch between call
>> styles, allows me to self document my own (or my company's) guide-lines
>> into the code. Besides, why should I care if something is a 'property'
>> function or a regular function? or even a field, for that matter?
>> There's
>> field syntax and there's method syntax, but why should the library care
>> how I choose to access their code? They don't have to read/review it. I
>> (and my team/managers, etc) do.
>
> One of the points of properties that I've seen commonly discussed in
> languages
> in general is the fact that you can more or less seemlessly switch
> between
> something being a public member variable and a property function.

Actually, seamlessly switching between field and field-like methods isn't a design goal of 'properties'. The actual design goal is to allow the promotion of a field into a member function. Once that occurs, you can never go back, due to method overloading. In fact, OOP concerns were one of the major driving forces behind 'properties' in the first place.

> As soon as
> you're loose about enforcing property syntax that doesn't work.

Actually, since you're not actually suppose to ever downgrade a 'property function', this isn't that big of a deal. And at a more formal level, Methods-as-Fields is a subset of the Uniform access principle. And UAP is capable of downgrading any function, not just 'property function's, to a field, so long as inheritance isn't an issue.

> And the fact
> that D is loose about it is incredibly bizarre.It's the only language
> that I
> know of that works that way.

Both Ruby and Eiffel do similar things.

> Typically, property syntax is strictly enforced
> for property functions and completely disallowed for non-property
> functions.
> C# definitely works that way.
>
> Property functions are part of the API of a library. The fact that they
> are
> property functions is part of that API, just like the names of functions
> and
> how many parameters they have is part of the API. So, making it so that
> @property is strictly enforced such that it strictly defines the syntax
> for
> calling a function isn't really any different from requiring that you
> use a
> specific name when calling a function.

So 'properties' should be strict because ()s are part of the API, but ()'s are only part of the API if 'properties' are strict. (circular logical is circular)

> Making it loose instead is actually the
> sort of thing that is extremely uncommon in programming. Programming
> syntax is
> generally very exact.

I do not think that word means what you think it does. Yes, programming languages need to be unambiguous/exact simply to compile. However, they very often include multiple ways of doing the same thing; infix operator overloading and functions, fields and methods, objects and structs, if/for/foreach/do/while/goto/break/continue, with(...), etc. The option of using ()'s or no-()'s can be view similarly. Note that all those examples have sparked various debates, spawned languages and list wars over the years. D is a multi-paradigm language and should allow you to express 'property' based design as well as non-'property' based design.

> What it sounds to me like is that you just don't like the idea of
> property
> functions and don't want to have to ever use them as property functions.

I'm sorry for that impression. I believe it's party due to the nature of this thread. It began as a response to your assertion that there were zero problems with strict property enforcement. I hope this discussion has at least raised your awareness of some of the issues that exist with strict 'property' enforcement and that you have given some thought to their importance relative to the benefits of strict 'properties'.

I whether I like or dislike 'property functions' is really dependent on your definition of what they are. I've used different "properties" before, read up on their history, usage and conceptual evolution in other languages and academia. C# style 'properties' are, quite literally, a copy of the first 'quick hack' to solve several key software engineering problems. This isn't actually a criticism; the extreme power of C++'s templates, as I understand it, was something of an accidental discovery followed by an evolutionary process. And, in other languages, the original concept of 'properties' has evolved as well. I'd put D as about halfway in the evolutionary process (as currently defined) today. The mixing of field and method notation is still a fairly new concept as programming languages go, and I don't believe the concept has been fully explored and put to rest yet. So yes, the trail isn't as broken in as we may have liked, but I don't believe that is a reason to head back, as it were. As we run into issues, we should evaluate them, dissect the root problem and then brainstorm multiple possible solutions and ways to go forward.

> Personally, I think that it is _way_ better than the incredibly lax way
> that
> property syntax has been handled in the past. And it seems perfectly
> normal to
> me that they'd be just as much a part of the API as the function's name.

Except that it isn't normal, historically speaking. Pre-'properties', no one would consider ()'s as part of a function's API. And in post-'property' languages, no one considers ()'s as part of the API. That 'properties' even gave designers control over ()'s in the first place, is more an artifact of implementation then active, intended design.

> If
> @property isn't enforced, then I don't see much point in ever having
> added it
> in the first place. The only advantage that I can see with having
> @property
> and lax enforcement over no @property at all is the incredibly rare
> ambiguity
> with delegates, and I honestly don't think that that problem merits
> adding
> @property. Strictly enforcing @property, on the other hand, and making
> the
> syntax consistent _is_ well worth it.

What do you mean by 'consistent'?

On Fri, 22 Apr 2011 07:59:54 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>> From: Robert Jacques <sandford at jhu.edu>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Thursday, April 21, 2011 4:05 PM
>> Subject: Re: [phobos] Time to get ready for the next release
>>
>> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>
>>>> How about the amount of existing code it breaks?  How about the fact
>>>> that
>>>> it breaks using the same function for both method chaining and with
>>>> property syntax?
>>>
>>> Something like
>>>
>>> auto b = a.prop1.prop2.prop3;
>>>
>>> should work. I doesn't at present, but it should. There's a bug report on it.
>>
>> What about auto b = a.prop1(5).prop2(6).prop3(7); ?
>
> Looks like a poor design.  If a setter property returns anything, it
> should return the value set.  Otherwise:
> auto b = a.prop1 = 5; // I would expect b == 5

I both David and I have responded in depth to this in other threads. In short, trying to decide the goodness of an API design using an abstracted, out of context, reduced code snippet designed to highlight the syntactic constructs it uses is fallacious.

> my solution:
>
> define a setProp1, setProp2, and setProp3 without property semantics. It also reads better:
>
> auto b = a.setProp1(5).setProp2(6).setProp3(7);

However, in the real API, setProp is a strictly inferior design. In point of fact, your proposed solution suffers from several issues:

1) It isn't DRY (Don't Repeat Yourself). Not only do you have simple code
duplication, but you also have to maintain equality of implementation, not
just bug updates.
2) You've increased the radius of comprehension of your library. Users
have to remember that both functions do the same thing and have to assign
two different names to the action in their head and then use them
appropriately in there code, based on the syntax they wish to use.
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.

>>> As for breaking existing code, _of course_ it's going to. That's to be
>>> expected, and I would have thought that that was expected when
>>> @property was
>>> introduced in the first place.
>>
>> Actually, no it wasn't expected. @property was introduced with loose semantics, not strict semantics. And, by the way, it was judged worth while with only loose semantics.
>
> I don't know what messages you read, but strict properties were what was approved.  There have been numerous discussions on the NG regarding properties, some pro-strict, some pro-loose, but the one which got the deal done was pro-strict.

I've been following/part of the 'property' discussions from day 1. My memory was that @property was 'accepted' inside a pro-strict thread, but wasn't pro-strict itself, and that there was a follow-up confirmation of loose-ness. But, alas, I've deleted my own local newsgroup history and my search-fu is weak. So I can't even find any kind of 'acceptance' post let alone it's context and follow-up. About the best I could find, one way or the other, is a bunch of circumstantial posts indicating the desire to patch a hole, as opposed to replacing the ship. But that could just have been earlier in the decision process. Anyways, my searching did turn up some apropos comments from Andrei:

"
To clarify: if there was any extra checking by the compiler, any
guarantee that the feature would provide at all, I'd be glad to pay the
price of thinking more when putting together a design. But you want to
define a language feature that allows people to require "()" or not as
they please, and that's all. It's a frivolous detail to be spending time
on when designing an API. I simply don't believe that's good language
design.

Andrei
"
"
The problem is that it's all loss, no gain: the callee must make the
decision whether the call must be with or without parens, and the caller
must obey that decision. There is no guarantee gained, only effort.
"

> The loose semantics were introduced to serve as a translation period, where you could migrate property code to using @property.  From what I remember, Walter tried to turn on strict properties, but found too many errors in Phobos to deal with.  So it has been back-burnered.

I don't remember that ever being posted to the newsgroup. And since, the critics of strict 'properties', included myself, would have discussed this, and I can search for myself just fine, I going to trust my memory.

> 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(){})

On 22 April 2011 15:26, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> Don Clugston wrote:
>>
>> It's now been two months since the last release, and there have been
>> huge compiler improvements.
>> Note also that there were a couple of very bad regressions in 2.052,
>> so I think we really need a release ASAP.
>> We've now achieved minimal stability again (all green on the auto-tester).
>>
>> Here's the things which are blockers for the next release:
>>
>> From the compiler side:
>> * struct destruction of temporaries (seems like we have a chance of
>> fixing this soon)
>> * fixing the regressions from my CTFE/const folding changes (Fixes are
>> here: https://github.com/D-Programming-Language/dmd/pull/37).
>> * a few things haven't been backported to D1 yet
>> druntime:
>> * clean up Windows DLL support
>> phobos:
>> * nothing that I know of
>>
>> Looks as though will be time to get std.parallelism in. But otherwise, if you have anything you'd like to get into the next release, please indicate so now.
>
> Compiling the latest and greatest from github, I noticed a few things, most of them changes that broke existing code, good or bad.
>
> - std.net.isemail does not seem to be compiled into the libary on windows. If it is, a debug compile fails because dmd stumbles over generating debug information for a string enum. Here's a patch that simply skips writing the enum fields, the type information is marked as incomplete anyway.
>
> https://github.com/rainers/dmd/commit/9d69feb17f075757c9e6874f64b201fa2f40d5b0
>
> - const string[] can no longer be passed to functions expecting string[] argument
>
> This is correct, but very strict. The array pointer and length of the argument could be modifiable, but the data elements pointed to should not. unfortunately, there is no type to express that. (Would const(string[])ref do that?)
>
> - variables of type string no longer implicitely cast to const(char)*
>
> I'm fine with this change.
>
> - const string values no longer accepted in switch-case, you have to use enum string.
>
> I'm not so sure about this. You might want to use the same string elsewhere, too, so you will have to define it twice, once for switch statements with enum, and once for other runtime purposes e.g. taken the address of the string.

There are a couple of issues which are fixed in my latest pull request.

> - struct initializers using {} are no longer evaluated at runtime? the compiler complains that the initializers do not evaluate at compile time.

That's bug 3809, they've always been evaluated at compile time. Previously some cases compiled, but didn't actually work. Bug 3271, 2850. Now it is consistent.


> I'm fine with replacing these with the Struct(args) syntax, but AFAIK it does not allow direct initializing of static arrays in the struct, you have to pass a dynamically created array literal. In my case I also needed to add an ugly cast(ubyte[]) to the argument, because [0,0] is interpreted as an array of integers.
>
> - std.parallelism.atomicIncUint no longer compiles, because there seem to be stronger checks regarding shared. Seems good to me.
>
> - the deprecation of octal numbers revealed an error in the Windows SDK header files (v6.0A, I haven't yet checked if it is fixed in newer versions).
>
> With all these issues fixed, Visual D seems to compile and run fine. All changes are backward compatible, so I can still switch back to dmd 2.052.
>
> Rainer
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>

On Fri, 22 Apr 2011 08:30:41 -0400, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
>> From: Robert Jacques <sandford at jhu.edu>
>> To: Discuss the phobos library for D <phobos at puremagic.com>
>> Sent: Thursday, April 21, 2011 11:00 PM
>> Subject: Re: [phobos] Time to get ready for the next release
>>
>>
>> The API design we are talking about is called 'Fluent interface' (http://en.wikipedia.org/wiki/Fluent_interface). So, as I'd say to a friend, It's A Thing(TM). And better minds than you and I have used it, recommend it (when applicable, of course) and implemented it in large, production quality libraries, etc. It's also completely and totally true that it violates the concept of a 'property', as defined by C# et al.. But that doesn't make it a bad design, just a design which wishes to blur the line between 'field' and 'method'. Notice, how I didn't say 'property' in there. My point is that there are valid design patterns which don't fit nicely into the labels of 'field', 'method' and 'property'.
>
> Notice that in the wikipedia article, in languages where properties exist, the fluent interface defines the property setters separately from the function setters.  e.g. in C#, you have:
>
> public string Color
> {
>    set {color = value;}
>
> }
>
> ...
>
> public IConfigurationFluent SetColor(string color)
> {
>    this.color = color;
>    return this;
>
> }
>
> Note especially the different names SetColor and Color.
>
> Essentially, to re-use the property as a fluent interface is a mutant form of Fluent Interface, and frankly, looks horrendous to me.  If you want both, define both.  a.prop1(5).prop2(7) reads poorly, and is confusing as hell, especially if you replace prop1 with an ambiguous term that could be a noun or a verb.  a.setProp1(5).setProp2(7) looks way better.
>
> Like it or not, the parentheses of a function call are part of the interface.  And the interface is defined by the author, not the caller. It means every time I see a property syntax, I have to go look up what that actually means.  It means as an author, I cannot come up with meaningful short names for my methods, because they might be used in a bastardized way by some clever programmer, and confuse everyone.  It means hello to methods like doRead().  bleh, no thanks.
>
> -Steve

Since you made most of these points in another thread, simply address the
one additional point made here;
That C# example doesn't use properties at all. And nether does the first
Java example. Or any of the other initial examples. But they are there to
present and teach a concept in the simplest way possible, not be
representative of production code. By the way, if you read down further,
you'd see that the second Java example, is actually from production code
and does use the 'mutant' syntactic form: pk.pack( nm
).gridx(1).gridy(0).fillx();  (and it mixes both verb and prop to boot).

I think I would like to have something in the middle of strict and loose semantics. I would like that functions marked with @property have to be called like a field:

auto bar = foo.field;
foo.field = 3;

But functions not marked with @property still can be called without the parentheses:

foo.bar();
foo.bar;

On 21 apr 2011, at 16:09, David Simcha wrote:

> As I've said before, we really need to decide whether @property has loose or strict semantics.  Loose semantics means that non- at property functions would still be callable without (), etc but @property functions wouldn't be allowed to have ()s.  Frankly, I hate @property, want to to have as little effect as possible,  like the flexibility of being able to call the same function both ways, and would have a lot of code break if this were taken away, so my vote is loose semantics.
> 
> On Thu, Apr 21, 2011 at 9:24 AM, Michel Fortin <michel.fortin at michelf.com> wrote: Le 2011-04-21 ? 6:48, Torarin a ?crit :
> 
> > Dmd has a bug that causes the @property attribute to be disregarded in functions that return auto.
> 
> Indeed. I think I have a fix for that in the "@property" branch of my DMD fork on github. Perhaps I should make a pull request from that.
> 
> Actually, I could make a pull request for the entire "@property" branch, it shouldn't impact things much as enforcement of @property is only done if you add the command line switch -property. Would that make sense?
> 
> --
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 
> 
> 
> _______________________________________________
> 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

-- 
/Jacob Carlborg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110423/2c675769/attachment.html>

Why can't something like this be available on the D website?

On 21 apr 2011, at 19:09, Walter Bright wrote:

> 
> 
> On 4/21/2011 6:24 AM, Michel Fortin wrote:
>> I'm just wondering how many DMD release will pass before my "const(Object)ref" pull request for DMD get reviewed. I don't want to push Walter too much, but the more he waits the more likely it won't merge so easily.
>> 
> 
> I understand. My current priority is to get temp destruction to work right. Following on is fixing fundamental issues with const, and getting disabling of default construction to work.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

-- 
/Jacob Carlborg