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