[Edu-sig] re: Does edu-sig extend to Jython

[Dethe Elza]

> >4) Python doesn't support X, but you can do Z to simulate it
> I would think as to method overloading we are in the realm of 4).

Yes and no.  Python doesn't have method overloading, but Java doesn't
have keyword parameters.  In my mind keyword parameters are more
flexible, versatile, and powerful.

There is also a general OO pattern of separating what changes from what
stays the same and putting what changes into its own class.  This is
what I was trying to demonstrate with my Line and Point example.  Often,
a huge switch() statement Java is a symptom of needing to give each
class a method which does the right thing, replacing the switch with
polymorphic behaviour.  Your example doesn't require switch, but the
same pattern may apply.

Another pattern is demultiplexing.  In this you would determine the
types of parameters and call a more specific routine:

def intersection(first, second):
  if first instanceof Line: lineIntersection(first, second)
  else: pointIntersection(first, second)

def lineIntersection(first, second):
  if second instanceof Line: lineLineIntersection(first, second)
  else: linePointIntersection(first, second)

def lineLineIntersection(first, second):
  # now we know the types, do something with them.

etc...

This is slightly more verbose than Java overloading, and requires
additiaonl function/method call overhead, but keeps the intent
relatively clear. The biggest problem is one which you will also have
with method overloading: Combinatorial Explosion.

Say we have two java classes, which I'll simulate with the following
pseudocode:

class Point:
  def Intersection(Line, Line)
  def Intersection(Point, Line)
  def Intersection(Point, Point)
  def Intersection(Line, Point)

class Line:
  pass

OK, now you add class Plane and you want to calculate intersections. 
Then you add NonEuclideanPlane.  And LineSegment.  Relying on method
overloading will soon result in hundreds of method definitions, when all
you want is a fairly simple method comparing two *things*.  If each
*thing* can present itself in a thing-neutral way, you only need one
method with no overloading, no demultiplexing, and no named variables.

Of course, that's not always possible.  Sometimes you know you won't
ever need more than these two things, or all of the new classes will be
subclasses of the first two, or whatever.  But these are two strategies
which can be used or mutated for quite a lot of situations.

> I get the gist of your suggestion, but the issue is pervasive and
> might overly tax my ingenuity.
> 
> My current thinking is this:
> 
> I need some testing of the arguments and some decent error
> reporting for inappropriate arguments, in any case. Right now
> you send a Line where the class needs a Plane, and somewhere down the
> pike you'll probably get a message about object x not having
> an attribute "normal" let's say -which Planes's have and Line's
> don't.  For me, as a user, I pretty now where to go. For
> someone else, as a user, it would be a mystery.

If you want early failure, in an appropriate way, assert() is the way to
go.

> (Again, I am assuming this is a necessary byproduct of dynamic
> typing.  I believe that Java would give an error message on
> construction that would be specific enough to allow me to forego
> some of this.  OTOH, I went through the process far enough to
> understand some of what the dynamic typing of Python is
> *giving* me and *saving* me versus Java's typing methodology
> to know not to resent - more than just a little - what it might
> be costing me. I could elaborate with specifics, but won't)

What Java is giving is that it takes positional arguments and
demultiplexes for you based on type (and only on type).  What python
gives you is that you can demultiplex based on name.  Since python can
mix positional parameters and named parameters, and you can test type
yourself easily enough, it seems more powerful to me.

> And in doing some real error catching and reporting on arguments,
> I would expect isinstance will come into play, and in
> doing it, it should not be very much additional burden to
> do it in such a way so that at least I can make argument
> order irrelevant.

That seems like a reasonable expectation.

> After that I guess I need to see where I am, and then take the more
> complex issues of this kind on a case by case basis - there
> probably is no one-size answer for all cases.

There is, but it doesn't fit.

--Dethe