stamped locks

[Gavin King]

http://www.takipiblog.com/2014/05/30/java-8-stampedlocks-vs-readwritelocks-and-synchronized/

I wonder if obtain() and release() on Obtainable should produce and
consume a "stamp". WDYT?

--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[Tom Kaitchuck]

There are two issues here:

1. Stamped locks. - Which IMHO are really a terrible idea, and are just asking for broken code and obscure bugs.

2. The pattern of obtain and release. This occurs fairly frequently in a lot of use cases. IE: resource pooling, classes that have some sort of create / finalize contract, etc.

In this second case the pattern is actually more subtle, the common case that is needed is to have a class of type foo that has two methods:

Bar giveMeABar();

void returnBar(Bar b);

Here the expectation is that the caller uses bar within some scope (sometimes defined by a block sometimes not) but the expectation is that the caller doesn't merely return the same type that they obtained, but the same instance. This can be gotten around by having an inner class as the type, which cannot be instantiated elsewhere. This of course makes it hard to make a generic interface out of this concept that implementations all comply with. Java's try with resource is a hack in this direction. 

I don't know what it would look like, but ideally there would be some ability of the type system that would enable one to specify that one item is the same as another.

[Gavin King]

On Tue, Jun 17, 2014 at 11:33 PM, Tom Kaitchuck <tom.ka...@gmail.com> wrote:

> 2. The pattern of obtain and release. This occurs fairly frequently in a lot
> of use cases. IE: resource pooling, classes that have some sort of create /
> finalize contract, etc.

Well, FTR, in Ceylon 1.1 we already have quite good support for those
patterns with try and Destroyable/Obtainable. But the thing about
stamped locks is that they just return a number. Which is good for
performance. But Destroyable/Obtainable don't support that.

More recently I have been asking myself if the try is really
necessary: why can't we just automagically clean up any Destroyable
resource instantiated in a block when the block finishes executing?

[Roland Tepp]

kolmapäev, 18. juuni 2014 0:46.28 UTC+3 kirjutas Gavin King:

More recently I have been asking myself if the try is really
necessary: why can't we just automagically clean up any Destroyable
resource instantiated in a block when the block finishes executing?

You know, that would be really cool!

Much nicer than any of the alternatives in use currently in languages that have similar ARM blocks (well, ones I know of at least).

The only question is -- what if the object escapes the block (either via assignment or return)?

[Tom Kaitchuck]

A variation on this that happens a lot, that I'm really not sure how to represent in Ceylon is the following in Java:

  HashMap<Class<?>,MyHandler<?>> typeMap = new HashMap<>();

Here the pattern is that the map is from a class of type X to a handler of type X where X is different for each element in the map. 

Because Java's type system is limited there is no way to express this other than "?" which means that put and get calls into the map return the wrong thing and need to be cast. Additionally there is no validation to prevent one from making a copy and paste error and inserting an incorrect mapping.

--
You received this message because you are subscribed to the Google Groups "ceylon-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-dev+...@googlegroups.com.
To post to this group, send email to ceylo...@googlegroups.com.
Visit this group at http://groups.google.com/group/ceylon-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAP7PoCd7%3D_nf9Mm2Zq1kdfNZ93tCSQqQnV5zs_oK24bTvRbT-Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Gavin King]

Represent it using a generic function:

object map {
shared MyHandler<T>? get<T>() => .... ;
}

Call it like this:

MyHandler<Something> handler = map.get<Something>();

> https://groups.google.com/d/msgid/ceylon-dev/CAGwh2krsfLN16McVoGJrqZrCEk4--KAkpN8rO2kMdbSKY%3D-LRw%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Tom Kaitchuck]

Sure, you can always do that. But if you want to build up the mapping in advance as opposed to running it on each request, that does not help.

Perhaps in Ceylon it could be done through subclassing the Map.

In Java this is not possible because it does not allow to override a method with different parameters based on generics.

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-dev/CAP7PoCd-zMAOuR0GR%3DNw7LmG-ZahaxcGRiFMbaWsRDV%3DRJzMoA%40mail.gmail.com.