There's 'synthetic', which is a flag on class members that indicates that they aren't intentional (by the code author), just a side-effect of the compiler making it all work right. A side-effect is that most IDEs suppress them in auto-complete models, which is overkill, but another flag that means: This is a system type thing, so, auto- complete, sure, but definitely don't generate javadocs, or offer it when extending classes, etcetera. I don't like structural typing in a java closure proposal, but if it does happen, The FunctionIII stuff can also use such a flag. Adding flags to members is backwards compatible. Just an idea.
NB: For a closure proposal I was cooking up I'm going to need a bunch of synthetic publics, which fortunately works as intended; javac will refuse to compile access to synthetics in .java source, and eclipse does not list them in auto-completes etc, but the JVM completely ignores the synthetic flag. (allows any call to a synthetic same as a call to a non-synthetic). Nice feature. On Feb 10, 3:45 pm, James Iry <[email protected]> wrote: > Scala doesn't work that way because Tuples have O(1) access to all > elements where what you propose would have O(n) access. Having 22 > Tuple classes is definitely a code smell. Same with having 22 > Function classes. But those are code smells forced by the JVM. On > "machines" with a less strict stack discipline than the JVM, e.g. the > x86, there are other ways to encode tuples that are much more > flexible. > > An alternative on the JVM is to use runtime byte code generation and > classloader-fu to generate TupleN classes as needed. But Scala has > avoided that kind of magic as it tends to not play well with other > things that want to do classloader-fu. > > What you've proposed is called a Heterogeneous Linked List, or HList > for short. It's exactly the kind of list you get from Lisps. Most > statically typed languages can't do them, or at least not usefully. > HLists are very tricky to type correctly and still make pleasant to > use. Scala can do it, but only just barely using a currently > experimental compiler flag. When that feature stabilizes you can > probably expect HLists to be in the standard library. > > Finally, related to your last point re: BGGA, Scala does have a type > for undefined called "Nothing." BGGA's undefined type was renamed > from "Unreachable" to "Nothing" in order to follow Scala's > example:http://gafter.blogspot.com/2008/08/java-closures-prototype-feature.html. > Both names make sense in context. > > The BGGA Void type means something else. Void is the type of a > closure that returns normally but doesn't return any useful data. > Scala has an equivalent (again, before BGGA did), but Scala calls it > Unit to differentiate from the non-first class nature of Java's void > and to help further distinguish it from Nothing. > > On Feb 9, 7:50 pm, Reinier Zwitserloot <[email protected]> wrote: > > > If you have inference, you can create TupleXes by chaining tuples. > > > So a (String, Integer, Double) tuple would be: > > > Pair<String, Pair<Integer, Double>>. > > > Then you add a light sprinkling of syntax sugar to make it not look > > ridiculous. > > > I don't understand why scala doesn't work this way. It would avoid > > littering the namespace with a tonne of these and having an arbitrary > > limit of 22. > > > A 'Pair' could then support asking how big it is (it would check if > > it's second element is a Pair, and if so, return that pair's size +1, > > and if not, return 2, or better yet, have a BGGA-esque Nothing/Void/ > > Undefined type and don't count those either). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
