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
next sibling parent reply "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
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 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 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 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 "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 reply "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
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 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:
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.


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


o

 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


	You can also add:
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 Tim Verweij <tjverweij gmail.com> writes:
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




 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.


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 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
Jul 15 2010
prev sibling parent reply eris <jvburnes gmail.com> writes:
Andrei Alexandrescu Wrote:


 std.stdio -> std.io
 
 Rationale: stuttering sucks.
 


Absolutely.


 BidirectionalRange -> DoublyEndedRange
 
 Rationale: bidirectional suggests something that can move *in* either 
 direction, whereas in fact the range can be shortened from either end.


It's an improvement, but I believe the proper English prefix for something that
is doubly-reflective in that sense is "Duplex".  It's also easier and shorter
to pronounce.  Say it with me now:

"DuplexRange"

Keep up the awesome work Andre.

BTW: D really needs some promotional work.  Would there be any chance that you
or Walter could give a talk at Google?  A short presentation with a list of
topics that could improve D would be great as a way to get Google Summer of
Code resources allocated.
Jul 13 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 07/13/2010 11:30 AM, eris wrote:

 Andrei Alexandrescu Wrote:


 std.stdio ->  std.io

 Rationale: stuttering sucks.


 Absolutely.


 BidirectionalRange ->  DoublyEndedRange

 Rationale: bidirectional suggests something that can move *in*
 either direction, whereas in fact the range can be shortened from
 either end.


 It's an improvement, but I believe the proper English prefix for
 something that is doubly-reflective in that sense is "Duplex".  It's
 also easier and shorter to pronounce.  Say it with me now:

 "DuplexRange"

 Keep up the awesome work Andre.

 BTW: D really needs some promotional work.  Would there be any chance
 that you or Walter could give a talk at Google?  A short presentation
 with a list of topics that could improve D would be great as a way to
 get Google Summer of Code resources allocated.


Google invited me for a talk via Benjamin Shropshire (thanks!). I am 
waiting for my manager's approval.

Andrei
Jul 13 2010
prev sibling next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Jul 14, 10 00:30, eris wrote:

 Andrei Alexandrescu Wrote:


 std.stdio ->  std.io

 Rationale: stuttering sucks.


 Absolutely.


 BidirectionalRange ->  DoublyEndedRange

 Rationale: bidirectional suggests something that can move *in* either
 direction, whereas in fact the range can be shortened from either end.


 It's an improvement, but I believe the proper English prefix for something
that is doubly-reflective in that sense is "Duplex".  It's also easier and
shorter to pronounce.  Say it with me now:

 "DuplexRange"


[bikeshed]
When one say "duplex" it's usually associated with telecommunication 
(half-duplex/full-duplex) or printing (duplex = two-sided).

And usually it's called "Double-ended" (as in Double-ended queue), not 
Doubly ended.
[/bikeshed]


 Keep up the awesome work Andre.

 BTW: D really needs some promotional work.  Would there be any chance that you
or Walter could give a talk at Google?  A short presentation with a list of
topics that could improve D would be great as a way to get Google Summer of
Code resources allocated.
Jul 13 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"eris" <jvburnes gmail.com> wrote in message 
news:i1i4bs$1c0e$1 digitalmars.com...

 It's an improvement, but I believe the proper English prefix for something 
 that is doubly-reflective in that sense is "Duplex".  It's also easier and 
 shorter to pronounce.  Say it with me now:

 "DuplexRange"


I'm a native Englsh speaker, and if I saw something called "DuplexRange", my 
first thought would be "Wait, is that full-duplex or half-duplex?" But maybe 
that's just me :)
Jul 13 2010
parent reply eris <jvburnes gmail.com> writes:
Nick Sabalausky Wrote:


 "eris" <jvburnes gmail.com> wrote in message 
 news:i1i4bs$1c0e$1 digitalmars.com...

 It's an improvement, but I believe the proper English prefix for something 
 that is doubly-reflective in that sense is "Duplex".  It's also easier and 
 shorter to pronounce.  Say it with me now:

 "DuplexRange"


 
 I'm a native Englsh speaker, and if I saw something called "DuplexRange", my 
 first thought would be "Wait, is that full-duplex or half-duplex?" But maybe 
 that's just me :)
 


Well everyone is going to have an opinion based on the usage of "Duplex" they
are most familiar with.  Full duplex is actually redundant.  Duplex means
double.  Half-Duplex ironically just means single or more properly simplex.

Duplex in comms means double ended communications or a communications channel
that supports simultaneous communications in both directions.

Duplex in printing means printing from both sides.

I was just suggesting a neat and tidy term that when combined with Range means
double-ended range.

If this is not what is meant then by all means suggest a more proper term for
double-ended or double sided.  Could be there is a better term than any of
those.

eris
Jul 13 2010
parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 13/07/2010 20:26, eris wrote:

 Nick Sabalausky Wrote:


 "eris"<jvburnes gmail.com>  wrote in message
 news:i1i4bs$1c0e$1 digitalmars.com...

 It's an improvement, but I believe the proper English prefix for something
 that is doubly-reflective in that sense is "Duplex".  It's also easier and
 shorter to pronounce.  Say it with me now:

 "DuplexRange"


 I'm a native Englsh speaker, and if I saw something called "DuplexRange", my
 first thought would be "Wait, is that full-duplex or half-duplex?" But maybe
 that's just me :)


 Well everyone is going to have an opinion based on the usage of "Duplex" they
are most familiar with.  Full duplex is actually redundant.  Duplex means
double.  Half-Duplex ironically just means single or more properly simplex.

 Duplex in comms means double ended communications or a communications channel
that supports simultaneous communications in both directions.

 Duplex in printing means printing from both sides.

 I was just suggesting a neat and tidy term that when combined with Range means
double-ended range.

 If this is not what is meant then by all means suggest a more proper term for
double-ended or double sided.  Could be there is a better term than any of
those.

 eris


To me, Half-Duplex != Simplex, as the former is two-way, but not 
simultaneously, as opposed to just single direction, but anyway...

DuplexRange.vote++;

A...
Jul 14 2010
parent =?iso-8859-2?B?VG9tZWsgU293afFza2k=?= <just ask.me> writes:
Dnia 14-07-2010 o 13:32:44 Alix Pexton <alix.DOT.pexton gmail.dot.com>  =

napisa=B3(a):


 DuplexRange.vote++;


++vote

And it's already used for with similar meaning:
...can communicate with one another in both directions.
http://en.wikipedia.org/wiki/Duplex_(telecommunications)

Tomek
Jul 23 2010