www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is array.reverse a property and not a method?

reply eris <jvburnes gmail.com> writes:
Just though I'd post here on something that made me question my sanity late
one night.

I was working on some test code and for some reason put parens around
"myArray.reverse".  After that the compiler complained that "reverse" was an
unknown identifier.  It took me about 30 minutes at 2am to finally give up and
figure out I needed sleep.

The next morning after some google searching I noticed that everyone was
referring to the 'reverse' "property".  That caught my eye.  reverse property?
 Thats not a property, it's a method -- especially since it does an in-place
modification of the object.

This must mean it's something I don't understand.  The only thing I could
think of is that the "reverse" property is actually a boolean which tells the
iterator which direction to traverse the data structure.

Your thought are appreciated.
Jul 12 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Jul 2010 12:16:32 -0400, eris <jvburnes gmail.com> wrote:

 Just though I'd post here on something that made me question my sanity  
 late
 one night.

 I was working on some test code and for some reason put parens around
 "myArray.reverse".  After that the compiler complained that "reverse"  
 was an
 unknown identifier.  It took me about 30 minutes at 2am to finally give  
 up and
 figure out I needed sleep.

 The next morning after some google searching I noticed that everyone was
 referring to the 'reverse' "property".  That caught my eye.  reverse  
 property?
  Thats not a property, it's a method -- especially since it does an  
 in-place
 modification of the object.

 This must mean it's something I don't understand.  The only thing I could
 think of is that the "reverse" property is actually a boolean which  
 tells the
 iterator which direction to traverse the data structure.

 Your thought are appreciated.

reverse, sort, dup, idup, keys, etc. are all "properties" that were present before genuine properties were added to the language. sort is all but deprecated, since std.algorithm.sort exists. reverse could even more easily be implemented as a library function than sort, it should be removed as well. dup and idup have problems as builtins also, see this bug: http://d.puremagic.com/issues/show_bug.cgi?id=3550. But that's not because they are propertites. I personally don't think they should be properties, but that's open to interpretation. The only one I see there that is truly a property is keys. -Steve
Jul 12 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/12/2010 11:53 AM, Steven Schveighoffer wrote:
 On Mon, 12 Jul 2010 12:16:32 -0400, eris <jvburnes gmail.com> wrote:

 Just though I'd post here on something that made me question my sanity
 late
 one night.

 I was working on some test code and for some reason put parens around
 "myArray.reverse". After that the compiler complained that "reverse"
 was an
 unknown identifier. It took me about 30 minutes at 2am to finally give
 up and
 figure out I needed sleep.

 The next morning after some google searching I noticed that everyone was
 referring to the 'reverse' "property". That caught my eye. reverse
 property?
 Thats not a property, it's a method -- especially since it does an
 in-place
 modification of the object.

 This must mean it's something I don't understand. The only thing I could
 think of is that the "reverse" property is actually a boolean which
 tells the
 iterator which direction to traverse the data structure.

 Your thought are appreciated.

reverse, sort, dup, idup, keys, etc. are all "properties" that were present before genuine properties were added to the language.

All of these antiquated built-ins should be moved into the library (either druntime or phobos).
 sort is all but deprecated, since std.algorithm.sort exists.

 reverse could even more easily be implemented as a library function than
 sort, it should be removed as well.

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#reverse Andrei
Jul 12 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 sort is all but deprecated, since std.algorithm.sort exists.

 reverse could even more easily be implemented as a library function than
 sort, it should be removed as well.

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#reverse

D site can enjoy a page that lists the deprecated D2 features (and maybe for each of them lists what to use instead of it), so current D2 programmers can avoid what will be removed. Bye, bearophile
Jul 12 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/12/2010 02:28 PM, bearophile wrote:
 Andrei Alexandrescu:
 sort is all but deprecated, since std.algorithm.sort exists.

 reverse could even more easily be implemented as a library
 function than sort, it should be removed as well.

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#reverse

D site can enjoy a page that lists the deprecated D2 features (and maybe for each of them lists what to use instead of it), so current D2 programmers can avoid what will be removed.

Good point. I'd to do some more renaming around Phobos and figure out an approach to deprecating names that aren't longer used. I'm thinking: std.conv -> std.conversion Rationale: it's a seldom typed name so shortening it is just odd std.stdio -> std.io Rationale: stuttering sucks. put(R, E) -> putNext(R, E) Rationale: conveys the notion that there is progress in the output. BidirectionalRange -> DoublyEndedRange Rationale: bidirectional suggests something that can move *in* either direction, whereas in fact the range can be shortened from either end. Would this be an improvement? Andrei
Jul 12 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 std.conv -> std.conversion

OK.
 std.stdio -> std.io

OK.
 put(R, E) -> putNext(R, E)

Uhm. I don't like this a lot.
 BidirectionalRange -> DoublyEndedRange

Acceptable. More suggestions: std.cover => std.coverage Rationale: this module is not used very often, so by Zipf law you can use the full word. std.typecons => std.records (that contains Record/record) std.typetuple => std.tuples (that contains Tuple) Rationale: a "typetuple" can contain values too, and structs have a tupleof method, not a typetupleof method. std.concurrency/std.thread => std.concurrency std.metastrings/std.traits => std.meta std.bitmanip => std.bits ? Rationale: 'bitmanip' is not a nice name. std.date/std.gregorian => std.time ? std.range => std.ranges ? std.regex/std.regexp => std.re (as in Python) ? Rationale: in certain kinds of modules this is used often, but 'regex' name too is acceptable. Bye, bearophile
Jul 12 2010
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:i1fs3g$2ev4$1 digitalmars.com...
 Andrei Alexandrescu:

 std.stdio -> std.io


I think this was brought up before and Walter didn't like it because he felt that putting it in the "std" package didn't make it blatantly obvious that it was the "standard" io module instead of just some random io module that got put into "std" for who knows what crazy reason. Of course, I completely disagree with him on that and would welcome the change.
 BidirectionalRange -> DoublyEndedRange


Umm, "DoubleEndedRange" please...
 std.metastrings/std.traits => std.meta

I like this a *lot*.
Jul 12 2010
prev sibling next sibling parent Brian Schott <brian-schott cox.net> writes:
On 07/12/2010 12:42 PM, Andrei Alexandrescu wrote:
 
 Would this be an improvement?
 

Yes. I approve enough to come out of lurking. (Though I do agree with Nick on "DoubleEndedRange") - Brian
Jul 12 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 06:23 AM, Steven Schveighoffer wrote:
 On Mon, 12 Jul 2010 15:42:49 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 put(R, E) -> putNext(R, E)

 Rationale: conveys the notion that there is progress in the output.

Can we have E getNext(R) also for completeness :) Then an input range can be defined similarly to an output range (where delegates and ranges that support E get() work).

Yah, see the parallel thread.
 Since put/putNext already establishes the notion of throwing when full,
 having getNext throwing when empty would be OK, no?

That does go against the "don't use exceptions for normal control flow" mantra, with which I agree. From a practical perspective, it makes client code unnecessarily verbose: try { for (;;) { item = getNext(r); ... } } catch (RangeEnd e) { } Andrei
Jul 13 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 On 07/12/2010 02:28 PM, bearophile wrote:
 Andrei Alexandrescu:
 sort is all but deprecated, since std.algorithm.sort exists.

 reverse could even more easily be implemented as a library
 function than sort, it should be removed as well.

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#reverse

D site can enjoy a page that lists the deprecated D2 features (and maybe for each of them lists what to use instead of it), so current D2 programmers can avoid what will be removed.

Good point. =20 I'd to do some more renaming around Phobos and figure out an approach t=

 deprecating names that aren't longer used.
=20
 I'm thinking:
=20
 std.conv -> std.conversion
=20
 Rationale: it's a seldom typed name so shortening it is just odd
=20
 std.stdio -> std.io
=20
 Rationale: stuttering sucks.
=20
 put(R, E) -> putNext(R, E)
=20
 Rationale: conveys the notion that there is progress in the output.
=20
 BidirectionalRange -> DoublyEndedRange
=20
 Rationale: bidirectional suggests something that can move *in* either
 direction, whereas in fact the range can be shortened from either end.
=20
 Would this be an improvement?
=20

iota -> sequence Rationale: according to the dictionary, an iota is "an infinitesimal amount" (http://www.merriam-webster.com/dictionary/iota) which has nothing to do with what the function does and can even be argued to mean the reverse! Given the dictionary definition, one would expect iota to represent either an empty range or a range with just one element... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 14 2010
prev sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Monday, July 12, 2010 12:42:49 Andrei Alexandrescu wrote:
 On 07/12/2010 02:28 PM, bearophile wrote:
 Andrei Alexandrescu:
 sort is all but deprecated, since std.algorithm.sort exists.
 
 reverse could even more easily be implemented as a library
 function than sort, it should be removed as well.

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#reverse

D site can enjoy a page that lists the deprecated D2 features (and maybe for each of them lists what to use instead of it), so current D2 programmers can avoid what will be removed.

Good point. I'd to do some more renaming around Phobos and figure out an approach to deprecating names that aren't longer used. I'm thinking: std.conv -> std.conversion Rationale: it's a seldom typed name so shortening it is just odd std.stdio -> std.io Rationale: stuttering sucks. put(R, E) -> putNext(R, E) Rationale: conveys the notion that there is progress in the output. BidirectionalRange -> DoublyEndedRange Rationale: bidirectional suggests something that can move *in* either direction, whereas in fact the range can be shortened from either end. Would this be an improvement? Andrei

Speaking of deprecated (or intended to be deprecated) features, is using opCall() with structs on the list? I recall that scope as storage class is being deprecated, but did opCall() get put on that pile as well? Or is it supposed to stay? It's definitely hard to keep track of what exactly is supposed to be sticking around and what's getting the axe. - Jonathan M Davis
Jul 12 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 12 Jul 2010 14:42:49 -0500, Andrei Alexandrescu wrote:

 I'd to do some more renaming around Phobos and figure out an approach to
 deprecating names that aren't longer used.
 
 I'm thinking:
 
 std.conv -> std.conversion
 
 Rationale: it's a seldom typed name so shortening it is just odd

Yes! :)
 std.stdio -> std.io
 
 Rationale: stuttering sucks.

Oh man, YES!
 put(R, E) -> putNext(R, E)
 
 Rationale: conveys the notion that there is progress in the output.

OK by me, but I've never seen it as a problem.
 BidirectionalRange -> DoublyEndedRange
 
 Rationale: bidirectional suggests something that can move *in* either
 direction, whereas in fact the range can be shortened from either end.

I'd never thought of that, but it's probably a good idea.
 Would this be an improvement?

In summary, yes. :) -Lars
Jul 13 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 12 Jul 2010 15:57:36 -0400, bearophile wrote:

 std.concurrency/std.thread => std.concurrency

std.thread doesn't exist anymore. It was moved into druntime and is now core.thread. (But it is still listed in the Phobos documentation menu as std.thread, which is very confusing.) -Lars
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Jul 2010 19:53:00 -0400, Nick Sabalausky <a a.a> wrote:

 std.metastrings/std.traits => std.meta

I like this a *lot*.

Red flag here -- isn't the proposed keyword to replace __traits meta? If that goes through, meta isn't a valid module name. -Steve
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 12 Jul 2010 15:42:49 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 put(R, E) -> putNext(R, E)

 Rationale: conveys the notion that there is progress in the output.

Can we have E getNext(R) also for completeness :) Then an input range can be defined similarly to an output range (where delegates and ranges that support E get() work). Since put/putNext already establishes the notion of throwing when full, having getNext throwing when empty would be OK, no? -Steve
Jul 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Jul 2010 07:23:53 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Mon, 12 Jul 2010 15:42:49 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 put(R, E) -> putNext(R, E)

 Rationale: conveys the notion that there is progress in the output.

Can we have E getNext(R) also for completeness :) Then an input range can be defined similarly to an output range (where delegates and ranges that support E get() work). Since put/putNext already establishes the notion of throwing when full, having getNext throwing when empty would be OK, no?

Note to self: read all NG posts before posting :) -Steve
Jul 13 2010
prev sibling parent Tim Verweij <tjverweij gmail.com> writes:
--00163628379c6ac1a9048b703a9d
Content-Type: text/plain; charset=ISO-8859-1

On 12 July 2010 21:28, bearophile <bearophileHUGS lycos.com> wrote:

 Andrei Alexandrescu:
 sort is all but deprecated, since std.algorithm.sort exists.

 reverse could even more easily be implemented as a library function


 sort, it should be removed as well.

http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#reverse

D site can enjoy a page that lists the deprecated D2 features (and maybe for each of them lists what to use instead of it), so current D2 programmers can avoid what will be removed.

for newcomers (such as myself). Often I use trail and error alongside the reading of references to learn new languages. If the compiler allows many language constructs/features that are deprecated, it would be very useful to have such a list. Otherwise I'm afraid that I will be writing D2 code that will work today, but will break with a newer more strict version of the compiler when it arrives. Not that I'm planning on writing huge amounts of D2 code right now ;-) but I wouldn't like having to unlearn things later. At least I'd like to keep that to a minimum. Groet, Tim --00163628379c6ac1a9048b703a9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 12 July 2010 21:28, bearophile <span dir=3D"l= tr">&lt;<a href=3D"mailto:bearophileHUGS lycos.com">bearophileHUGS lycos.co= m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le= ft: 1ex;"> Andrei Alexandrescu:<br> <div class=3D"im">&gt; &gt; sort is all but deprecated, since std.algorithm= .sort exists.<br> &gt; &gt;<br> &gt; &gt; reverse could even more easily be implemented as a library functi= on than<br> &gt; &gt; sort, it should be removed as well.<br> &gt;<br> &gt; <a href=3D"http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#= reverse" target=3D"_blank">http://www.digitalmars.com/d/2.0/phobos/std_algo= rithm.html#reverse</a><br> <br> </div>D site can enjoy a page that lists the deprecated D2 features (and<br=

D2 programmers can avoid what will be removed.<br> <br></blockquote><br></div>Yes, please. This is not only useful for current= D2 programmers, but also for newcomers (such as myself). Often I use trail= and error alongside the reading of references to learn new languages. If t= he compiler allows many language constructs/features that are deprecated, i= t would be very useful to have such a list. Otherwise I&#39;m afraid that I= will be writing D2 code that will work today, but will break with a newer = more strict version of the compiler when it arrives. Not that I&#39;m plann= ing on writing huge amounts of D2 code right now ;-) but I wouldn&#39;t lik= e having to unlearn things later. At least I&#39;d like to keep that to a m= inimum.<br> <br>Groet,<br>Tim<br><br> --00163628379c6ac1a9048b703a9d--
Jul 15 2010