This got me thinking...  Every object is derived from a common base object, as in Java.  As long as D includes RTTI (run-time type ID), we can maybe replace STL-style generic programming with something like

class Stack
{
    Object[] stk;
    ...
}

Then, since every object is a reference (and every reference is of identical size), we could maybe say something like:

Stack.push_list( [ 3, "Str", 8-7.9384i, new Widget( ) ] );

(I'm assuming that push_list(obj [] ) pushes the contents of the list, not a
ref to the list.)

Unfortunately, this can waste a lot of space; suppose you wanted a stack of 'N' ascii's / chars; you'd have to have type info for each one of them!  For this reason we should maybe add a syntax for specifying a substitution (?) of Object with int's--for example--for a particular instance of the generic type.  But if the stack, etc are defined for all native types (a daunting task) in the D library, then maybe the Object[] approach is sufficient for less common generics.

Reactions?



> class  _STLVirtual
> {
>     protected :
>         _STLVirtual ();
>
>     public   :
>         virtual        add    ( .. )    = 0;
>         virtual        erase    ( ... )    = 0;
>         virtual        begin    ( ... )    = 0;
>         virtual        end        ( ... )    = 0;
>
>         // ...
> };

The system you talk about is exactly how Java works.  The main issues with it are lack of speed and lack of type-safety.

The C++ advocates will yell at you for this, because you have to downcast to
your expected type (speed), and you can basically put anything into this
stack (type-safety).

When I left the Java scene about 1.5 years ago, there was talk of specialized types, or generic collections or something of that nature, don't know what has happened to it since...

In Java, there is no way of creating a type-safe container.  That's because there is no way of specifying generic code ala C++ templates, and that is the crux of the whole template discussion currently raging on this newsgroup (fun stuff :))

In C++, there is no way of writing the Java equivalent of the class you describe, because there is no root class for all classes (such a pity). (Ok, you can make a mix-in class using multiple inheritance, but that's pretty ugly, and there is no standard for it).

I hope D can make some progress in alleviating these two situations, as Java's method is definitely better for some things, and C++'s is better for others.  Having to be tied down to one or another simply by choice of language is distressing.

-t

"Brent Schartung" <bschartung@home.com> wrote in message news:9lp22q$2cq4$1@digitaldaemon.com...
> This got me thinking...  Every object is derived from a common base
object,
> as in Java.  As long as D includes RTTI (run-time type ID), we can maybe replace STL-style generic programming with something like
>
> class Stack
> {
>     Object[] stk;
>     ...
> }
>
> Then, since every object is a reference (and every reference is of
identical
> size), we could maybe say something like:
>
> Stack.push_list( [ 3, "Str", 8-7.9384i, new Widget( ) ] );
>
> (I'm assuming that push_list(obj [] ) pushes the contents of the list, not
a
> ref to the list.)
>
> Unfortunately, this can waste a lot of space; suppose you wanted a stack
of
> 'N' ascii's / chars; you'd have to have type info for each one of them!
For
> this reason we should maybe add a syntax for specifying a substitution (?) of Object with int's--for example--for a particular instance of the
generic
> type.  But if the stack, etc are defined for all native types (a daunting task) in the D library, then maybe the Object[] approach is sufficient for less common generics.
>
> Reactions?
>
>
>
> > class  _STLVirtual
> > {
> >     protected :
> >         _STLVirtual ();
> >
> >     public   :
> >         virtual        add    ( .. )    = 0;
> >         virtual        erase    ( ... )    = 0;
> >         virtual        begin    ( ... )    = 0;
> >         virtual        end        ( ... )    = 0;
> >
> >         // ...
> > };
>
>
>

> I read somewhere that there is being thought about integrating templates
and
> possibly STL... However, I personally think STL has a couple of design
mistakes.
> 1.    The interface is not the same for all collections.

Nor should it be in my opinion.  Every collection that could reasonably support [] access does.  Every container that could reasonably support push_back() does.  To try to design your containers so that they can be used with no understanding of how they work is a mistake IMO.

Further, the user of a function that takes a collection could innocently pass in a collection without realizing the function works totally innappropriately with it.  Hey it compiles right?  And it would work until you ran the program with a slightly larger dataset and it ground to a halt.

> 2.    There is no way to chose for compile time or runtime polyphormism.
All it can
> do now is compile time polyphormism which basically leaves the root of the
original
> C++ with runtime polyphormism...

I'll take every thing at compile time I can possibly get.  I'd like the program defined the minute I put fingers to keyboard.  Not years from now when it's run.


Angus Graham

> In C++, there is no way of writing the Java equivalent of the class you describe, because there is no root class for all classes (such a pity). (Ok, you can make a mix-in class using multiple inheritance, but that's pretty ugly, and there is no standard for it).

Sure there's a root for all C++ classes:  void.
As a good programmer you wouldn't consider stuffing your containers with
void* pointers to various classes, then trying to determine what they are
when you take them out.  But that's just what you're talking about when you
fill containers with base classes and use RTTI to get them out.

Angus Graham

Angus Graham wrote:

> To try to design your containers so that they can be used with no understanding of how they work is a mistake IMO.

You think that does not happen with the current design? <g>

Trying to design containers in such a way that using them is equal is great in IMHO. That way when the 'demand' to the container changes because of functional changes to the code one could much easier change the type of container without having to go through numerous sources files to change the container access everywhere.

> Further, the user of a function that takes a collection could innocently pass in a collection without realizing the function works totally innappropriately with it.  Hey it compiles right?  And it would work until you ran the program with a slightly larger dataset and it ground to a halt.

The user can do the exact same thing with a function template...

template < class C > DoSomethingWithContainer ( C  &coll )
{
    for ( C :: iterator  i = coll.begin () ; i != coll.end () ; i++ )
        // whatever.
}

Of course when every container would have a [] operator it could happen that
when used wrongly accessing the contents through it would be very heavy on the
CPU... Well, don't you think users are using for ( begin (), end () ) on map's
to do a reverse lookup at all??? <g>

> > 2.    There is no way to chose for compile time or runtime polyphormism.
> All it can
> > do now is compile time polyphormism which basically leaves the root of the
> original
> > C++ with runtime polyphormism...
>
> I'll take every thing at compile time I can possibly get.  I'd like the program defined the minute I put fingers to keyboard.  Not years from now when it's run.

Sure, but at times it might be nice to be able to get/use run time polyphormism. This is not even an option now.

Jan

Well, ( void * ) would be very rough... (I indeed would rather use a base class
in that case), but hey... Why not???

I stand corrected (2x) :)  I was thinking of base classes.

-t

"Jan Knepper" <jan@smartsoft.cc> wrote in message news:3B8170AD.C4EB3053@smartsoft.cc...
> Well, ( void * ) would be very rough... (I indeed would rather use a base
class
> in that case), but hey... Why not???
>
>

Walter wrote:
> Tim Sweeney wrote in message <9lno18$1kmb$1@digitaldaemon.com>...
> 
>>Witness that when STL is translated to a language with a more flexible type system (such as Haskell), it basically "disappears"
>>into much simpler native language functionality -- and you realize
>>that half of STL consists of workarounds for C++ limitations, while the other half consists of workarounds for STL's limitations.
>>STL-like techniques have no place whatsoever in a cleanly designed
>>language.
> 
> I'm very interested in hearing more about this.
> 

I can't speak to Haskell.  It has a type inference system that I don't understand, but the sturcture of container classes is tremendously sensitive to the structure of the language.  Look at Ada component classes, Java component classes, Eiffel component classes.  Each is highly different from the other, and all are different from the STL, even though several of them were designed with full knowledge of the STL's existence, and also knowledge that STL aware programmers were a large segment of the folk they were trying to recruit.

Expect that D will use a different structure.  If it's better than C++, if it has a different structure for the template classes (or replaces them with generics), it will.  I couldn't tell you just how it will differ.  For one thing, it's not deterministic.  Eiffel has at least 3 major variants, but nobody's been able to do a direct translation.

> I can't speak to Haskell.  It has a type inference system that I don't understand, but the sturcture of container classes is tremendously sensitive to the structure of the language.  Look at Ada component classes, Java component classes, Eiffel component classes.  Each is highly different from the other, and all are different from the STL, even though several of them were designed with full knowledge of the STL's existence, and also knowledge that STL aware programmers were a large segment of the folk they were trying to recruit.

Stepanov wrote the STL for Ada first.  IIRC from Stroustrup's "D&E of C++", C++ STL is 1/10 the klocs of Ada's.


Angus Graham

Whoa, say that last sentence ten times fast.

Angus Graham wrote:
>...
> 
> Stepanov wrote the STL for Ada first.  IIRC from Stroustrup's "D&E of C++",
> C++ STL is 1/10 the klocs of Ada's.
> 
> 
> Angus Graham
> 
> Whoa, say that last sentence ten times fast.
> 
I haven't seen that, but you can do nearly anything in Ada if you work hard enough at it.  Still, a factor of 1:10 certainly implies that it's a much better fit to C++.