• Dee Girl <deegirl noreply.com> May 11 2008
• Yigal Chripun <yigal100 gmail.com> May 11 2008
• "Janice Caron" <caron800 googlemail.com> May 11 2008
• Yigal Chripun <yigal100 gmail.com> May 11 2008

Dee Girl <deegirl noreply.com> writes:

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

Yigal Chripun <yigal100 gmail.com> writes:

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

"Janice Caron" <caron800 googlemail.com> writes:

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

Yigal Chripun <yigal100 gmail.com> writes:

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