Hi there,

just looking at the semantics of the array properties. There are a few points I don't like

.length
I believe, this should be read-only. The asymmetry between upsizing and
downsizing is extremely confusing and will cause all kinds of errors.
Downsizing should, instead, be done by splicing, where you see exactly what
happens, and where it becomes clear, that no data is copied.
Upsizing can be done in several ways. The most straightforward way would be
to create a bigger array and then copy the content. This means two separate
operation, so people will probably cry out over this proposal, but it will
certainly help to avoid many errors and help people to understand how
arrays work.
There just must be an absolutely clear distinction between handling array
pointers and manipulation array contents on the heap.

.sort
This one should be dropped. Sorting is a far too complex task to put it in
the language. There is no way to specify the criteria by which to sort, or
the direction, or the algorithm. Sorting clearly belongs into the library.
Also, this is an operation on the array data and should, therefore not be
displayed as a property of the array pointer. Furthermore, sorting is an
action, so calling it "property" as a bit off.

.reverse
Currently this is an operation on the data as well. I would move it to the
library along with .sort - especially, since calling an action "property"
just seems not right to me, again.

B.t.w: Implementing my suggestion with multidimensional arrays and strides, .reverse could be done on the pointer alone without touching the data. But with multidimensional arrays, the array properties will have to be extended anyway.

Ciao,
Nobbi

> Hi there,
>
> just looking at the semantics of the array properties. There are a few points I don't like
>
> .length
> I believe, this should be read-only. The asymmetry between upsizing and
> downsizing is extremely confusing and will cause all kinds of errors.
> Downsizing should, instead, be done by splicing, where you see exactly what
> happens, and where it becomes clear, that no data is copied.

That's not a bad concept.

> Upsizing can be done in several ways. The most straightforward way would be
> to create a bigger array and then copy the content. This means two separate
> operation, so people will probably cry out over this proposal, but it will
> certainly help to avoid many errors and help people to understand how
> arrays work.
> There just must be an absolutely clear distinction between handling array
> pointers and manipulation array contents on the heap.

There's some merit in what you say, but I confess I am content with the current situation.

> .sort
> This one should be dropped. Sorting is a far too complex task to put it in
> the language. There is no way to specify the criteria by which to sort, or
> the direction, or the algorithm. Sorting clearly belongs into the library.
> Also, this is an operation on the array data and should, therefore not be
> displayed as a property of the array pointer. Furthermore, sorting is an
> action, so calling it "property" as a bit off.

Not sure I agree it should be dropped, but it certainly should not have property syntax.

> .reverse
> Currently this is an operation on the data as well. I would move it to the
> library along with .sort - especially, since calling an action "property"
> just seems not right to me, again.

Shouldn't have property syntax.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote:

> Not sure I agree it should be dropped, but it certainly should not have property syntax.

re: .sort

I think it's nice to have a standard sort that works when you don't need the absolute fastest/smallest/flexiblest algorithm (which is most of the time, unless your profile shows otherwise :-). You can write a small stand- alone program that does not require special libs -- and there's no reason you can't use some other library routine if your needs are special.

And it should have method call syntax :-)

-- 
dave

Dave Sieber wrote:

> "Matthew" <matthew.hat@stlsoft.dot.org> wrote:
> 
>> Not sure I agree it should be dropped, but it certainly should not have property syntax.
> 
> re: .sort
> 
> I think it's nice to have a standard sort that works when you don't need the absolute fastest/smallest/flexiblest algorithm (which is most of the time, unless your profile shows otherwise :-). You can write a small stand- alone program that does not require special libs -- and there's no reason you can't use some other library routine if your needs are special.
> 
> And it should have method call syntax :-)

i.e. "my_array.sort()" ???

Where is the problem with having a

template(T)
void
sort(T[] a) {
        ...
};

somewhere in the library? Of course, you'll need to import that part of the library, but if you start pulling stuff from the library into the language at random just for convenience, then it is rather arbitrary where to stop.

Norbert Nemec <Norbert.Nemec@gmx.de> wrote:

>> And it should have method call syntax :-)
> 
> i.e. "my_array.sort()" ???

Yes, that's method call syntax, as I wrote.

> Where is the problem with having a
> 
> template(T)
> void
> sort(T[] a) {
>         ...
> };

I have no idea, I don't see a problem with it.

-- 
dave

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c6e2jc$1761$1@digitaldaemon.com...
> Dave Sieber wrote:
>
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote:
> >
> >> Not sure I agree it should be dropped, but it certainly should not have property syntax.
> >
> > re: .sort
> >
> > I think it's nice to have a standard sort that works when you don't need the absolute fastest/smallest/flexiblest algorithm (which is most of the time, unless your profile shows otherwise :-). You can write a small stand- alone program that does not require special libs -- and there's no reason you can't use some other library routine if your needs are special.
> >
> > And it should have method call syntax :-)
>
> i.e. "my_array.sort()" ???
>
> Where is the problem with having a
>
> template(T)
> void
> sort(T[] a) {
>         ...
> };

There is no problem.

> somewhere in the library? Of course, you'll need to import that part of the library, but if you start pulling stuff from the library into the language at random just for convenience, then it is rather arbitrary where to stop.

Of course it is arbitrary. As I said before, I don't have a problem with the current state wrt .sort (as long as it loses the property syntax), but I'm not going to get on the soapbox to defend it, because in an absolute sense you are right. It's a tradeoff between such absolute correctness and convenience, and sometimes it's appropriate that convenience wins. This may be one such case, or it may just fall under the bar slightly enough for it not to worry me. :-)