Here's a list of 12 'random' ideas. Next to each idea is description
what the idea is about, if it break API/ABI and how much, what vala
extensions it needs etc.
It is not in any way an official list. Feel free to criticize.
1. USING CLOSURES
The change is simple - use 'Data' version (i.e. GCompareDataFunc instead
of GCompareData). It enables using user closures as comparable functions.
Impact on API: Broken constructors/getters. Possibly small impact if
most uses null anyway.
Impact on ABI: Formally broken. However on most (all?) C calling
conventions there is no impact.
Importance: Small/Medium. Most user don't care but it would provide a
consistent behavior (i.e. without questions 'why I cannot use closures
here')
2. SINGLE-LINKED LIST INTERFACE
An interface for single-linked lists (i.e. without bi-directional
iterators etc.). It should be inserted between List and Collection.
Impact on API: Broken for those hand-implementing List.
Impact on ABI: Broken for those hand-implementing List.
Importance: Small
3. SINGLE-LINKED LIST/SINGLE LINKED NON-BLOCKING LIST
2 implementations:
- single-linked list
- non-blocking linked list allowing non-blocking access to list (i.e.
many threads can access list simultaneously with guarantee of finishing
operation in finite number of steps)
Impact on API: Added classes (nothing broken).
Impact on ABI: Added classes (nothing broken).
Importance: Small
Needed Vala Extensions: There's need of 1 or 2 extra bits next to
reference so the structure have to be properly aligned. While it is no
problem on most architectures there is not necessary so on more exotic
architectures or compile flags.
There are other implementations however there are mostly workarounds and
probably it would be better to implement it in C/provide required
support of aligning in Vala.
4. NON-BLOCKING SKIP LIST<ACCEPTED?>
Implementing non-blocking set (i.e. many threads can access list
simultaneously with guarantee of finishing operation in finite number of
steps)
Impact on API: <TO DISCUSS> Skip list would technically be a sorted set
but there is similar problem with bi-directional iterators as with 3.
Impact on ABI: See "Impact on API"
Importance: High (???)
Needed Vala Extensions: See 3
5. CODE REFACTORING<ACCEPTED?>
At least TreeMap/TreeSet code is largly duplicated. Additionally it
handles both ADS implementation as gee interfaces. Refactoring ADS
implementation out into internal structure would shorten and simplify
code as well as remove duplicates.
Impact on API: -
Impact on ABI: -
Importance: Medium
6. REVERSED ITERATORS<ACCEPTED?>
Allow code like:
foreach(int i in mycollection.reversed(_view)
Impact on API: Broken for implementations of interfaces. An extension of
existing interfaces by properties.
Impact on ABI: Broken for implementations of interfaces. An extension of
existing interfaces by properties.
7. REVERSED LIST/SORTED SET/SORTED MAP<ACCEPTED?>
Allow code like:
foreach(int i in mycollection.reversed_view) as well as providing fully
the view (mylist.reversed_view is List
Impact on API: Broken for implementations of interfaces. An extension of
existing interfaces by methods.
Impact on ABI: Broken for implementations of interfaces. An extension of
existing interfaces by methods.
Importance: High
8. ITERATOR REWORK
Change Iterator<G> interface to exclude first() (but possibly
introducing last() with default implementation) moving first() to
BidirIterator<G>. See functional iterators discussion for more
information for reasons. Add pointed_at or similar properties etc.
Impact on API: Large. Iterator<G> is probably the most used interface.
Impact on ABI: Large. Iterator<G> is probably the most used interface.
9. FUNCTIONAL INTERFACE<ACCEPTED?>
Allowing map a function over collection. Fold it etc.
Impact on API: ??? - see separate discussion
Impact on ABI: ??? - see separate discussion
Needed Vala Extensions: Generic delegates.
Dependencies: 8 (???)
10. FILE/IO ITERATORS
Imagine writing foreach(string line in file.lines) as in Ruby or similar
language or foreach(File f in directory)
Impact on API: ???
Impact on ABI: ???
Needed Vala Extensions: Possibly it should look like a native method of
GIO without forcing dependency.
11. ASYNCHRONOUS ITERATORS
The problem with 9 and 10 is that they are synchronous. Therefore all
I/O operation would always block thread.
has_next/next should be made async operation for use with I/O. However
map should have map_async with the signature:
Iterator<B> Iterator<A>.map_async(B ()(A), void ()(A, Cancellable,
AsyncReadyCallback callback), B ()(A, AsyncResult))
Needed Vala Extensions: -
Needed Vala Sugar: It would be nice if it was possible to write:
Iterator<int> i = something.map((uri) => {
File f = Vfs.get_file_for_uri(uri);
yield;
foreach (yield string line in f.lines) {
// do something
}
});
Which would generate both methods. However we can break interface once
and wait till sugar later.
12. SIGNALS<ACCEPTED?>
Emit notification signals when collection is resized. Possibly
added/removed etc. signals
Impact on API: For implementations
Impact on ABI: For implementations
Regards
Attachment:
signature.asc
Description: OpenPGP digital signature