Python vs. Io

Kylotan kylotan at hotmail.com
Tue Feb 3 00:48:51 CET 2004


"Donn Cave" <donn at drizzle.com> wrote in message news:<1075702864.490920 at yasure>...

> But if the feed function had been outside this hierarchy, we would
> be writing instead
>    feed(parser, data)
> 
> Why isn't that a violation of the object abstraction?  Simply make
> it generic and let the above notation serve in either case, and you
> don't have to know the implementation in order to use it.
> 
> Now I'll admit that this level of abstraction does pose a problem
> with scope and legibility, and that might have to be addressed.
> My point though is that we already accept this problem as a cost
> of doing OO business, so it's kind of surprising to me that OO
> languages invariably stop there, instead of going all the way.
> They'll proudly declare that `everything is an object', but don't
> wonder about the distinction between functions and methods.

>From my point of view (C++ and general OOP background) this comes down
to access privileges and the visible implications of the code.

feed(parser, data) implies that feed has equal access privileges to
both parser and data, and that parser and data are unchanged by the
operation. It's vaguely saying "I want something to happen based on
parser and data".

parser.feed(data) implies that feed has enhanced access privileges to
parser compared to its access to data. In particular it implies that
parser maintains some sort of state and that data is just an argument.
It's saying "I want parser to do something based on data".

In Python this is mainly just a semantic issue since you don't have
the rigorous public/private/protected system that C++ does. But it
does usually provide useful hints as to what the main object in any
given interaction is. (ie. distinguishing between controller and
entity classes, in UML terms.) Of course, it's entirely a religious
matter in much the same way as arguing for a clear distinction between
functions and subroutines would be. Just different ways of looking at
it to suit different thought processes.

-- 
Ben Sizer



More information about the Python-list mailing list