Yigal Chripun Wrote:

> Disclaimer: this post reflects my personal opinion only and should not start yet another flame war about tango vs phobos. feel free to disagree with everything I say.
> 
> based on what I know:
> phobos uses the C IO. this is both bad for performance (yet another
> layer) and the interface is ugly. Tango's IO much more powerful, more
> efficient, and more flexible. the cost of it is that it's more complex
> (compared to the  C-like functions phobos provides).
> phobos is ill organized mixing the run-time library (which you as a user
> should never touch) with the user code. Why is the GC internals in the
> same library as the string manipulation functions?? also the namespace
> in tango is much better organized into packages and modules (although,
> sometimes it's too much, like the collections being nested in utils). I
> prefer Tango's tango.io.Stdout vs std.stdio. I think Stdout is lame but
> at least it's inside an IO package. what's the deal with using 8-letter
> acronyms that are hard to remember anyway? we are not limited by DOS' 8
> chars length for file names anymore.
> Tango has much more functionality, is optimized for performance, has
> less bugs and more maintainers than phobos. Walter is a genius compiler
> writer but he can't spend all his time on phobos, And I really dislike
> the C++ smell from all of the code Andrei added to phobos. He's a C++
> Wizard, But that C++ mindset that templates solve everything is bad IMO.
> sometimes, the language does need to provide proper syntax. D needs a
> good tuple support and not a template Tuple!(...)  for example. another
> example would be all the templates in std.algorithm. I'd prefer a reduce
> function that takes a delegate rather than a reduce template.

I am not sure I understood all how D templates work. But how it seems is this. Please correct if it is wrong. If reduce takes a template argument then expands a loop each time in client code. If reduce as you want takes a delegate argument then there is only one loop but there is one indirect call for each iteration.

Question is which one is better. Conceptually they have same power. There are details of performance. I think first one is best because really offers you both. The second only limits your choice. But they have same power, why would you hate one and love another? Thank you, Dee Girl

Dee Girl wrote:
> 
> I am not sure I understood all how D templates work. But how it seems is this. Please correct if it is wrong. If reduce takes a template argument then expands a loop each time in client code. If reduce as you want takes a delegate argument then there is only one loop but there is one indirect call for each iteration.
> 
> Question is which one is better. Conceptually they have same power. There are details of performance. I think first one is best because really offers you both. The second only limits your choice. But they have same power, why would you hate one and love another? Thank you, Dee Girl
> 

read my other reply about time vs. space.
I prefer a delegate since to me it looks cleaner. I don't know how
Andrei implemented it, but either the template inlines stuff and the
benefit would be less time more space (again, the balance can change due
to linker/compiler)
if not than it would be the same as the delegate version. only it'll
bloat the executable since for each unique delegate there will be a copy
of the template.
If my understanding here is wrong, feel free to correct me. [Janice?]

--Yigal

On 11/05/2008, Yigal Chripun <yigal100@gmail.com> wrote:
>  I don't know how
>  Andrei implemented it, but either the template inlines stuff

If the function is called N times (where N > 0), the template is
instantiated exactly once.

The function /may/ get inlined, but this will be true of all functions, not just template functions. In D, there is no way to say "never inline this function".



>  if not than it would be the same as the delegate version.

Yes.


>  only it'll
>  bloat the executable since for each unique delegate there will be a copy
>  of the template.

It is certainly possible to ensure that there is exactly one delegate type for each element type, so the number of copies can be made minimal.


>  If my understanding here is wrong, feel free to correct me. [Janice?]

See separate post. By my reckoning, your OrderedCollection interface results in more executable bloat than use of std.algorithm.sort. (But if my understanding of your idea is wrong, feel free to correct me).

Janice Caron wrote:
> On 11/05/2008, Yigal Chripun <yigal100@gmail.com> wrote:
>>  I don't know how
>>  Andrei implemented it, but either the template inlines stuff
> 
> If the function is called N times (where N > 0), the template is
> instantiated exactly once.
> 
> The function /may/ get inlined, but this will be true of all functions, not just template functions. In D, there is no way to say "never inline this function".
> 
> 
> 
>>  if not than it would be the same as the delegate version.
> 
> Yes.
> 
> 
>>  only it'll
>>  bloat the executable since for each unique delegate there will be a copy
>>  of the template.
> 
> It is certainly possible to ensure that there is exactly one delegate type for each element type, so the number of copies can be made minimal.
> 
> 
>>  If my understanding here is wrong, feel free to correct me. [Janice?]
> 
> See separate post. By my reckoning, your OrderedCollection interface results in more executable bloat than use of std.algorithm.sort. (But if my understanding of your idea is wrong, feel free to correct me).

if what you say is true ( and i don't have any reason to believe
otherwise) than the use of templates here is redundant.
I like the idea of open classes very much (and wait for it to get
implemented for D2) since this removes the inconsistency between methods
and free functions.
the idea is that the classes would contain the minimal needed set of
methods (those there need polymorphism) and other functionality can be
provided with free functions, _but_ with a consistent interface. so, for
example, if all the collections would use the same reduce function, it
can be defined outside the hierarchy as a free function, but the user
would still be able to use collection.reduce as if it was part of the
interface. another possibility is to use mixins for common functionality
to avoid re-inventing the wheel.
in any way, the wanted result is that the user can use a consistent API.

-- Yigal