[Tutor] Creating instances (group program revisited)

Wed, 28 Mar 2001 23:32:55 -0500

Good.  <grin>  I was beginning to wonder after your previous message
defending's Java's class-based model.  (and you are right that Java
isn't the first/only language to use a strictly class-based moedl)

| >  Python is OO through and through.  There is nothing in Python that
| >  isn't an object.
| 
| Ints, Floats etc.. are not objects, but types. Files ????

ints floats string tuples list files, etc are objects.  In _CPython_
the type/class split exists as an accident of implementation.  The
only difference is that integer objects are defined in C and thus have
slight semantic differences to objects defined in python using the
class construct.  The difference is mainly that you can't add
arbitrary members and there is no __class__ or __bases__ attribute.

Jython, on the other hand, doesn't have this accident of
implementation and all built-in types can be subclassed with python
code.

| > Even functions are objects in Python.  Putting the loadFile function
| > into a class would be more class-based, but not necessarily more OO.
| 
| Because Python is typeless you don't see the advantage

I think this is a common misconception.  Python is _not_ typeless, it
is simply _dynamicaly_ typed.  If you write a function that takes a
string argument, and I pass it an int, I will get a TypeError.  In
perl, otoh, you will have no way of knowing that I screwed up and your
function will very happily and correctly give me the wrong anser.

Here is an example, without even using functions

>>> print "Hello " + 3 + " World"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: cannot add type "int" to string
>>>

| However, In C++ you can overload this function if you want to read from
| something else than a file.
| addStudent( File);
| addStudent(String);

Overloading is a different issue, and I don't really miss it that much.  It is
also only marginally relevant for OO.  C could use overloading just as
effectively.

| 
| A better design in my mind would be to have a addStudent(File) method
| in Teacher, and a  getStudent() method in the StudentListFile class,
| which derives from the File class.
|
| In this way, we don't have to modify the Teacher class implementation
| if we change the file format.  If we modify the file syntax, we modify
| the internals of the File class.

How about having a StudentParser object (class, whatever ;-)) that can
parse strings.  Have a File that can load the file and hand the strings
to the StudentParser to get back a Student.  The Teacher can have a
addStudent( file=None , astring=None ) function that overloads based on
the keyword arguments.  If you pass it a file, it will ask the File
object to give back Students from it, which are actually created (ie
new'ed or malloc'ed) by the StudentParser object.  If you pass it a
string, it will ask the StudentParser itself for the resulting Student
object.

| 
| >
| > I'm not arguing that the function shouldn't be in a class, that
| > depends on the overall design, but to be OO doesn't require classes.
| > Only in Java, Eiffel, C++, and Smalltalk (not sure about Smalltalk
| > since I have never used or learned it).
| 
|  you can also remove C++ from the list... (Friend functions).

But C++'s object model is still class-based.  I kind of actually liked
Eiffel's acces modifers.  C++ attempts a similar thing with Friend
function/classes but isn't quite as flexible.

I really like python's treament of everythin as first-class objects,
including function and class objects.  This makes it very cool to have a
dictionary of options (ie user input) for keys and class objects as
values.  Then a simple dictionary lookup from the user's input to get
the proper class object gives a nice polymorphic flow to the code.  I
used this (from Jython) to replace a long (ugly IMO) switch in Java code
to get the right behavior.  The situation was a menu for the user to
pick a test to run on the code.

It seems that we are mostly in agreement wrt OO.
-D