July 22, 2004
I agree with you Berin :-)

If Ben can wrap an interface on top of the concrete implementation (where it makes sense), then that's what I would personally use from a client perspective (it feels more 'solid' than an alias to me). It's what I try to expose from within my libraries too; for the reason you state, but also so that others might plug in a concurrent alternative.

Regarding performance: runtime overhead for Interface dispatching is minimal in Walters implementation, but the casting to and from a concrete implementation is not. I imagine (hope) this is just a question of compiler maturity rather than a language design issue.

- Kris

"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:cdmmvk$1mf$1@digitaldaemon.com...
> Ben Hinkle wrote:
> >
> > True. The runtime dispatching of Java's library is nice - though it does mean the performance might not be as good as compile-time binding. The
use
> > case you are talking about (protecting oneself from choosing a
collection
> > type too early in the development process) can be avoided by making up
an
> > alias. For example define
> >  alias vector MyCollectionAlias;
> > Then instead of using vector<Coord> everywhere you can use
> > MyCollectionAlias<Coord>. If the time comes when you want to use a
linked
> > list instead of a vector you only have to change the alias definition
and
> > recompile. Writing libraries might be more scary, though, unless one can modify and recompile the library. Anyhow, there are trade-offs in either direction.
>
> I'm playing devil's advocate here for a moment.  Please bear with me, while I have extensive programming experience, I am new to D.
>
> Since I write a lot of code that is designed to be used as a library, and backwards compatibility is very important to me, what would be the impact of using an interface?
>
> The reason I say that is because the following two methods are functionally equivalent, but not syntactically equivalent:
>
> vector<Coord>      getPolygon()
> linked_list<Coord> getPolygon()
>
> If I found that the linked_list worked better for me after I already released the library I would have to choose between breaking backwards compatibility or living with the deficiencies the other collection had. Array backed lists and linked lists are best suited to different types of interaction, so you can't just say there should be only one type of list.
>
> Now, if I were able to use an interface, I would be free to make the change without breaking binary compatibility with any software already installed on the system.  I would also be able to enjoy the boost in performance that would arguably be orders of magnitude better than runtime dispatching vs. compiletime dispatching.
>
> I think this is about as best an argument as I can muster supporting interfaces for the collections.
>
> Within an application, one can always use the implementations directly (in many cases that's what happens), so they still have the advantage of compiletime binding where they need it.  With a library the goals are interoperability so the interfaces make more sense to manage potential change.
>
> Does that make sense, or am I just blowing wind here?  If I'm blowing wind, I'll stop now.


July 22, 2004
Kris wrote:

> I agree with you Berin :-)
> 
> If Ben can wrap an interface on top of the concrete implementation (where it makes sense), then that's what I would personally use from a client perspective (it feels more 'solid' than an alias to me). It's what I try to expose from within my libraries too; for the reason you state, but also so that others might plug in a concurrent alternative.

The concurrent versions of a queue, for example, has been in the back of my mind and is an argument for interfaces. I have a feeling, though, the differences in threading behavior between a concurrent container and a non-concurrent container wouldn't make any switch as simple as changing a "new Queue" to "new ConcurrenQueue" - there are subtle assumptions in interfaces and implementations that make 100% "plug and play" hard.

Personally I wouldn't use the alias thing - it was just an idea if one really has no idea how a given data structure will be used and the flexibility of switching mid-development is needed.

I generally like Java's collection framework - which was why I took a stab at porting it. It's reassuring to write code that just takes an Iterator, for example, and not care what one is iterating over.

> Regarding performance: runtime overhead for Interface dispatching is minimal in Walters implementation, but the casting to and from a concrete implementation is not. I imagine (hope) this is just a question of compiler maturity rather than a language design issue.

I had more in mind the inlining that the compiler can do if everything is known at compile time. Runtime dispatching prevents inlining. I agree the actual function call is not a performance problem.


July 22, 2004
"Ben Hinkle"  wrote ..
> The concurrent versions of a queue, for example, has been in the back of
my
> mind and is an argument for interfaces. I have a feeling, though, the differences in threading behavior between a concurrent container and a non-concurrent container wouldn't make any switch as simple as changing a "new Queue" to "new ConcurrenQueue" - there are subtle assumptions in interfaces and implementations that make 100% "plug and play" hard.

Very true; was actually referring to something else (my poor choice of words), but I'm glad you made this point. I'm running into that "100%" barrier myself right now.

> I generally like Java's collection framework - which was why I took a stab at porting it. It's reassuring to write code that just takes an Iterator, for example, and not care what one is iterating over.

I have the same "hangup", so can sympathize <g>
BTW, how much trouble is it to port the Java code? Would a mechanical
translator help you significantly?

> > Regarding performance: runtime overhead for Interface dispatching is minimal in Walters implementation, but the casting to and from a
concrete
> > implementation is not. I imagine (hope) this is just a question of compiler maturity rather than a language design issue.
>
> I had more in mind the inlining that the compiler can do if everything is known at compile time. Runtime dispatching prevents inlining. I agree the actual function call is not a performance problem.

Right. I hadn't considered that.


July 22, 2004
How about the old library by Daniel Yokomiso?

http://www.minddrome.com/produtos/d/

The license is unwieldy, but i don't think this was intentional and he might agree to change it.

-eye

Kris schrieb:
> I'm a big fan of simplicity, so more power to you Ben.
> 
> 
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message
> news:cdlvdj$2ot0$1@digitaldaemon.com...
> 
>>It's the old design question of complexity vs features. Some use-cases are
>>not worth the added complexity. Keep in mind complexity makes a library
>>harder to learn, use and maintain and many times the use-case is so
> 
> seldomly
> 
>>used that it just adds baggage. Do I want a concept of "dynamic array"
> 
> that
> 
>>I can subclass? personally, no, I don't. I've never subclassed vector<>,
>>Vector or ArrayList (to use the C++/Java classes).
>>
>>"Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message
>>news:cdjuu4$1s66$1@digitaldaemon.com...
>>
>>>I can't believe it to be a bad idea to support both inheritance and
>>>composition.
>>>
>>>
>>
>>
> 
> 
July 22, 2004
Ilya Minkov wrote:
> How about the old library by Daniel Yokomiso?
> 
> http://www.minddrome.com/produtos/d/
> 
> The license is unwieldy, but i don't think this was intentional and he might agree to change it.
> 
> -eye

It is licensed LGPL. That could create serious problems for close-source development, but open source projects may still be able to work with it.

Though I'm sure it was revolutionary when first released, it has gathered some cobwebs over the years. A while back, I tried to brush off some of the dust, but I tired of trying to get the unittests to pass. (I'd say that Mr. Yokomiso is a strong believer in DbC.)

I've attached my work in case someone could benefit from it. After only a few months, even my efforts to update it to newer compiler versions has gotten stale, so this might be a losing proposition. :(

> 
> Kris schrieb:
> 
>> I'm a big fan of simplicity, so more power to you Ben.
>>
>>
>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:cdlvdj$2ot0$1@digitaldaemon.com...
>>
>>> It's the old design question of complexity vs features. Some
>>> use-cases are
>>> not worth the added complexity. Keep in mind complexity makes a library
>>> harder to learn, use and maintain and many times the use-case is so
>>
>>
>> seldomly
>>
>>> used that it just adds baggage. Do I want a concept of "dynamic array"
>>
>>
>> that
>>
>>> I can subclass? personally, no, I don't. I've never subclassed vector<>, Vector or ArrayList (to use the C++/Java classes).
>>>
>>> "Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message news:cdjuu4$1s66$1@digitaldaemon.com...
>>>
>>>> I can't believe it to be a bad idea to support both inheritance and composition.


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/





July 23, 2004
J C Calvarese wrote:
> Ilya Minkov wrote:
> 
>> How about the old library by Daniel Yokomiso?
>>
>> http://www.minddrome.com/produtos/d/
>>
>> The license is unwieldy, but i don't think this was intentional and he might agree to change it.
>>
>> -eye
> 
> 
> It is licensed LGPL. That could create serious problems for close-source
> development, but open source projects may still be able to work with it.

AFAIK, LGPL is the least troublesome of the GNU licenses, even when it comes to closed-source projects using the library.

Lars Ivar Igesund
July 23, 2004
"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:cdm2qk$2qgl$1@digitaldaemon.com...
> Ilya Minkov wrote:
>
> > Ben Hinkle schrieb:
> >
> >> It's the old design question of complexity vs features. Some use-cases
> >> are
> >> not worth the added complexity. Keep in mind complexity makes a library
> >> harder to learn, use and maintain and many times the use-case is so
> >> seldomly
> >> used that it just adds baggage. Do I want a concept of "dynamic array"
> >> that
> >> I can subclass? personally, no, I don't. I've never subclassed vector<>,
> >> Vector or ArrayList (to use the C++/Java classes).
> >
> >
> > On the one hand, i agree that for D, a less complex library is quite appropriate.
> >
> > On the other hand, i recall a nice use of subclassing an array (or any other container) in Sather, where language supports all of that so nicely that it adds no complexity to the library... However, D is not the same, and potential productivity gains would probably be minimal.
>
> There is an advantage to having a standard interface to interact with, allowing the implementation of that interface to change.
>
> For example, I may know I need to interact with a list of items, so I declare my variable as a list<>.  I don't know what implementation of the list will yield the better results yet, but at least I know I am working on a subset of methods that are available in all implementations.  I might start with a vector<> and then realize that the backing array is inneficient for large amounts of data so I switch to a linked_list<>.
>
> It's not subclassing that empowers the user, but interfaces.
>
> list<Coord> m_coordinates = vector<Coord>;
> list<Coord> m_coordinates = linked_list<Coord>;
>
> The List interface in Java has the standard "Collection" interface
> as well as list specific functions.  The actual implementations of the
> List have additional functions that pertain to that type of list (like
> a getHead() or getTail() for LinkedList).
>
> I have specified in Java libraries I wrote that I am returning a collection, but did not identify what kind it was.  I needed the luxury of choosing whether I returned a list or a set--but I wasn't sure of the details at that time.
>
> So interfaces provide alot of help when you need to deal with a wider variety of things.
>
> In D we have templates, so I don't know how much that changes the picture.  I can still see times where it would be very convenient to have an interface for the collections as opposed to working directly against an implementation.  Just to handle temporary unknowns.

One of the aspects of DTL is that all containers may optionally be instantiated to implement one or more standard interfaces. I've already got this stuff working nicely, with a List, a Stack and a Vector being manipulated by the same, compiled, function via a common interface.

The instantiations with, and without, the generic interface look like the following:

        alias Vector!(Int)                     vector_t;
        alias Vector!(Int, IContainer)   polymorphic_vector_t;

[btw, I'm really going to try and get DTL 0.1 done this weekend, as I am sure everyone's well past the point of patience by now. Just a minor inconvenience that I've started a rather high-pressure contract for a new client this week ... ;)]



July 23, 2004
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:cdme7s$2usd$1@digitaldaemon.com...
>
> "Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:cdm2qk$2qgl$1@digitaldaemon.com...
> > Ilya Minkov wrote:
> >
> > > Ben Hinkle schrieb:
> > >
> > >> It's the old design question of complexity vs features. Some use-cases
> > >> are
> > >> not worth the added complexity. Keep in mind complexity makes a library
> > >> harder to learn, use and maintain and many times the use-case is so
> > >> seldomly
> > >> used that it just adds baggage. Do I want a concept of "dynamic array"
> > >> that
> > >> I can subclass? personally, no, I don't. I've never subclassed
> vector<>,
> > >> Vector or ArrayList (to use the C++/Java classes).
> > >
> > >
> > > On the one hand, i agree that for D, a less complex library is quite appropriate.
> > >
> > > On the other hand, i recall a nice use of subclassing an array (or any other container) in Sather, where language supports all of that so nicely that it adds no complexity to the library... However, D is not the same, and potential productivity gains would probably be minimal.
> >
> > There is an advantage to having a standard interface to interact with, allowing the implementation of that interface to change.
> >
> > For example, I may know I need to interact with a list of items, so I declare my variable as a list<>.  I don't know what implementation of the list will yield the better results yet, but at least I know I am working on a subset of methods that are available in all implementations.  I might start with a vector<> and then realize that the backing array is inneficient for large amounts of data so I switch to a linked_list<>.
> >
> > It's not subclassing that empowers the user, but interfaces.
> >
> > list<Coord> m_coordinates = vector<Coord>;
> > list<Coord> m_coordinates = linked_list<Coord>;
> >
> > The List interface in Java has the standard "Collection" interface
> > as well as list specific functions.  The actual implementations of the
> > List have additional functions that pertain to that type of list (like
> > a getHead() or getTail() for LinkedList).
> >
> > I have specified in Java libraries I wrote that I am returning a collection, but did not identify what kind it was.  I needed the luxury of choosing whether I returned a list or a set--but I wasn't sure of the details at that time.
> >
> > So interfaces provide alot of help when you need to deal with a wider variety of things.
> >
> > In D we have templates, so I don't know how much that changes the picture.  I can still see times where it would be very convenient to have an interface for the collections as opposed to working directly against an implementation.  Just to handle temporary unknowns.
>
> True. The runtime dispatching of Java's library is nice - though it does mean the performance might not be as good as compile-time binding.

With DTL it won't matter. You'll be able to instantiate with or without a common, runtime polymorphic, interface

> The use
> case you are talking about (protecting oneself from choosing a collection
> type too early in the development process) can be avoided by making up an
> alias. For example define
>  alias vector MyCollectionAlias;
> Then instead of using vector<Coord> everywhere you can use
> MyCollectionAlias<Coord>. If the time comes when you want to use a linked
> list instead of a vector you only have to change the alias definition and
> recompile. Writing libraries might be more scary, though, unless one can
> modify and recompile the library. Anyhow, there are trade-offs in either
> direction.


July 23, 2004
J C Calvarese wrote:

> Ilya Minkov wrote:
> 
>> How about the old library by Daniel Yokomiso?
>>
>> http://www.minddrome.com/produtos/d/
>>
>> The license is unwieldy, but i don't think this was intentional and he might agree to change it.
>>
>> -eye
> 
> 
> It is licensed LGPL. That could create serious problems for close-source
> development, but open source projects may still be able to work with it.
> 

:(

There are a bunch of open source licenses that are not compatible with the LGPL, such as the venerable Apache Software License.  I prefer something more pragmatic to the *GPL dogma.  For most of my stuff, I wouldn't be able to use it.
July 25, 2004
Lars Ivar Igesund schrieb:
> AFAIK, LGPL is the least troublesome of the GNU licenses, even when it comes to closed-source projects using the library.

GPL has the requierement that when library functions more than 10 lines in length are linked into the executable, this executable must be completely open-source. Thus, for a header-only library it's not a solution, as well as for non-stripped D libraries or template libraries.

What you are referring to is 2 things:
* libraries which are shared and belong somehow to an open-source operating system don't impose a problem at all, since they have no restrictions on the target executable.
* some libraries (like wxWidgets or FLTK) have a modified LGPL which allows linking without forcing to open-source. But Daniel's Deimos hasn't.

Daniel has been a friendly and helpful guy. I think he just didn't give enough thought or thorough reading to LGPL. The copy he distributes with the library even contains the "insert your name here" placeholders. :) I don't think the restriction on making the whole executable was intended, even if the intention that derivations from the library should be was.

-eye
1 2 3
Next ›   Last »