I think the idea is that Vector will somehow allow values of variable type, whereas arrays use fixed types.  Its also the one remaining reason I could see for a Map class, if Map could be a subsclass of Vector that uses variable typed keys.

-C. Sauls
-Invironz

Automatic resizing ?

C

On Sat, 20 Mar 2004 11:30:40 -0500, Ben Hinkle <bhinkle4@juno.com> wrote:

> On Sat, 20 Mar 2004 06:51:24 -0000, "Matthew" <matthew@stlsoft.org>
> wrote:
>
>>> What is the equivalent of Java's Vector in D?
>>
>> The DTL's Vector!! :)
>
> I should probably wait until DTL is more baked, but...
> why have a Vector class when we have dynamic arrays
> in D already? Unless there are really good reasons
> to have one we should avoid making a Vector class.
>
> I can imagine a couple of possible reasons for Vector:
> 1) Vector subclasses some abstract list class or
>    interface
> 2) Vector would use iterator classes to be consistent
>    with other classes in DTL
>
> Without seeing DTL it's kindof hard to imagine
> satisfying 1 and 2 with "pure" dynamic arrays but
> I really hope we don't just add a Vector class
> because Java/C++ have one in their collections API.
>
> -Ben



-- 
D Newsgroup.

"C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:c3hk8r$boj$1@digitaldaemon.com...
> Hey don't worry about it, isn't that why we have this NG?  :)  Besides, you at least proved it can be done... good news to anybody who actually comes up with a need for a map-like object down the road.  Keep your code laying around somewhere.

Of course. It's in version control

> Oh, and I wanna add my begging for the preview release.  :)

As soon as I hear from big-W

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:ggro5099etn7cu5i6c3skaairgvi7u25ib@4ax.com...
> On Sat, 20 Mar 2004 06:51:24 -0000, "Matthew" <matthew@stlsoft.org> wrote:
>
> >> What is the equivalent of Java's Vector in D?
> >
> >The DTL's Vector!! :)
>
> I should probably wait until DTL is more baked, but...
> why have a Vector class when we have dynamic arrays
> in D already?

1. The length and capacity are clearly distinguished.
2. The containers will be bolt-ins (see
the other thread in which I talk about this "popular" technique), to allow
them to subclass abstract container interfaces, or abstract classes, or
whatever you want/think appropriate, so that they can work with more
flexible
inheritance-based/runtime-polymorphic code just as well as with more
efficient/type-safe generic code.
3. They will all work with Ranges. Alas this is all still well up in the
blue-skies as far as D goes. I've pretty much got it all worked out for C++,
along with John Torjo - I've been doing the concepts and the abstractions,
and John's been doing some mind bending things with filters. I *know* it
will
work for D because I worked it out on a bike ride a couple of weeks ago,
but I forgot it again before I could get to some paper, so it's a case of
arsing
around in code, or doing something else, until the code pixie comes by and
whispers it in my ear again. <G>

(Please don't be concerned if this sounds like the ravings of a madman: I
get the
majority of my ideas in this way, and they often tantalise me from afar for
days/weeks
before I can crystalise them onto paper.)

> Unless there are really good reasons
> to have one we should avoid making a Vector class.
>
> I can imagine a couple of possible reasons for Vector:
> 1) Vector subclasses some abstract list class or
>    interface

That will be possible, via the bolt-in mechanism

> 2) Vector would use iterator classes to be consistent
>    with other classes in DTL

DTL classes will all work with algorithms and built-in language features in
the form
of ranges/slices, rather than STL-like iterators.

FYI, I'm going to try and complete the C++ Ranges stuff (for STLSoft; JT's
doing a Boost version) before, so the concept's are clear, and then the D
Range
stuff should seem a lot clearer (if only because there'll be something
concrete and
proven to which people (including me) can refer).

But we should have no issue using the DTL stuff thus far without any concern of Ranges, so I'll try and do the bolt-in stuff and post it shortly.

> Without seeing DTL it's kindof hard to imagine
> satisfying 1 and 2 with "pure" dynamic arrays but
> I really hope we don't just add a Vector class
> because Java/C++ have one in their collections API.

Not in the least.

Matthew wrote:

>There's also an IntRange, which I mentioned in a recent post will support a
>relativelt succint syntax
>
>    foreach(int i; new IntRange(-20, +20, 2))
>    {
>        . . .
>    }
>
>This'll be turned into a template soon so that it will work with any
>integral type.
>
Wouldn't this be neater in a free function ie:

   foreach(int i; range(-20, +20, 2))
   {
       . . .
   }

or do you plan to do that?

-- 
-Anderson: http://badmama.com.au/~anderson/

I'm not sure what you mean. Arrays can only contain monomorphic types by value, but can contain polymorphic types by reference. Vector!() is the same, partly because it's implemented in terms of the built-in arrays.

"C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:c3hsn1$r04$1@digitaldaemon.com...
> I think the idea is that Vector will somehow allow values of variable type, whereas arrays use fixed types.  Its also the one remaining reason I could see for a Map class, if Map could be a subsclass of Vector that uses variable typed keys.
>
> -C. Sauls
> -Invironz

On Sat, 20 Mar 2004 17:52:48 -0000, "Matthew" <matthew@stlsoft.org> wrote:

>
>"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:ggro5099etn7cu5i6c3skaairgvi7u25ib@4ax.com...
>> On Sat, 20 Mar 2004 06:51:24 -0000, "Matthew" <matthew@stlsoft.org> wrote:
>>
>> >> What is the equivalent of Java's Vector in D?
>> >
>> >The DTL's Vector!! :)
>>
>> I should probably wait until DTL is more baked, but...
>> why have a Vector class when we have dynamic arrays
>> in D already?
>
>1. The length and capacity are clearly distinguished.

The capacity of dynamic arrays is a pretty hot topic and there are several possible ways to support capacity without making a Vector class.

>2. The containers will be bolt-ins (see
>the other thread in which I talk about this "popular" technique), to allow
>them to subclass abstract container interfaces, or abstract classes, or
>whatever you want/think appropriate, so that they can work with more
>flexible
>inheritance-based/runtime-polymorphic code just as well as with more
>efficient/type-safe generic code.

I'm trying to dig up those posts but I'm having trouble finding them... oh well. I'll wait for DTL.

>3. They will all work with Ranges. Alas this is all still well up in the
>blue-skies as far as D goes. I've pretty much got it all worked out for C++,
>along with John Torjo - I've been doing the concepts and the abstractions,
>and John's been doing some mind bending things with filters. I *know* it
>will
>work for D because I worked it out on a bike ride a couple of weeks ago,
>but I forgot it again before I could get to some paper, so it's a case of
>arsing
>around in code, or doing something else, until the code pixie comes by and
>whispers it in my ear again. <G>
>
>(Please don't be concerned if this sounds like the ravings of a madman: I
>get the
>majority of my ideas in this way, and they often tantalise me from afar for
>days/weeks
>before I can crystalise them onto paper.)

no problem. I know what you mean. I'll wait for more details.

>> Unless there are really good reasons
>> to have one we should avoid making a Vector class.
>>
>> I can imagine a couple of possible reasons for Vector:
>> 1) Vector subclasses some abstract list class or
>>    interface
>
>That will be possible, via the bolt-in mechanism
>
>> 2) Vector would use iterator classes to be consistent
>>    with other classes in DTL
>
>DTL classes will all work with algorithms and built-in language features in the form of ranges/slices, rather than STL-like iterators.

cool!

>FYI, I'm going to try and complete the C++ Ranges stuff (for STLSoft; JT's
>doing a Boost version) before, so the concept's are clear, and then the D
>Range stuff should seem a lot clearer (if only because there'll be something
>concrete and proven to which people (including me) can refer).
>
>But we should have no issue using the DTL stuff thus far without any concern of Ranges, so I'll try and do the bolt-in stuff and post it shortly.

ok.

>> Without seeing DTL it's kindof hard to imagine
>> satisfying 1 and 2 with "pure" dynamic arrays but
>> I really hope we don't just add a Vector class
>> because Java/C++ have one in their collections API.
>
>Not in the least.

yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.

-Ben

I haven't done much D yet, but...
Aren't the typedefs like map_t.key_type and map_t.value_type good for
generic programming, instead of hardcoding types using the built in arrays?
Or can you figure them out in a template which takes the assoc array's type
as a parameter?

> >> What is the equivalent of Java's Vector in D?
> >
> >     Note that the Map's foreach returns key&value pairs, which the
built-in
> > assoc arrays do not, so we get to do this:
> >
> >
> >    Map!(int, int).Map    m;
> >    . . .
> >    foreach(map_t.pair_type p; m)
> >    {
> >        printf("[%d]: %d ", p.key, p.value);
> >    }
>
> they do, no need for that.
>
> int[int] m;
> . . .
> foreach(int key, int value ; m)
> {
> printf("[%d] %d\n", key, value);
> }
>
>
> I fail to see the necessity of Map at all...

> I'll wait to see.
>
> >    foreach(int i; new IntRange(-20, +20, 2))
>     foreach(int i; Range!(int)(-20, +20, 2))
>
> why is this better then:
>
>      for(int i=-20; i<20 ; i+=2)
>
>
>
> Ant

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c3i172$12o2$2@digitaldaemon.com...
> Matthew wrote:
>
> >There's also an IntRange, which I mentioned in a recent post will support
a
> >relativelt succint syntax
> >
> >    foreach(int i; new IntRange(-20, +20, 2))
> >    {
> >        . . .
> >    }
> >
> >This'll be turned into a template soon so that it will work with any integral type.
> >
> Wouldn't this be neater in a free function ie:
>
>     foreach(int i; range(-20, +20, 2))
>     {
>         . . .
>     }
>
> or do you plan to do that?

Indeed. That's one option, and I've now done it. But because D does not support implicit template instantiation, we'd either have to be satisfied with just one (int), or one of a small set (one integral, one floating point, etc.), as in:

    IntegralRange!(int).Range range(int from, int to, int inc)
    {
        return new IntegralRange!(int).Range(from, to, inc);
    }

    FloatingRange!(double) range(double from, ...)
    {
        return new FloatingRange!(double)(from, to, inc);
    }

and rely on the user to specify integers or floating points to help the compiler disambiguate, as in:

 foreach(int i; range(0, 10, +1))
 {
  printf("%d ", i);
 }

 foreach(int i; range(0.0, 10.0, +1.0))
 {
  printf("%d ", i);
 }

This is not really a bad solution, since one would always be free to use explicit ranges for other types, as in

 foreach(int i; IntegralRange!(long).range(0, 10, +1))
 {
  printf("%d ", i);
 }


I've also got several half finished thoughts about how we might somehow get these things integrated into the language, but as I say, they're only half-finished (probably half-baked). And since the int and double forms would serve the vast majority of cases, it's probably best left unemcumbered.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:sknp50lk1tbov9fhefoiflqin8ihr6bpkd@4ax.com...
> yeah, I shouldn't have said "just because Java/C++ have one"... It's natural to want to add one, just as it is natural to want to add a String class of some sort. I really hope we can keep 90% of D code using dynamic arrays - no offense to Vector but multiple ways to do very similar things is a pain in the butt when writing APIs.

One point I tried to make in my sdwest talk was I just did not like having arrays, Vectors, and Strings as separate types. They really should be the same thing, and it was a significant design goal of D to make them the same (i.e., add sufficient power to arrays).

You're right, though, that people coming from Java/C++ will look for a String or Vector and initially wonder why it isn't there. I'd like the collection classes in DTL to be more advanced things than what really ought to be in the core language. I think we can show, using DTL, that D is more expressive with far less code than C++ STL.

Anyone want to throw out ideas on collection types that would be cool in DTL?