I see some consensus forming that structural types aren't that
compelling, TCP is a useful property but not a panacea, and in
particular that there ought to be a difference in inline closures and
control abstraction.
I'd like to formalize my CICE/BGGA/FCM hybrid proposal a bit more.
Isn't this roughly what both Ben, Stephen, and myself want?
1. Start with CICE. Modify it slightly to state that this and super
always default to the enclosing block's notion of this and super.
Having a local this/super for CICE is virtually never relevant (only
potentially useful for single abstract method abstract classes, such
as LinkedHashMap. As far as I'm concerned we can drop that use case
entirely if that makes things easier).
2. Allow a keyword or annotation to modify a CICE SAM type into a
control abstraction. These are only legal on interfaces, not on single-
abstract-method abstract classes. Call it @Control.
3. Any CICE block of a @Control type has transparent return, break,
and continue. As far as I know, super, this, break, return, and
continue are the only relevant keywords for TCP. There is NO WAY to
return from the inner method, other than running out the method,
therefore the return type of the one method is compiler-enforced to be
void.
4. A new block syntax is added which replaces the type name with a #,
and starts with the parameter list immediately after. These are legal
only where the type is A) directly inferrable and B) A @Control SAM
type. directly inferrable means: It is a parameter to a method call,
where the parameter type is a @Control SAM type, or, it is assigned to
a variable that is of a @Control SAM type.
5. You may cast any method that matches structure to a SAM type using
a cast, and a # symbol to refer to the method (FCM-like syntax). The
cast is optional (think autoboxing) in the same situations where a
@Control SAM's type name is optional (see the previous paragraph).
example syntax:
@Control
public interface Each<T> { void do(T item); }
public static <T> void forEach(Iterable<T> iter, Each<T> each) {
Iterator<T> i = iter.iterator();
while ( i.hasNext() ) each.do(i.next());
}
public static int absoluteSort(int a, int b) {
return Math.abs(a) - Math.abs(b);
}
public static void example() {
forEach(Arrays.asList("foo", "bar"), #System.out.println);
forEach(Arrays.asList("foo", "bar"), #(String s)
{ System.out.println(s.toUpperCase()); });
Collections.sort(Arrays.asList(-2, 1, -5, -28, -3, 16, 1, 2),
#absoluteSort);
Object foo = (Comparator) #absoluteSort;
}
NB: John Nilsson: I could not follow a word of your post.
On Jan 16, 3:43 pm, Ben Schulz <[email protected]> wrote:
> > So, FCM both violates and follows Tennants Correspondance Principle.
> > But that is in fact a very good thing, something that a naive
> > statement of "violates TCP" fails to appreciate.
>
> Stephen,
>
> not realizing that TCP is violated would be naive and that's what CICE
> does. I was not trying to "name drop", I was simply extending
> Reinier's second point, which was "long returns", a symptom of TCP if
> you will. If and how FCM solves that problem is neither here nor there
> when you compare CICE and BGGA. (Though I would prefer a one-size-fits-
> all proposal over one that differentiates between control abstractions
> and "inline closures" I concede that it eliminates a lot of the
> complexity.)
>
> With kind regards
> Ben
>
> > Stephen
>
> > On Jan 16, 12:24 pm, Ben Schulz <[email protected]> wrote:
>
> > > using(closeable, Block() {
> > > // old code
> > > someMap.get(this); // ouch
> > > // more old code
>
> > > });
>
> > > In a pure language (which Java is by no means) this would happen all
> > > the time, because e.g. if-else is implemented as a message on Boolean
> > > (hello Smalltalk). In those languages the violation of TCP would be a
> > > major annoyance, but at least you would get used to it. In Java it
> > > would simply be a source of evil evil *evil* bugs!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
