> [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]
