phobos commit, revision 1689


user: dsimcha

msg:
Fix unittests in std.range.

http://www.dsource.org/projects/phobos/changeset/1689

On Wed, Jun 23, 2010 at 4:07 PM, dsource.org <noreply at dsource.org> wrote:

> phobos commit, revision 1689
>
>
> user: dsimcha
>
>
save() is sometimes attributed with @property, other times it is not. Is it
really a property? I don't think it is a good idea to tag every function
with @property just to make it callable without ().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100623/3fce20f4/attachment.html>

Isn't that the point of @property?  I just followed what Andrei was doing. If there's anywhere where I didn't put @property in, it's purely an unintentional oversight.  Please let me know and/or fix it.

On Wed, Jun 23, 2010 at 9:34 AM, Max Samukha <maxsamukha at gmail.com> wrote:

>
>
> On Wed, Jun 23, 2010 at 4:07 PM, dsource.org <noreply at dsource.org> wrote:
>
>> phobos commit, revision 1689
>>
>>
>> user: dsimcha
>>
>>
> save() is sometimes attributed with @property, other times it is not. Is it
> really a property? I don't think it is a good idea to tag every function
> with @property just to make it callable without ().
>
> _______________________________________________
> 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/20100623/cb47ae49/attachment.html>

I think it should be a property. I followed the convention that stuff that doesn't change "this" is a property.

Andrei

On 06/23/2010 09:01 AM, David Simcha wrote:
> Isn't that the point of @property?  I just followed what Andrei was doing.  If there's anywhere where I didn't put @property in, it's purely an unintentional oversight.  Please let me know and/or fix it.
>
> On Wed, Jun 23, 2010 at 9:34 AM, Max Samukha <maxsamukha at gmail.com <mailto:maxsamukha at gmail.com>> wrote:
>
>
>
>     On Wed, Jun 23, 2010 at 4:07 PM, dsource.org <http://dsource.org>
>     <noreply at dsource.org <mailto:noreply at dsource.org>> wrote:
>
>         phobos commit, revision 1689
>
>
>         user: dsimcha
>
>
>     save() is sometimes attributed with @property, other times it is
>     not. Is it really a property? I don't think it is a good idea to tag
>     every function with @property just to make it callable without ().
>
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto: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

On Wed, Jun 23, 2010 at 5:45 PM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> I think it should be a property. I followed the convention that stuff that doesn't change "this" is a property.
>
> Andrei
>

But property setters are often supposed to change 'this'? Honestly I can hardly see much utility in @property. For example, Q_PROPERTY in Qt adds value. It is introspectable, can fire a notification when changed, optionally shows up in the designer, is resettable to a default value and more. Is @property only useful for disambiguating the case when a function returns a callable?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100623/ef8cd5d8/attachment.html>

On 06/23/2010 10:59 AM, Max Samukha wrote:
>
>
> On Wed, Jun 23, 2010 at 5:45 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>
>     I think it should be a property. I followed the convention that
>     stuff that doesn't change "this" is a property.
>
>     Andrei
>
>
> But property setters are often supposed to change 'this'?

Well of course I was referring to getters.

> Honestly I can
> hardly see much utility in @property. For example, Q_PROPERTY in Qt adds
> value. It is introspectable, can fire a notification when changed,
> optionally shows up in the designer, is resettable to a default value
> and more. Is @property only useful for disambiguating the case when a
> function returns a callable?

On the same grounds, I opposed @property tooth and nail and now, unpleasantly enough, my worst scares are coming true: @property is a non-falsifiable sham, a convention defined for the sake of following it. I strongly believe the alternatives I proposed would have been vastly better.


Andrei

When is @property going to start being enforced, i.e. when are you going to no longer be able to call non @property functions w/o ()s or assign using the = sign to a non- at property function?  I never really followed the newsgroup discussion b/c I was happy with the old status quo and didn't think Walter would give in, so I lost track of what exactly @property even does.

On Wed, Jun 23, 2010 at 12:07 PM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> On 06/23/2010 10:59 AM, Max Samukha wrote:
>
>>
>>
>> On Wed, Jun 23, 2010 at 5:45 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>>
>>    I think it should be a property. I followed the convention that
>>    stuff that doesn't change "this" is a property.
>>
>>    Andrei
>>
>>
>> But property setters are often supposed to change 'this'?
>>
>
> Well of course I was referring to getters.
>
>
>  Honestly I can
>> hardly see much utility in @property. For example, Q_PROPERTY in Qt adds value. It is introspectable, can fire a notification when changed, optionally shows up in the designer, is resettable to a default value and more. Is @property only useful for disambiguating the case when a function returns a callable?
>>
>
> On the same grounds, I opposed @property tooth and nail and now, unpleasantly enough, my worst scares are coming true: @property is a non-falsifiable sham, a convention defined for the sake of following it. I strongly believe the alternatives I proposed would have been vastly better.
>
>
> Andrei
>
> _______________________________________________
> 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/20100623/0ce96d83/attachment.html>

Walter tried to enable the restriction at some point but that breaks a ton of code in Phobos (and probably elsewhere). We discussed adding it as an compiler flag that I'd turn on, get Phobos to work, and then check in before dmd makes it mandatory.

@property is a prime example countering the theory that Walter doesn't listen to what's going on on the newsgroup (lazy is another one.) Unfortunately, design by newsgroup is seldom good, sigh. Landslide popular vote is not a good measure of quality. Good examples of proposals coming from the newsgroup have been, I think, most always originating from strong individual propositions (e.g. Steve's inout).


Andrei

On 06/23/2010 11:11 AM, David Simcha wrote:
> When is @property going to start being enforced, i.e. when are you going to no longer be able to call non @property functions w/o ()s or assign using the = sign to a non- at property function?  I never really followed the newsgroup discussion b/c I was happy with the old status quo and didn't think Walter would give in, so I lost track of what exactly @property even does.
>
> On Wed, Jun 23, 2010 at 12:07 PM, Andrei Alexandrescu <andrei at erdani.com <mailto:andrei at erdani.com>> wrote:
>
>     On 06/23/2010 10:59 AM, Max Samukha wrote:
>
>
>
>         On Wed, Jun 23, 2010 at 5:45 PM, Andrei Alexandrescu
>         <andrei at erdani.com <mailto:andrei at erdani.com>
>         <mailto:andrei at erdani.com <mailto:andrei at erdani.com>>> wrote:
>
>             I think it should be a property. I followed the convention that
>             stuff that doesn't change "this" is a property.
>
>             Andrei
>
>
>         But property setters are often supposed to change 'this'?
>
>
>     Well of course I was referring to getters.
>
>
>         Honestly I can
>         hardly see much utility in @property. For example, Q_PROPERTY in
>         Qt adds
>         value. It is introspectable, can fire a notification when changed,
>         optionally shows up in the designer, is resettable to a default
>         value
>         and more. Is @property only useful for disambiguating the case
>         when a
>         function returns a callable?
>
>
>     On the same grounds, I opposed @property tooth and nail and now,
>     unpleasantly enough, my worst scares are coming true: @property is a
>     non-falsifiable sham, a convention defined for the sake of following
>     it. I strongly believe the alternatives I proposed would have been
>     vastly better.
>
>
>     Andrei
>
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto: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

On Wed, Jun 23, 2010 at 5:01 PM, David Simcha <dsimcha at gmail.com> wrote:

> Isn't that the point of @property?  I just followed what Andrei was doing. If there's anywhere where I didn't put @property in, it's purely an unintentional oversight.  Please let me know and/or fix it.
>
> I don't have commit access to phobos. DummyRange.front on line 1644 and
DummyRange.save (1647) should be properties, I believe. Also, 'front' on
line 1553.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100623/09ca13fd/attachment.html>

Ok, so I'll probably have time soon to do a serous cleanup of all these nagging @property and auto ref issues and improve the unittests in std.range and std.algorithm, across everything, not just the couple ranges that I worked on recently.  I'm sick enough of all these little nagging issues that make ranges hard to use in D that I'm willing to devote some significant effort towards solving them.  Before I do, do we all agree on the following:

1.  All higher order ranges should use auto ref.
2.  front(), empty(), back(), length() and save() are @property.
3.  popFront(), popBack(), and moveFront() are *NOT* @property.
4.  Higher order ranges should check for infinite-ness of the ranges they're
operating on and propagate it (using enum bool empty = false instead of a
function that propagates empty) where it makes sense, for example in Map and
Filter.

If so, these standards should be published somewhere to discourage the kind of inconsistency that's developed due to sheer confusion about what the "right" answers to these issues are.

On Wed, Jun 23, 2010 at 1:20 PM, Max Samukha <maxsamukha at gmail.com> wrote:

>
>
> On Wed, Jun 23, 2010 at 5:01 PM, David Simcha <dsimcha at gmail.com> wrote:
>
>> Isn't that the point of @property?  I just followed what Andrei was
>> doing.  If there's anywhere where I didn't put @property in, it's purely an
>> unintentional oversight.  Please let me know and/or fix it.
>>
>> I don't have commit access to phobos. DummyRange.front on line 1644 and
> DummyRange.save (1647) should be properties, I believe. Also, 'front' on
> line 1553.
>
>
> _______________________________________________
> 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/20100623/8aa3eee8/attachment-0001.html>