On Wed, Jun 23, 2010 at 19:36, David Simcha <dsimcha at gmail.com> wrote:

> 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.


Oh, nice call! I'm also getting tired of putting comments around the refs, release after release, to make ranges in phobos accept one another. I'd be glad to be of help, if I can (though with two children sick right now, I don't promise to get enough sleep to be useful)


> Before I do, do we all agree on the following:
>
> 1.  All higher order ranges should use auto ref.
>

My own tentative auto refs for std.range didn't change the lvalue/rvalue issues :(


> 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.
>
>
I'd even go as far as saying that HOR should propagate their input's
properties as much as possible, as you did with bug 2872 (hmm, I didn't find
that a few months ago, that's why I posted 3871).
Also, bug 3872.

Philippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100623/8e44caa5/attachment.html>

Another option -- put the code in as an optional build parameter for dmd.  Then people who want to get phobos ready can build their own dmd copy to work on the issues.  These should be easy, but mostly busywork, because the compiler will simply complain when something is invalid.  They'll all be pretty much 3-second bugs :)

And as far as "design by newsgroup" I think almost all the new features were vetted on the newsgroup at one point, including inout.  It's unfair to simply point to ones you disagree with as evidence of failure ;)

In defense of @property, I think we all agree we needed something to distinguish setters from single-arg functions.  I think with a reasonable rule, we can allow calling no-arg functions without parens (via a proposal I made earlier that as long as the function returns void, it should be allowed).  All that's left is actual property getters.  I can't say enough that @property in those cases has nothing to do with functionality and everything to do with human interpretation.  Like it or not, the use of parentheses is an extension of the function name, whose semantic meaning of course is unenforceable.  But just allowing the user to decide whether something is a property or a function leaves the interpretation up to the user, taking all the power away from the author who wrote the function.  @property is a clarification tool, and by necessity, is implemented via convention rather than compiler enforcement.


-Steve


----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Wed, June 23, 2010 12:18:34 PM
> Subject: Re: [phobos] phobos commit, revision 1689
> 
> 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 <
> href="mailto:andrei at erdani.com">andrei at erdani.com
> <mailto:
> ymailto="mailto:andrei at erdani.com"
> href="mailto:andrei at erdani.com">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
> 
> <
> href="mailto:andrei at erdani.com">andrei at erdani.com <mailto:
> ymailto="mailto:andrei at erdani.com"
> href="mailto:andrei at erdani.com">andrei at erdani.com>
> 
>      <mailto:
> href="mailto:andrei at erdani.com">andrei at erdani.com <mailto:
> ymailto="mailto:andrei at erdani.com"
> href="mailto:andrei at erdani.com">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
> 
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com <mailto:
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com>
> 
> 
> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> 
> _______________________________________________
> phobos mailing
> list
> 
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos
> mailing list

> href="mailto:phobos at puremagic.com">phobos at puremagic.com

> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos

On 06/24/2010 11:11 AM, Steve Schveighoffer wrote:
> And as far as "design by newsgroup" I think almost all the new features were vetted on the newsgroup at one point, including inout. It's unfair to simply point to ones you disagree with as evidence of failure ;)

I was referring to those that have arguably shown themselves to be failures.

> In defense of @property, I think we all agree we needed something to distinguish setters from single-arg functions.  I think with a reasonable rule, we can allow calling no-arg functions without parens (via a proposal I made earlier that as long as the function returns void, it should be allowed).

Fine, though that leaves writeln = 5; on the table.

> All that's left is actual property
> getters.  I can't say enough that @property in those cases has
> nothing to do with functionality and everything to do with human
> interpretation.  Like it or not, the use of parentheses is an
> extension of the function name, whose semantic meaning of course is
> unenforceable.  But just allowing the user to decide whether
> something is a property or a function leaves the interpretation up to
> the user, taking all the power away from the author who wrote the
> function.  @property is a clarification tool, and by necessity, is
> implemented via convention rather than compiler enforcement.

I've heard this argument before. I acknowledge there is a need to address unpleasant corner cases such as functions that return functions or delegates. What I'm saying is that the feature as designed hurts most for the benefit of a couple tiny corner cases. I've seen that several times in several language before. It's called bad design.

What I'm seeing in the field after faithfully using @property for a while fits my worst predictions:

1. Code is sprinkled with @property so there's more syntactic noise to introduce and to deal with;

2. Whenever I define some function I need to make an arbitrary decision whether that will be a @property or not. Reasonable people could ask me why I chose whichever way I chose. (Most recent example: save() for forward ranges.) Arbitrary decisions are bad.

@property is badly designed, no two ways about it. I now regret I didn't lobby more against it. I have a similar regret about lazy.


Andrei

On Thu, Jun 24, 2010 at 1:15 PM, Andrei Alexandrescu <andrei at erdani.com>wrote:

>
> Fine, though that leaves writeln = 5; on the table.


This argument drives me crazy.  D will also allow me to do stuff like
system("rm -rf /"); or uint* foo = cast(uint*) cast(void*) uniform(0U,
uint.max);  (*foo)++;.  Languages should and do allow a superset of what
reasonable people would want to do, because drawing the line perfectly is
impossible.  In other words, just because you can doesn't mean you should.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100624/e0922695/attachment.html>

All a matter of opinion, but I'd say that @property should only be applied to logical properties of the data structure (go figure).  A clone method (ie. save) doesn't represent an attribute of the data, it's simply a non-mutating operation on the data.  An easy litmus test is whether the member could be replaced with a public variable.  If so, it's probably a property.  This is the real purpose of the no-parens syntax anyway--it allows the class designer to replace public data members with functions at no cost to the end user.

On Jun 23, 2010, at 7:45 AM, Andrei Alexandrescu wrote:

> 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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Well said.  This is the rule I am using as well.

-Lars



On Thu, 2010-06-24 at 11:49 -0700, Sean Kelly wrote:
> All a matter of opinion, but I'd say that @property should only be applied to logical properties of the data structure (go figure).  A clone method (ie. save) doesn't represent an attribute of the data, it's simply a non-mutating operation on the data.  An easy litmus test is whether the member could be replaced with a public variable.  If so, it's probably a property.  This is the real purpose of the no-parens syntax anyway--it allows the class designer to replace public data members with functions at no cost to the end user.
> 
> On Jun 23, 2010, at 7:45 AM, Andrei Alexandrescu wrote:
> 
> > 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
> > _______________________________________________
> > 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

In fact, save should not be implemented unless it looks like this:

T save() { return this; }

So it's pretty much a property.  If you implement save on ranges where the operation will be costly, you are looking for trouble with algorithms that require save.

This is why I don't really like the concept of save.

-Steve



----- Original Message ----
> From: Lars Tandle Kyllingstad <lars at kyllingen.net>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Fri, June 25, 2010 2:44:51 AM
> Subject: Re: [phobos] phobos commit, revision 1689
> 
> Well said.  This is the rule I am using as well.

-Lars



On Thu, 2010-06-24 at 11:49 -0700, Sean Kelly
> wrote:
> All a matter of opinion, but I'd say that @property should only
> be applied to logical properties of the data structure (go figure).  A
> clone method (ie. save) doesn't represent an attribute of the data, it's simply
> a non-mutating operation on the data.  An easy litmus test is whether the
> member could be replaced with a public variable.  If so, it's probably a
> property.  This is the real purpose of the no-parens syntax anyway--it
> allows the class designer to replace public data members with functions at no
> cost to the end user.
> 
> On Jun 23, 2010, at 7:45 AM, Andrei Alexandrescu wrote:
> 
> > 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 <
> href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com
> >> 
> <mailto:
> href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com>>
> wrote:
> >> 
> >> 
> >> 
> 
> >>    On Wed, Jun 23, 2010 at 4:07 PM,
> href="http://dsource.org">dsource.org <http://dsource.org>
> 
> >>    <
> href="mailto:noreply at dsource.org">noreply at dsource.org <mailto:
> ymailto="mailto:noreply at dsource.org"
> href="mailto:noreply at 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
> >> 
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com <mailto:
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com>
> 
> >>    http://lists.puremagic.com/mailman/listinfo/phobos
> 
> >> 
> >> 
> >> 
> >> 
> >> 
> _______________________________________________
> >> phobos mailing
> list
> >> 
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
> >> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
> > 
> _______________________________________________
> > phobos mailing
> list
> > 
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
> > 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> _______________________________________________
> phobos mailing
> list
> 
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos


_______________________________________________
phobos
> mailing list

> href="mailto:phobos at puremagic.com">phobos at puremagic.com

> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos

A range implemented as a class would define

T save() { return clone(); }

Andrei

On 06/25/2010 08:24 AM, Steve Schveighoffer wrote:
> In fact, save should not be implemented unless it looks like this:
>
> T save() { return this; }
>
> So it's pretty much a property.  If you implement save on ranges where the operation will be costly, you are looking for trouble with algorithms that require save.
>
> This is why I don't really like the concept of save.
>
> -Steve
>
>
>
> ----- Original Message ----
>> From: Lars Tandle Kyllingstad<lars at kyllingen.net>
>> To: Discuss the phobos library for D<phobos at puremagic.com>
>> Sent: Fri, June 25, 2010 2:44:51 AM
>> Subject: Re: [phobos] phobos commit, revision 1689
>>
>> Well said.  This is the rule I am using as
>> well.
>
> -Lars
>
>
>
> On Thu, 2010-06-24 at 11:49 -0700, Sean Kelly
>> wrote:
>> All a matter of opinion, but I'd say that @property should only
>> be applied to logical properties of the data structure (go figure).  A
>> clone method (ie. save) doesn't represent an attribute of the data, it's simply
>> a non-mutating operation on the data.  An easy litmus test is whether the
>> member could be replaced with a public variable.  If so, it's probably a
>> property.  This is the real purpose of the no-parens syntax anyway--it
>> allows the class designer to replace public data members with functions at no
>> cost to the end user.
>>
>> On Jun 23, 2010, at 7:45 AM, Andrei
>> Alexandrescu wrote:
>>
>>> 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<
>> href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com
>>>>
>> <mailto:
>> href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com>>
>> wrote:
>>>>
>>>>
>>>>
>>
>>>>     On Wed, Jun 23, 2010 at 4:07 PM,
>> href="http://dsource.org">dsource.org<http://dsource.org>
>>
>>>>     <
>> href="mailto:noreply at dsource.org">noreply at dsource.org<mailto:
>> ymailto="mailto:noreply at dsource.org"
>> href="mailto:noreply at 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
>>>>
>> ymailto="mailto:phobos at puremagic.com"
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com<mailto:
>> ymailto="mailto:phobos at puremagic.com"
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com>
>>
>>>>     http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> _______________________________________________
>>>> phobos mailing
>> list
>>>>
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>>>
>> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>> _______________________________________________
>>> phobos mailing
>> list
>>>
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>>
>> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
>> _______________________________________________
>> phobos mailing
>> list
>>
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>
>> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> _______________________________________________
> phobos
>> mailing list
>
>> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>
>> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

And such a range would be dog-slow in an algorithm that assumes save() is quick.

-Steve



----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Fri, June 25, 2010 9:41:13 AM
> Subject: Re: [phobos] phobos commit, revision 1689
> 
> A range implemented as a class would define

T save() { return clone();
> }

Andrei

On 06/25/2010 08:24 AM, Steve Schveighoffer
> wrote:
> In fact, save should not be implemented unless it looks like
> this:
>
> T save() { return this; }
>
> So it's pretty much a property.  If you implement save on ranges where the operation will be costly, you are looking for trouble with algorithms that require save.
>
> This is why I don't really like the concept of save.
>
> -Steve
>
>
>
> ----- Original 
> Message ----
>> From: Lars Tandle Kyllingstad<
> ymailto="mailto:lars at kyllingen.net" href="mailto:lars at kyllingen.net">lars at kyllingen.net>
>> To:
> Discuss the phobos library for D<
> href="mailto:phobos at puremagic.com">phobos at puremagic.com>
>> 
> Sent: Fri, June 25, 2010 2:44:51 AM
>> Subject: Re: [phobos] phobos
> commit, revision 1689
>>
>> Well said.  This is the rule
> I am using as
>> well.
>
> 
> -Lars
>
>
>
> On Thu, 2010-06-24 at 11:49 -0700, Sean Kelly
>> wrote:
>> All a matter of opinion, but I'd say that
> @property should only
>> be applied to logical properties of the data
> structure (go figure).  A
>> clone method (ie. save) doesn't
> represent an attribute of the data, it's simply
>> a non-mutating
> operation on the data.  An easy litmus test is whether the
>> 
> member could be replaced with a public variable.  If so, it's probably a
>> property.  This is the real purpose of the no-parens syntax
> anyway--it
>> allows the class designer to replace public data members
> with functions at no
>> cost to the end user.
>>
>> 
> On Jun 23, 2010, at 7:45 AM, Andrei
>> Alexandrescu
> wrote:
>>
>>> 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<
>> href="mailto:
> ymailto="mailto:maxsamukha at gmail.com" href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com"> ymailto="mailto:maxsamukha at gmail.com" href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com
>>>>
>> 
> <mailto:
>> href="mailto:
> href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com"> ymailto="mailto:maxsamukha at gmail.com" href="mailto:maxsamukha at gmail.com">maxsamukha at gmail.com>>
>> 
> wrote:
>>>>
>>>>
>>>>
>>
>>>> 
>    On Wed, Jun 23, 2010 at 4:07 PM,
>> 
> href="http://dsource.org">
> href="http://dsource.org">dsource.org<
> target=_blank >http://dsource.org>
>>
>>>> 
>    <
>> href="mailto:
> href="mailto:noreply at dsource.org">noreply at dsource.org">
> ymailto="mailto:noreply at dsource.org"
> href="mailto:noreply at dsource.org">noreply at dsource.org<mailto:
>> 
> ymailto="mailto:
> href="mailto:noreply at dsource.org">noreply at dsource.org"
>> 
> href="mailto:
> href="mailto:noreply at dsource.org">noreply at dsource.org">
> ymailto="mailto:noreply at dsource.org"
> href="mailto:noreply at 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
>>>>
>> ymailto="mailto:
> ymailto="mailto:phobos at puremagic.com" href="mailto:phobos at puremagic.com">phobos at puremagic.com"
>> 
> href="mailto:
> href="mailto:phobos at puremagic.com">phobos at puremagic.com">
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com<mailto:
>> 
> ymailto="mailto:
> href="mailto:phobos at puremagic.com">phobos at puremagic.com"
>> 
> href="mailto:
> href="mailto:phobos at puremagic.com">phobos at puremagic.com">
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com>
>>
>>>> 
> 
> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> 
> _______________________________________________
>>>> phobos
> mailing
>> list
>>>>
>> href="mailto:
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com">
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>>>
>> 
> href="
> >http://lists.puremagic.com/mailman/listinfo/phobos"
> target=_blank
>>> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>> 
> _______________________________________________
>>> phobos
> mailing
>> list
>>>
>> href="mailto:
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com">
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>>
>> 
> href="
> >http://lists.puremagic.com/mailman/listinfo/phobos"
> target=_blank
>>> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
>> 
> _______________________________________________
>> phobos
> mailing
>> list
>>
>> href="mailto:
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com">
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>>
>> 
> href="
> >http://lists.puremagic.com/mailman/listinfo/phobos"
> target=_blank
>>> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> 
> _______________________________________________
> phobos
>> 
> mailing list
>
>> href="mailto:
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com">
> ymailto="mailto:phobos at puremagic.com"
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
>
>> 
> href="
> >http://lists.puremagic.com/mailman/listinfo/phobos"
> target=_blank
>>> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
> 
> _______________________________________________
> phobos mailing
> list
> 
> href="mailto:phobos at puremagic.com">phobos at puremagic.com
> 
> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos
> mailing list

> href="mailto:phobos at puremagic.com">phobos at puremagic.com

> href="http://lists.puremagic.com/mailman/listinfo/phobos" target=_blank
> >http://lists.puremagic.com/mailman/listinfo/phobos

On 06/25/2010 08:44 AM, Steve Schveighoffer wrote:
> And such a range would be dog-slow in an algorithm that assumes save() is quick.

We discussed this. There is no exit. An algorithm does assume that save() is not proportional to the size of the range, but not that it's necessarily "quick".

Andrei