Re: future JDK features: CHARVA
I would LOVE for the JRE to have something like Charva ! Or at the very least a way to build cross-platform text-based interfaces without the need for JNI calls. Regards, Serge... Bernhard Fastenrath wrote: CHARVA awt+swing as selectable features of the JRE and as default in Unix environments without a DISPLAYvariable. ( http://www.pitman.co.za/projects/charva/ ) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Future JDK features 2 items
1/ Ok don't flame me... Method pointers I *know* it is possible to accomplish all the delegation one might want by using polymorphism, but this often leads to unncessary screeds of boiler-plate, so I still I believe there is a case for some kind of streamlining of delegation by allowing it to be achieved on a method level rather than at a class level. For instance it might make sense for a Class to provide several sort methods, polymorphism would require this class to implement a different interface for each one, function pointers could be used instead to have a method take a parameter and return a refrence to the appropriate method thereby correctly (IMHO) encapsulating the decision/conditions within the class and not exposing it externally. 2/ Jar versioning Lets see a JVM which has the capability to accept simultaneous registration of multiple versions of a package and resolve them to satisfy dependence with an appropriate version, and without breaking the classloader model we've grown to love (or perhaps merely accept!). The version resolution could be, by default the most recent, where specified to the classloader by specification version the most recent implementation of the spec by implementation version a specific version. Manifests could specify inter-package dependance declaratively. This would surely be a huge boon to integration. (P.S. I'd love to contribute to either idea...) d *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: RE: Future JDK features 2 items
[Original Message]
From: Danny Angus [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: 10/26/04 3:17:32 AM
Subject: Future JDK features 2 items
1/ Ok don't flame me... Method pointers
But still, be sure to watch for flames from the
Purist Society! They _do_ have a point, ya know.
I *know* it is possible to accomplish all the delegation one might want by
using polymorphism, but this often leads to unncessary screeds of
boiler-plate,
so I still I believe there is a case for some kind of streamlining of
delegation by allowing it to be achieved on a method level rather than at
a
class level.
For instance it might make sense for a Class to provide several sort
methods, polymorphism would require this class to implement a different
interface for each one, function pointers could be used instead to have a
method take a parameter and return a refrence to the appropriate method
thereby correctly (IMHO) encapsulating the decision/conditions within the
class and not exposing it externally.
In order to support such a concept, there would
necessarily be a severe restriction on what such
a method pointer reference object could do and
how it was specified. The 'C' function-through-pointer
syntax might be very useful here, but, as Mr. Angus
says, return a _reference_ instead of a _pointer_.
Try this on for size, from ANSI 'C' syntax:
public (int methodName)(Integer parm2);
or,
public (int)(Integer parm2) methodName;
Notice that the argument names should be optional
since it is the object type that is important here.
I would prefer the first syntax since it looks more
like how it would be invoked, method name followed
by its parameters. It would be used like,
if (0 == comparableObjectIsParm1.methodName(parm2)) {...}
or generically,
pre
sampleCompareMethod(ImplementsComparable comparableObject,
Integer compareWith)
{
private (int compareMethod)(Integer);
switch(compareMode)
{
case 1: compareMethod = ParentClass.parentCompareMethod;
case 2: compareMethod = SubClass1.sub1CompareMethod;
case 3: compareMethod = SubClass2.sub2CompareMethod;
}
return(comparableObject.compareMethod(compareWith));
}
In a similar way, and probably not quite what Mr. Angus
is suggesting,
sampleCompareMethod(ImplementsComparable comparableObject,
Integer compareWith)
{
private (int compareMethod)(Integer);
switch(compareMode)
{
case 1: compareMethod = SomeClass.compareMethod1;
case 2: compareMethod = SomeClass.sub1CompareMethod2;
case 3: compareMethod = SomeClass.sub2CompareMethod3;
}
return(comparableObject.compareMethod(compareWith));
}
/pre
Notice again that the local variables do not need
to have a name for the formal arguments, just
their types.
Using such syntax provides a simple way to
build function-through-pointer tables.
The table would only care about the return
type, not in the parameter list. Here is
where the second form would be useful, namely,
for those that like their [brackets] to _follow_
the variable definition, although I will show
it in both forms:
public (int methodName)(Integer)[];
and,
public (int)(Integer) methodName[];
To me, the latter expression is easier to
identify as an array of (int method(Integer parm)
than the first one.
The overarching question here is, How does this
concept fit into the OO philosophy? That is for
the Java LEX/YACC-oids to figure out! Mr. Angus'
idea is a very practical one, if not very conventional,
and I have run across this issue before. Of course,
solving it until now involves a compareTo() method
in a bunch of subclasses in a normal setting, but
there have been times...
Dan Lydick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: FW: RE: Future JDK features 2 items
Dan Lydick wrote:
From: Danny Angus [EMAIL PROTECTED]
1/ Ok don't flame me... Method pointers
But still, be sure to watch for flames from the
Purist Society! They _do_ have a point, ya know.
I *know* it is possible to accomplish all the delegation one might want by
using polymorphism, but this often leads to unncessary screeds of
boiler-plate,
so I still I believe there is a case for some kind of streamlining of
delegation by allowing it to be achieved on a method level rather than at
class level.
Your example can as easily use class references as it can be written
using method pointers.
Where's the advantage of a method pointer?
class ImplementsComparable {
interface ComparableMethod {
void compare (Comparable c) { ... }
}
class CompareMethodImpl1 implements ComparableMethod {
void compare (Comparable c) { ... }
}
class CompareMethodImpl2 implements ComparableMethod {
void compare (Comparable c) { ... }
}
class CompareMethodImpl3 implements ComparableMethod {
void compare (Comparable c) { ... }
}
ComparableMethod compareMethodImpl1 = new CompareMethodImpl1 ();
compareMethodImpl2 = new
CompareMethodImpl2 ();
compareMethodImpl3 = new
CompareMethodImpl3 ();
}
sampleCompareMethod (ImplementsComparable comparableObject,
Integer compareWith)
{
ComparableMethod compareMethodImpl;
switch (compareMode) {
case 1: compareMethodImpl = comparableObject.compareMethodImpl1;
case 2: compareMethodImpl = comparableObject.compareMethodImpl2;
case 3: compareMethodImpl = comparableObject.compareMethodImpl3;
}
return compareMethodImpl.compare (compareWith);
}
If you are desperate to use method pointers you can use a method pointer
in Java
using java.lang.reflect.Method nearly the way you suggested it to be used:
public final static Method COMPARE_METHOD_1 =
ImplementsCompare.class.getMethod (compareMethod1, parameterTypes||);
public final static Method COMPARE_METHOD_2 =
ImplementsCompare.class.getMethod (compareMethod2, parameterTypes||);
public final static Method COMPARE_METHOD_3 =
ImplementsCompare.class.getMethod (compareMethod3, parameterTypes);||
switch (compareMode)
{
case 1: compareMethod = COMPARE_METHOD_1;
case 2: compareMethod = COMPARE_METHOD_2;
case 3: compareMethod = COMPARE_METHOD_3;
}
return compareMethod.invoke (comparableObject, parameters);
If the parameters have different names it's likely they have different types so
you would probably want to invoke methods with the exact same parameter list,
which defeats your argument that not knowing parameter names is an advantage.
The main difference is that in the earlier piece of code methods are wrapped
in inner classes, which amounts to about 30 additional characters you have to
type: class FooBar { ... } implements I for each class, one instantiation
for each class and a common interface.
--
www.citizens-initiative.org http://www.citizens-initiative.org/
Re: FW: RE: Future JDK features 2 items
[Original Message]
From: Bernhard Fastenrath [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Date: 10/26/04 2:09:02 PM
Subject: Re: FW: RE: Future JDK features 2 items
Dan Lydick wrote:
From: Danny Angus [EMAIL PROTECTED]
1/ Ok don't flame me... Method pointers
...
Your example can as easily use class references as it can be written
using method pointers.
Where's the advantage of a method pointer?
Maybe Mr. Angus wasn't going here, but behind my
concept was work I have done in C/C++ with arrays
of function-through-pointer for varied functionality
depending on context.
class ImplementsComparable {
}
sampleCompareMethod (ImplementsComparable comparableObject,
Integer compareWith)
{
}
This approach might do the job just as well.
What say you, Danny Angus?
If the parameters have different names it's likely they have different
types so
you would probably want to invoke methods with the exact same parameter
list,
which defeats your argument that not knowing parameter names is an
advantage.
The naming of C/C++ parameters in function prototypes is often skipped
as long as the type is known. Nobody cares except the implementation
of the actual method. The downside is that you have to know the
exact prototype in order to reference it, and prototype header files is
part of what Java is trying to get away from.
The main difference is that in the earlier piece of code methods are
wrapped
in inner classes, which amounts to about 30 additional characters you
have to
type: class FooBar { ... } implements I for each class, one
instantiation
for each class and a common interface.
Good point. Thanks for your observation.
Dan Lydick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features 2 items
On Oct 26, 2004, at 1:17 AM, Danny Angus wrote: 1/ Ok don't flame me... Method pointers If you want method pointers today, just get a good byte code generation tool. We use cglib in Geronimo to generate FastMethod objects, which look a lot like reflection Method but are about a 100 times faster (there only slightly slower than an invoke virtual). -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
