• Norbert Nemec (32/32) Apr 24 2004 Hi there,
• Matthew (6/32) Apr 24 2004 There's some merit in what you say, but I confess I am content with the ...
• Dave Sieber (10/12) Apr 24 2004 re: .sort
• Norbert Nemec (11/25) Apr 24 2004 i.e. "my_array.sort()" ???
• Dave Sieber (5/15) Apr 24 2004 I have no idea, I don't see a problem with it.
• Matthew (9/34) Apr 24 2004 There is no problem.

Norbert Nemec <Norbert.Nemec gmx.de> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

 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.

Dave Sieber <dsieber spamnot.sbcglobal.net> writes:

"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

Norbert Nemec <Norbert.Nemec gmx.de> writes:

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.

Dave Sieber <dsieber spamnot.sbcglobal.net> writes:

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

"Matthew" <matthew.hat stlsoft.dot.org> writes:

"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. :-)