On Sun, 17 Jul 2011 09:49:52 -0400, d coder <[email protected]> wrote:
Greetings
Sure, this does not solve the original problem, if it was really an
issue.
@d coder: do you have an example where runtime changing of the
comparison
function
behavior would be required?
While I do, I am sure there are alternative ways to program to avoid
needing
those.
But I think there is a bigger usability issue in what I mentioned. There
would be a good number of coders wanting to instantiate
BinaryHeap!(SomeContainer, SomeComparator) as a member of another
class. I
agree that more often it would be the case where SomeComparator does not
depend on a state variable. But even then, D does not allow me to provide
any function/delegate literal for SomeComparator.
So for example, even this is deemed illegal:
class Foo {
BinaryHeap!(uint[], (a, b) {return a > b;}) heap;
// ..
}
To a casual programmer, this would be unacceptable, making BinaryHeap and
other such structures too problematic to use. Even when you explicitly
specify the delegate literal as a "function":
class Foo {
BinaryHeap!(uint[], function (a, b) {return a > b;}) heap;
// ..
}
You get another Error: this for __funcliteral1 needs to be type Foo not
type
BinaryHeap!(uint[],__funcliteral1)
The issue here is that the *type* of the binary heap depends on the
functor. Yet, you cannot define the functor (which depends on having an
instance pointer) until you've instantiated the object, which in turn
requires declaring the type.
What is needed is a BinaryHeap solution that accepts a delegate as a
parameter instead of a template member. I wonder if there's a reasonable
mapping from the latter to the former, as I also use alias parameter to
define functors in dcollections (stolen shamelessly from Andrei's
design). Worst case, BinaryHeap grows a branch which stores/calls a
delegate instead of a template parameter.
Note to Mehrdad:
I'm actually still confused at why _functions_ should be passed as
template parameters
The beauty of alias parameters is they can be *anything*, including:
* functions (not function pointers)
* function pointers (including function literals)
* inner functions (i.e. functions with context that *aren't* delegates)
* delegates (including delegate literals)
* function objects (i.e. structs with opCall)
* function templates (whose parameters are determined via IFTI)
* strings which are used to build a function out of simple parameters
(i.e. "a < b")
The big issue is that they cannot be runtime-dependent (to a certain
degree). What's interesting is that they *can* be runtime dependent if
they are inner functions. So clearly there is a way to get this to work.
What I'm not sure is if it can be done without some syntax changes.
It's definitely a problem, but the benefits of using alias parameters seem
to far outweigh these issues.
-Steve
