• Bill Baxter (8/8) Jul 28 2009 One more thing I'd like to mention regarding properties.
• KennyTM~ (2/13) Jul 28 2009 Better they should be functions in the standard library.
• Moritz Warning (3/14) Jul 29 2009 They should go into a library.
• bearophile (17/19) Jul 29 2009 Because they are (supposed to be) handy. You don't want to add imports a...
• bearophile (11/12) Jul 29 2009 My last post may lead people to misunderstand what I think, so I add a c...
• Bill Baxter (7/24) Jul 29 2009 Even if these things exist, they should still be written in D. It
• language_fan (11/27) Jul 29 2009 The idea behind built-in features like AAs or arrays (and operations on

Bill Baxter <wbaxter gmail.com> writes:

One more thing I'd like to mention regarding properties.

It has long annoyed me that .sort and .reverse are functions, but
CANNOT be called like functions.
So even if I'd like to make a distinction between properties and
functions in my usage, I cannot with those two.  We should fix that.

I think they may both be headed for the chopping block, but if not we
should fix em.

--bb

KennyTM~ <kennytm gmail.com> writes:

Bill Baxter wrote:
 One more thing I'd like to mention regarding properties.
 
 It has long annoyed me that .sort and .reverse are functions, but
 CANNOT be called like functions.
 So even if I'd like to make a distinction between properties and
 functions in my usage, I cannot with those two.  We should fix that.
 
 I think they may both be headed for the chopping block, but if not we
 should fix em.
 
 --bb

Better they should be functions in the standard library.

Moritz Warning <moritzwarning web.de> writes:

On Tue, 28 Jul 2009 16:46:51 -0700, Bill Baxter wrote:

 One more thing I'd like to mention regarding properties.
 
 It has long annoyed me that .sort and .reverse are functions, but CANNOT
 be called like functions.
 So even if I'd like to make a distinction between properties and
 functions in my usage, I cannot with those two.  We should fix that.
 
 I think they may both be headed for the chopping block, but if not we
 should fix em.
 
 --bb

They should go into a library.
I wonder why they ended up in the language anyway..

bearophile <bearophileHUGS lycos.com> writes:

Moritz Warning:
 They should go into a library.
 I wonder why they ended up in the language anyway..

Because they are (supposed to be) handy. You don't want to add imports and
remember where to import from, if you want to write a 10-lines long program.
Such kind of programs are common enough in dynamic languages.
Another small advantage is that you avoid template bloat that comes from using
such functions tanen from a std lib made of function templates over different
kind of arrays.

But after seeing how slow the built-in sort is, and seeing how it doesn't
accept a "key" mapping function, I think moving sort in the std-lib may be
better.

- I'd like to keep reverse as a property, because it's a common operation and
because there's only one way to implement it well.
- Beside the reverse, I'd like to add few more standard methods to arrays:
- mul, to multiply a char/array n times.
- find (find position of an item)
- opIn_r (tell if a given item is present)
- count (count how many copies of a given item are present)
- remove (remove first instance of an item)
- delete (remove i-th item)
- insert (insert item before index)
- Maybe "pop()" too may be useful, it's like delete, but it also returns it.
Default is the last item.

I presume Andrei will not like such suggestions (that I have written here in
one of my first lists of things, lot of time ago).

Bye,
bearophile

bearophile <bearophileHUGS lycos.com> writes:

 Because they are (supposed to be) handy. You don't want to add imports and
remember where to import from, if you want to write a 10-lines long program.
Such kind of programs are common enough in dynamic languages.<

My last post may lead people to misunderstand what I think, so I add a
clarification here.

There are two important differences:
- In those dynamic languages you usually don't have the *freedom* to write
those functions in the same language, you typically must write them in C to
have enough performance.
- D arrays (and in future probably more things) allow a syntax
array.functioname() that leads to the same syntax as array methods.
- D2 manages well groups of overloads coming from different modules.

So in the end the only problems are:
- some template bloat coming from using function templates.
- finding and adding the right imports.
- having a well designed std library that contains names like ones I have
listed.

Bye,
bearophile

Bill Baxter <wbaxter gmail.com> writes:

On Wed, Jul 29, 2009 at 5:02 AM, bearophile<bearophileHUGS lycos.com> wrote:
 Moritz Warning:
 They should go into a library.
 I wonder why they ended up in the language anyway..

 Because they are (supposed to be) handy. You don't want to add imports and
remember where to import from, if you want to write a 10-lines long program.
Such kind of programs are common enough in dynamic languages.
 Another small advantage is that you avoid template bloat that comes from using
such functions tanen from a std lib made of function templates over different
kind of arrays.

 But after seeing how slow the built-in sort is, and seeing how it doesn't
accept a "key" mapping function, I think moving sort in the std-lib may be
better.

 - I'd like to keep reverse as a property, because it's a common operation and
because there's only one way to implement it well.
 - Beside the reverse, I'd like to add few more standard methods to arrays:
 - mul, to multiply a char/array n times.
 - find (find position of an item)
 - opIn_r (tell if a given item is present)
 - count (count how many copies of a given item are present)
 - remove (remove first instance of an item)
 - delete (remove i-th item)
 - insert (insert item before index)
 - Maybe "pop()" too may be useful, it's like delete, but it also returns it.
Default is the last item.

 I presume Andrei will not like such suggestions (that I have written here in
one of my first lists of things, lot of time ago).

Even if these things exist, they should still be written in D.  It
doesn't seem right to burden compiler writers with the task of writing
such library-ish functions.  If the importing thing is a problem (and
I tend to agree that it is) then they should be imported automatically
in std.object.

--bb

language_fan <foo bar.com.invalid> writes:

Wed, 29 Jul 2009 11:46:53 +0000, Moritz Warning thusly wrote:

 On Tue, 28 Jul 2009 16:46:51 -0700, Bill Baxter wrote:
 
 One more thing I'd like to mention regarding properties.
 
 It has long annoyed me that .sort and .reverse are functions, but
 CANNOT be called like functions.
 So even if I'd like to make a distinction between properties and
 functions in my usage, I cannot with those two.  We should fix that.
 
 I think they may both be headed for the chopping block, but if not we
 should fix em.
 
 --bb

 
 They should go into a library.
 I wonder why they ended up in the language anyway..

The idea behind built-in features like AAs or arrays (and operations on 
them) is that the compiler can use clever optimizations to make them 
faster than equivalent library provided containers (similar things 
happened years ago when records and ZF expressions were added to 
languages).

Another fact is that if you have a built-in syntax for some containers, 
it's rather easy to overload the syntax with for instance custom HashMaps 
and TreeMaps and transparently replace the built-in ones with these - I'm 
sure that there must be projects that take advantage of these properties 
of D.