On 13/07/10 17:23, Didier 'Ptitjes' wrote:
> Hi Martin,
>
> Glad that we have a potential new contributor ;)
>
> On 13/07/10 16:18, Maciej Piechotka wrote:
>> On 13/07/10 16:08, Martin DeMello wrote:
>>> On Tue, Jul 13, 2010 at 7:21 PM, Maciej Piechotka <uzytkownik2 gmail com> wrote:
>>>> On 13/07/10 13:17, Martin DeMello wrote:
>>>>>
>>>>> I'm new to vala in general; could someone explain why adding methods
>>>>> to, say, Iterable would break the API?
>>>>
>>>> Because method add to interface means any class which implemented the
>>>> interface must implement additional method. Which it currently does not
>>>> implement.
>>>
>>> But can't the methods be defined as concrete in the interface, the way
>>> ruby does it? All it requires is foreach.
>>
>> 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...
>
The problem with iterface/abstract classes is that every extending of
interface breaks the whole thing unless someone uses abstract classes.
It forced Java to distinguish between SortedSet and OrderedSet.
GObject had tradition of using the 'virtual' (or even 'real') methods in
interfaces.
I might like them because many languages I use... well have them in some
way. Haskell classes (which have nothing in common with OOP classes)
while a bit more powerful then interfaces (especially with extensions)
do support default methods. Dynamic languages don't have interfaces but
Ruby modules allow similar 'dummy implementations. .Net currently also
support it (however I don't know it so well).
> (...)
> 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 ? ...
>
> Then we would discuss of style. (methods defines on iterables,
> iterators, ...)
>
To simplify notation I will take the following notation
A example(B, C)
- takes arguments B and C and returns A
A example(A ()(B, C), B, C)
- takes delegate taking B and C and returning A and B and C and
returns A
(A, B)
- pair
G
-'argument' of collection
Sorry - I'll do both at one step:
Important:
Iterable<G>
- A fold(A ()(A, G), A) or A foldl(A ()(A, G), A) - Left fold.
Can be implemented in terms of Iterable (I shown it in previous e-mail)
- Iterator<A> scan(A ()(A, G), A) or Iterator<A> scanl(A ()(A,
G), A) - as fold but returns partial results in iterator
- Iterator<G> filter(boolean ()(G)) - returns iterator skipping
elements for which predicate does not hold
BidirIterable<G>
- A rfold(A ()(G, A), G) or A foldr(A ()(G, A), A) - Right fold
- BidirIterator<A> rscan(A ()(A, G), A) or Iterator<A> scanr(A
()(A, G), A) - as scan but goes from end.
Iterable<G> (some of them. Probably should return the 'self' type)
- Iterable<A> map(A ()(G))
Iterator<G> or Iterable<G> (I assume iterator)
- Iterator<(G, A)> zip(Iterator<A>) - combines elements from both
iterators as they go
- Iterator<A> zipWith(A ()(G, B), Iterator<G>) - combine elements
from both iterators puts them into function and returns the
(+ zip3/4/5 etc.)
Haskell utils (make code nice but they aren't strictly so useful. Often
can be simply extention of previous):
Iterable<G>:
- boolean all (boolean ()(A)) - returns true if predicate is true
for each element of collection
- boolean any (boolean ()(G)) - similar to previous
- Iterator<G> drop(int) - returns iterator skipping n first elements
- Iterator<G> dropWhile(boolean G()) - skips elements from the
beginning which hold the predicate
- Iterator<G> take(int) - last element is n-th element (or earlier)
- Iterator<G> takeWhile(boolean G()) - iterator returns element
when it holds predicate
Iterator<G>:
- void skip(int) - skip n elements (moves iterator forward)
- void skipWhile(bool ()(G)) - skip elements from the beginning
that follow the predicate (moved iterator forward)
Utils class??? Not needed in non-pure language?
- Iterator<A> execute(Iterator<A ()>)
> Best regards, Didier.
>
Regards
Attachment:
signature.asc
Description: OpenPGP digital signature