On Apr 17, 2008, at 4:53 AM, Daniel Yokomizo wrote:
> It's better to reuse whatever syntax these proposals use.
One nice thing about working on the JVM is that I get to take a
vacation from syntax arguments. Though I might carry my pager on
vacation. :-)
Another detail I left out of the nutshell, but which is present in
the forthcoming full API, are operations for unreflecting fields as
well as methods:
class MethodHandles { ...
public static MethodHandle
unreflectFieldGetter(java.lang.reflect.Field f);
public static MethodHandle
unreflectFieldSetter(java.lang.reflect.Field f);
... }
Something language designers usually miss at this point is that a
handle to a variable (like a field above) is most naturally
represented as a two-sided extension to a normal function type,
nameless as a regular function, but with an additional setter
aspect. It may be called an accessor; it is a subtype of function,
and is parameterized exactly the same as function:
class Foo { int val } foo;
accessor {=> int} acc1 = (&foo.val or foo#val or something);
int i = acc1();
acc1() = i+1;
Map<K,V> map;
accessor {K=>V} acc2 = (&<K>map.get or map#get(K) or something,
with put annotated in somehow)
V x = acc2(k);
acc2(k2) = v2;
The design of accessor types is (AFAIK) insufficiently appreciated.
It was at the heart of "esh" Scheme[1] and allowed clean access-
oriented programming patterns, and better integration with slot-
oriented languages (CLOS-lite, C++ lvalues).
-- John
[1] http://homepage.mac.com/rose00/work/esh.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
