[Tutor] Java and Python (was: Iterators)

[Arthur]

> > > Nope. Java is an overhyped phenomenon that is winning hearts
> > > for some extremely nebulous reasons.
> > Java seemed to have the center-piece of an UnMicrosoft campaign -
> > or at least was marketed (implicitly, at least) as such.
>
> Yes, thats what I meant :-)

and your other comments..

Well, I accept that you are talking from a deeper experience than I.

The issue is timely to me, because I am at a bit of a crossroads - feeling
the need to further explore one of C++ or Java - again mostly to have a
better understanding of options to extend, complement Python.

The impetus:

At the moment the lack of method overloading in Python has become a focus.
PyGeo in pure Python has maybe 40 classes of geometric "primitives".  I
could probably cut that to 15 to 20 if I had the ability to distinguish by
constructor signature. I think that would make PyGeo much more useable and
better simulate geometric thinking.

First choice is probably just to find a way to simulate method overloading
behavior in Python; second is to explore whether I can achieve the result by
porting the classes to Java or C++ and expose them to Python.

As to choice one - I have gotten fairly close, but no cigar yet. Essentially
my approach is trying to find is a function/algorythm to which I can send a
list of lists of classes that are acceptable constructor signatures for a
class, together with the instance arguments actually sent to the class, and
receive back a message as to which signature the arguments match, or that
there is no match. The further complications being that I would like to make
argument order irrelevant. That is, if I send a (line instance, plane
instance) it should find a match with a signature of  [Plane, Line], *and*
return the arguments in (plane instance, line instance) order. And, of
course, the [Plane, Line] signature should find a match for instances which
are subclasses of Plane and/or Line.  Interesting and fun to try to work
this out. Probably quite doable, but I haven't  been able to nail it yet.

If I do work it out, I *think* I can take it from there by, among other
things, referencing (to the function name called during update cycles) the
function appropriate to the signature returned as valid. (If that makes any
sense, as stated). And I am thinking since this is all accomplished at
initialization, there will be no performance hit after start-up. And a
second or two of start-up overhead does not concern me.

On the other hand I fear that if this is in fact doable, there would be a
more publicly discussed Python Pattern for handling this issue - so that
maybe I am off on a goose chase.

Ideas welcome.

Art