Re: Gee Functional iterators

[Martin DeMello <martindemello gmail com>]

On Tue, Jul 13, 2010 at 8:53 PM, Didier 'Ptitjes' <ptitjes free fr> wrote:
> Hi Martin,
>
> Glad that we have a potential new contributor ;)

Glad to potentially contribute :)

>> Currently no. But the bug I posted is about adding this functionality to
>> Vala. Currently Vala interfaces are more Java/C#-like.
>
> I personally dislike this way of extension and prefer the
> interface/abstract-classes way, but here I guess that this is really a
> question of style and habits...

You mean rather than decorating a class/object with methods at runtime?

> All in all, breaking the ABI/API is not a problem, as we still have at
> least one anticipated round of developement where we do expect to break
> the ABI. So don't let that limit your imagination/creativity/engineering...
>
> At first I propose that you both collaborate to define a feature set
> that you would need/like/foresee. As you seem to have same background
> concerning haskell and ruby, I guess you can easily come into consensus :)
>
> So what kind of operators ? What do they take as argument ? ...

I think once we get a good design and implementation for map(), the
rest will pretty much write itself. Some issues:

1. Do we want to allocate a new ArrayList in the map() method, or have
the calling code pass in an accumulator?

2. Does vala's delegate/closure mechanism allow us to pass in a
function with an arbitrary return value? (That is, can we have a
delegate whose argument type is specified but whose return type
isn't?) If we resort to passing around void* pointers to get around
the type system, can we restore the type safely before we return
anything to the user?

3. Will accessing the external Iterator help us with this? We could
probably manage some casting trickery that is opaque to the user (i.e.
let the implementation code be ugly so that the client code isn't)

martin