On 13/07/10 17:50, Martin DeMello wrote:
> 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?
>
What you mean is duck typing. It is somehow different then static typing
when compiler checks if type have the given method.
The problem discussed is whether the interfaces should have a concrete
implementations at all or should just specify... well interface.
>> 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?
>
On one hand most in-pure FP languages (F#, Scala) you would get a new
ArrayList. However (what I haven't written in previous e-mail) it might
be actually beneficial to operate on iterators instead of ArrayLists.
Chaining allocation can be quite expensive:
array.map((x) => {
return x.get_width();
}).foldl((x, y) => {
return x + y;
}, 0); // array.map(Window.get_width).sum() ?
would have one - unnecessary - allocation.
Working on Iterators(as to large extend done F#) have the advantage of
avoiding allocations:
array.iterator().map((x) => {
return x.get_width();
}).foldl((x, y) => {
return x + y;
}, 0); // array.iterator().map(Window.get_width).sum() ?
May be a bit longer but avoids the allocations. On the other hand it
would cause much longer code:
new ArrayList(array.iterator().map((x) => {return x.get_width();}));
or
new ArrayList(array.map((x) => {return x.get_width();}));
instead of:
array.map((x) => {return x.get_width();})
However it makes map simply to put into interface. I'd vote so far for
returning iterator and adding iterator-based constructors[1]
[1] With the methods I proposed it would be possible to do:
new ArrayList(list.filter((x) => {return x%2 == 0;}))
> 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?
>
It's on the way into vala.
> 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)
>
The point of library is to make the user code beautiful ;)
> martin
Regards
Attachment:
signature.asc
Description: OpenPGP digital signature