6 ms·

Classes are already objects. I don't know whether Java 8 will finally introduce function as a data type, but if it does, I'm pretty sure they won't do it the wa

Classes are already objects. I don't know whether Java 8 will finally introduce function as a data type, but if it does, I'm pretty sure they won't do it the way Ruby blocks work (i.e. block is not an object).

rukkyg 15y ago
Aren't methods already an object of class java.lang.reflect.Method? Do you mean you should be able to do something like foo(PrintStream.println.method) like you can do foo(PrintStream.class)?
- eternalban 15y ago
  No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.
  - riffraff 15y ago
    would you care to explain why this is not enough? You can pass them around, invoke them, get their properties. The interface may be bad but I'm not sure what is missing.
    - eternalban 15y ago
      In the original comment, I was merely addressing the misunderstanding of the GP regarding the reflection packages constructs. The interface is your basic (irreducible) disconnected/unbound procedure invocation API, with all the positive/warts associated. I agree that in principle, we have enough information in the reflection data structure to allow a (specific) JVM implementation to provide a non-standard 'method object' feature. Consensus, possibly? (Good question, really. C. Nutter is one to hit with that one.)
EdiX 15y ago
I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.
- ramblerman 15y ago
  An inner class is the ugly half-brother of a closure. 99% of the time they're used they define just one method. When they are used for more than 1 method implementations, well ... they shouldn't be inner classes. They just exist to fill the gap of having no closures. I say this as a long time and affectionate java user but project lambda in JDK8 is long overdue.
  - EdiX 15y ago
    They are there, they have been there for over ten years, much code exists that needs them to be there. You can't take them out of the language. More syntax sugar for them would be good, adding first class functions IMHO isn't good.
  - yummyfajitas 15y ago
    When they are used for more than 1 method implementations, well ... they shouldn't be inner classes. Why not? Very often, a class will have some data members which are pretty much meaningless elsewhere. Why should the class used to represent that data be exposed elsewhere?

rukkyg 15y ago

Aren't methods already an object of class java.lang.reflect.Method? Do you mean you should be able to do something like foo(PrintStream.println.method) like you can do foo(PrintStream.class)?

eternalban 15y ago
No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.
- riffraff 15y ago
  would you care to explain why this is not enough? You can pass them around, invoke them, get their properties. The interface may be bad but I'm not sure what is missing.
  - eternalban 15y ago
    In the original comment, I was merely addressing the misunderstanding of the GP regarding the reflection packages constructs. The interface is your basic (irreducible) disconnected/unbound procedure invocation API, with all the positive/warts associated. I agree that in principle, we have enough information in the reflection data structure to allow a (specific) JVM implementation to provide a non-standard 'method object' feature. Consensus, possibly? (Good question, really. C. Nutter is one to hit with that one.)

EdiX 15y ago

I'd rather they didn't. It would be redundant with inner classes that are already there, I don't like this piling up of features. It would be more interesting if they allowed inner classes to close over non-final variables.

ramblerman 15y ago
An inner class is the ugly half-brother of a closure. 99% of the time they're used they define just one method. When they are used for more than 1 method implementations, well ... they shouldn't be inner classes. They just exist to fill the gap of having no closures. I say this as a long time and affectionate java user but project lambda in JDK8 is long overdue.
- EdiX 15y ago
  They are there, they have been there for over ten years, much code exists that needs them to be there. You can't take them out of the language. More syntax sugar for them would be good, adding first class functions IMHO isn't good.
- yummyfajitas 15y ago
  When they are used for more than 1 method implementations, well ... they shouldn't be inner classes. Why not? Very often, a class will have some data members which are pretty much meaningless elsewhere. Why should the class used to represent that data be exposed elsewhere?