Re: Update

I was telling My friend Tim Boudreau from the Netbeans project about 
Clerezza as he was looking for something to do for his between job 
holiday.

Here's an e-mail he sent which I thought would be better forwarded 
to the list, to avoid all that good writing getting lost.


On 13 May 2011, at 10:54, Tim Boudreau wrote:

> From a quick look at the FAQ, here's a quick API thought:
> 
> This sort of thing (IMO anything that forces developers to remember
> writing finally blocks) is evil (I know, you see it everywhere in Java
> - it's still evil):
> 
> Lock l = mGraph.getLock().readLock();
> l.lock();
> try {
> Iterator<Triple> iter = mGraph.filter(...);
> //iterate over triples
> } finally {
> l.unlock();
> }
> 
> My first thought is, unless the collections are prohibitively large,
> make a copy and simply eliminate this problem (most developers forget
> that doing
> new HashSet(someCollection);
> or similar also involves iterating someCollection under the hood, so
> you end up with bugs anyway).
> 
> If the lock is really unavoidable, the following is a much nicer
> pattern that takes care of the lock without having to bother the
> caller about it:
> 
> interface CollectionUser {
> <T> T withCollection (Collection c);
> }
> 
> and put a method on whatever object you'd get the collection from,
> which takes care of acquiring the lock, doing whatever is necessary,
> and then releasing it, e.g.
> 
> public <T> T useCollection(CollectionUser<T> u) {
> Lock l = mGraph.getLock().readLock();
> l.lock();
> try {
>    return u.withCollection(getTheCollection());
> } finally {
>    l.unlock();
> }
> }
> 
> Then everybody's code is guaranteed-correct and nobody has to think about locks.
> 
> You could generify it as
> interface CollectionUser<T, R extends Iterable<T>> {
>  public <A> A withCollection(R collection);
> }
> 
> although sometimes people find too-generic things confusing, so it may
> be best to leave some of that out and make it specific to the
> collection type if that is known.
> 
> BTW, it's probably nicer to return Iterable rather than Iterator,
> since then the caller can use the nice for-loop syntax:
> for (Thing t : theIterable) { ... }
> 
> -Tim


Tim, that's why we need you on the list. :-)

Scala also provides a lot of power tools to get rid of this. I think the
RichGraphNode

https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/RichGraphNode.scala

It calls a CollectedIter which hides some of that

https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/rdf.scala.utils/src/main/scala/org/apache/clerezza/rdf/scala/utils/CollectedIter.scala

But I think one can do a lot better as Scala supports closures and many other goodies
we have been waiting for in java for a while. It's just not something I have had
time to look at.

In any case there is a lot of improvement to do in Clerezza. But it is a very  original
and interesting project to look at.

Henry

Social Web Architect
http://bblfish.net/

Received on Friday, 13 May 2011 09:19:32 UTC