Re: Future JDK features 2 items
On Oct 27, 2004, at 4:15 PM, Bernhard Fastenrath wrote: method pointers? closures? Is anybody going to suggest self-modifying java assembler code as a language feature? I don't really see how you got from method pointers and closures to self-modifying code (I see that as a bit of fear mongering). Is the goal to break Java and render it useless? In my opinion we can live without closures. You didn't have to attach for a bit longer. I actually love closures, and think it would be a great addition to Java. I spend a lot of time tracking down poorly written try/finally blocks in people's code where they don't properly close DB connections, IO streams, Jar files, and even delete their temp files. A good closure library would virtually eliminate this type of programming errors. Now I still doubt Sun's ability to pull of this feature after seeing the junk in 1.5, but if I got to choose only one major language feature to add it would be closures. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features 2 items
Dain wrote: I understand what you are saying, but do you believe that Sun could actually get such a feature right? I take your point, and tend to think not. I don't believe that Sun would get it right first time, not if we consider their track record. So, yes, I am arguing that no feature is better than a poorly implemented feature. I wholeheartedly support that point of view! core Java is pretty much OK, and doesn't really have the issues that would justify the risk (of implementing poorly and requiring re-working later) involved with new features for which accepted work arounds exist. I personally don't like the prospect that Java is heading for bloat, and would much rather see Sun spend its time fixing the JVM than mucking about with core Java. (but I'll start a new thread for that one..) 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]
Re: FW: RE: Future JDK features 2 items
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.
Yes. It was in order to provide much more dynamic variation in behaviour,
but also to have that dynamism encapsulated by the implementing class.
A class would implement an interface as usual, but could dynamically return
a different method implementation from a set of methods declared internally
without recourse to multiple interfaces or classes defined purely to
provide an alternative implementation of an internal method.
I can't see why we persist in putting up with the existing long-winded
approach of defining single method inner or anonymous classes just so that
we can select a method implementation dynamically.
Other languages provide support for this kind of behaviour, and I don't
believe it needs to break any OO principles if it is properly designed.
This approach [anonymous classes] might do the job just as well.
What say you, Danny Angus?
It works, obviously, but it contains more meaningless boilerplate code for
structure than significant code for behaviour.
Additionally if you have a number of less trivial methods implemented it
becomes very hard for a programmer to understand the context of the block
they are working in.
Is it not true that when writing this stuff both IDE's and people have
difficulty working out exactly which set of braces to close and when?
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.
Yeah, and my point is why do we have to put up with this...
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]
Re: Future JDK features 2 items
Dain wrote: If you want method pointers today, just get a good byte code generation tool. Yeah I know, and I seriously believe that workarounds such as this do more to harm the so-called purity of Java than providing explicit language level mechanisms for method pointers. The AWT moved from Events to delegation in 1.1 Since then I have always wondered why we are compelled to delegate to Classes implementing interfaces rather than Methods implementing specified method signatures. It leads to alot of structural code which obfuscates functional code, and a lot of unnecessary plumbing to route conditional execution after the method has been invoked. Why can't we drop the extra structures and apply our pre-conditions before the method is invoked? 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]
Re: Future JDK features 2 items
On Oct 27, 2004, at 1:10 AM, Danny Angus wrote: Dain wrote: If you want method pointers today, just get a good byte code generation tool. Yeah I know, and I seriously believe that workarounds such as this do more to harm the so-called purity of Java than providing explicit language level mechanisms for method pointers. I understand what you are saying, but do you believe that Sun could actually get such a feature right? My guess is they would slap so many coding restrictions and security checks around this feature to make is most useless. So, yes, I am arguing that no feature is better than a poorly implemented feature. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Future JDK features 2 items
The way that most modern languages handle what C used to do with method-pointers is with closures. Exactly what that means for a language like Java is being experimented with in places like Groovy. Much like how entity beans are a joke -- giving all of J2EE a big black eye -- and the standard is moving over to what actually has been proven to work (a-la Hibernate), I agree with Dain that I don't really trust Sun to get it right yet; I'd rather see real-life solutions for a while before it gets mixed into the platform... We've lived with XDoclet before getting annotations, and libs for doing enums before JDK1.5, we can live without closures for a bit longer. (Said by someone who hates to leave Ruby and Python for Java largely because Java doesn't have closures.) -Jim Moore -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 12:53 PM To: Jakarta General List Subject: Re: Future JDK features 2 items On Oct 27, 2004, at 1:10 AM, Danny Angus wrote: Dain wrote: If you want method pointers today, just get a good byte code generation tool. Yeah I know, and I seriously believe that workarounds such as this do more to harm the so-called purity of Java than providing explicit language level mechanisms for method pointers. I understand what you are saying, but do you believe that Sun could actually get such a feature right? My guess is they would slap so many coding restrictions and security checks around this feature to make is most useless. So, yes, I am arguing that no feature is better than a poorly implemented feature. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Future JDK features 2 items
method pointers? closures? Is anybody going to suggest self-modifying java assembler code as a language feature? Is the goal to break Java and render it useless? In my opinion we can live without closures. You didn't have to attach for a bit longer. Jim Moore wrote: The way that most modern languages handle what C used to do with method-pointers is with closures. Exactly what that means for a language like Java is being experimented with in places like Groovy. Much like how entity beans are a joke -- giving all of J2EE a big black eye -- and the standard is moving over to what actually has been proven to work (a-la Hibernate), I agree with Dain that I don't really trust Sun to get it right yet; I'd rather see real-life solutions for a while before it gets mixed into the platform... We've lived with XDoclet before getting annotations, and libs for doing enums before JDK1.5, we can live without closures for a bit longer. (Said by someone who hates to leave Ruby and Python for Java largely because Java doesn't have closures.) -Jim Moore -- www.citizens-initiative.org http://www.citizens-initiative.org/
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]
