Python vs. Io

[Donn Cave]

In article <153fa67.0402021548.6c5e394 at posting.google.com>,
 kylotan at hotmail.com (Kylotan) wrote:

> "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.

> 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.

I think that's what I meant by violating the abstraction.
Aren't these issues only for the author of the parser?
Why do you want to know what privileges feed has with
one parameter vs. another?  Isn't it enough that it works?

   Donn Cave, donn at drizzle.com