David B. Held wrote:
> Alexander Panek wrote:
>> [...]
>> You have a point, though the beauty & readability of D pretty much nullifies that. The syntax sugar that is added so far does not actually complicate the parsing so much, so D's syntax can still be seen as clean, IMHO.
> 
> I think the ridiculous size of the front-end is a pretty good existence proof.  Take a look, Neal.
> 
> Dave

Posted at 09:42 am? Somebody has a skewed clock :o).

Andrei

Andrei Alexandrescu (See Website For Email) Wrote:
<snip>
> We definitely should get rid of the shameful .sort and .reverse though.

What is shameful about them?

Stewart.

Andrei Alexandrescu (See Website For Email) Wrote:

> David B. Held wrote:
> > Alexander Panek wrote:
> >> [...]
> >> You have a point, though the beauty & readability of D pretty much
> >> nullifies that. The syntax sugar that is added so far does not
> >> actually complicate the parsing so much, so D's syntax can still be
> >> seen as clean, IMHO.
> > 
> > I think the ridiculous size of the front-end is a pretty good existence proof.  Take a look, Neal.
> 
> Take a look at Polyglot. Even Java syntax is heinous to parse.

Oh my!

We all know that D's front end is bad, Java's is heinous, and C++ is starting to become a moral issue (it's just WRONG! you may cry)

That said, I agree with the above.  Arrays should not have a native, non-library sort or reverse "property" that's really a method.  We should and can also bind methods to AA's, or build our own structures that act like AA's and attach methods to them.

Essentially all you need to do is populate the associative array with function*'s.  You may have to dereference them...

Davidl Wrote:

> it's totally not arbitrary.  since AA in D is a container, but we lack of method to operate on it and even more with any resort to add method for it on user land.  So functions as Array Properties in a language with AA is a must.  it looks beautiful, and we can extend our AA with funcs and they work as methods  like way.  it's reasonable.  i used to think in ur way either.  But after u post this, and i consider the AA's func stuff, i finally realize why we don't  get rid of this feature.
<snip top of upside-down reply>

I've never been sure about this feature.  The notation makes it look as though the property is part of the type, when it could be part of the code that's using someone else's type.  This gets more complicated when you try allowing it for structs and classes.

But even sillier is this:

----------
import std.stdio;

class Qwert {
    int yuiop(int[] asdfg) { return asdfg[0]; }

    int hjkl(int[] asdfg) {
        return asdfg.yuiop();
    }
}

void main() {
    Qwert zxcvb = new Qwert;

    writefln(zxcvb.hjkl([3, 4, 5]));
}
----------

Moreover, why is the doc calling them properties, even though it doesn't work without the ()?

Another way that extending basic types could have been implemented is by enhanced typedefs.  For example:

    typedef char[] String {
        char[] toUpper() { ... }
    }

Stewart.

Andrei Alexandrescu (See Website For Email) wrote:
> Posted at 09:42 am? Somebody has a skewed clock :o).

I figure in two weeks my Linux box will fix itself (at least until next year!).

Stewart Gordon wrote:
> Andrei Alexandrescu (See Website For Email) Wrote:
> <snip>
>> We definitely should get rid of the shameful .sort and .reverse though.
> 
> What is shameful about them?

They should be free functions, and sort should also allow a predicate.

Andrei

Andrei Alexandrescu (See Website For Email) Wrote:

> Stewart Gordon wrote:
>> Andrei Alexandrescu (See Website For Email) Wrote:
>>> We definitely should get rid of the shameful .sort and .reverse though.
>> 
>> What is shameful about them?
> 
> They should be free functions,

What do you mean?

> and sort should also allow a predicate.

If you mean a comparator, it's been said already.  But how would getting rid of it fix that problem?

Stewart.

Stewart Gordon wrote:
> Andrei Alexandrescu (See Website For Email) Wrote:
> 
>> Stewart Gordon wrote:
>>> Andrei Alexandrescu (See Website For Email) Wrote:
>>>> We definitely should get rid of the shameful .sort and .reverse though.
>>> What is shameful about them?
>> They should be free functions,
> 
> What do you mean?
> 
>> and sort should also allow a predicate.
> 
> If you mean a comparator, it's been said already.  But how would getting rid of it fix that problem?

The problem is that reverse and sort should be, as in STL, algorithms decoupled from the container they work on.

Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Stewart Gordon wrote:
>> Andrei Alexandrescu (See Website For Email) Wrote:
>> <snip>
>>> We definitely should get rid of the shameful .sort and .reverse though.
>>
>> What is shameful about them?
> 
> They should be free functions, and sort should also allow a predicate.

I agree.  But until then, adding such free functions fortunately does not conflict with the built-in properties so long as the free functions require parameters.  For the record, Tango has a predicate-based sort routine in tango.core.Array.  It currently performs about the same as the built-in routine.


Sean

On Wed, 21 Mar 2007 08:53:07 -0700, Andrei Alexandrescu (See Website For
Email) wrote:

>> So functions as Array Properties in a language with AA is a must.

> We definitely should get rid of the shameful .sort and .reverse though.

... and replace them with more suitable implementations as I'm sure the functionality is in itself useful (i.e. I use it in my code <g>)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
22/03/2007 9:23:09 AM