Russ P. a écrit :
On Jan 13, 7:32 pm, "James Mills" <prolo...@shortcircuit.net.au>
wrote:
On Wed, Jan 14, 2009 at 1:18 PM, Russ P. <russ.paie...@gmail.com> wrote:
Yes, but the fact that you can approximate OO programming in a
particular language does not make that language object oriented. You
can approximate OO programming in C, but that does not mean that C is
an OO language.
Wrong. Not having strict and enforced access control 9_NOT_ encapsulation)
(Please stop confusing the two) is not a strict requirements of the OO model.
I think you are the one who is confused. Part of the problem here is
that the term "encapsulation" has at least two widely used meanings
(in the context of programming). In one sense, it just means grouping
data and methods together. In another sense, it means restricting the
client's access to data or methods.
The second is named "data hiding". And while it's a mean to _enforce_
encapsulation, it is not encapsulation by itself. Encapsulation is about
making clear what's part of the public interface and what's
implementation detail - IOW, it's about decoupling client code from
implementation. Nothing in this _requires_ data hiding.
Someone earlier on this thread
tried to claim that the first meaning applies to OOP, but Wikipedia
(and many other sources) say just the opposite.
You can choose to trust everything you read on wikipedia. You can...
wrt/ what's OO, the only commonly accepted definitions are:
1/ objects are defined by an identity, a state and a behaviour
2/ objects communicate by sending messages to each other
People here are trying to claim that the leading underscore
conventions used with Python are essentially equivalent to
encapsulation. That is nonsense, of course.
Your POV.
But the point is that if you don't like
encapsulation,
I do like it. What I don't like is useless language-enforced restrictions.
then by definition you don't like OOP. You may like
certain features of OOP, but you don't like it in general. That's
about all their is to it.
And by the way, please don't bring up the canard that I am some kind
of OO zealot. I think OO is overrated, and I don't Java, in part
because it forces everything to be OO. The issue here is not my
personal opinion of OOP. This issue is one of widely accepted
definitions within the OO community.
Another widely accepted definition within the OO community is that C++
is an OO language because it has classes and data-hiding, and that
Javascript is not because it has none of them.
Remember that it is a model and not a strict set of requirements that
programming
languages must implement.
Of course it's not a "requirement that programming languages must
implement." It's only a requirement if they want to be OO languages.
Neither. The only requirements for being an OOPL are stated above.
In fact, Python borrows features from the Functional Paradigm. Does this
make it a Functional Language ? No. Why ? Because one of the clear
requirements of the Functional Paradigm is that functions cannot have
side affects.
So I can claim that Python is not strictly object oriented
You can claim it, yes. OTHO, I can claim that Java is not strictly
object oriented since it has non-object types.
In both cases, this is just plain meaningless. There's no closed,
well-defined theory, no mathematical model behind "OO" (like there are
for functional programming or for the relational model). So you just
can't apply "strictly" to OO. It's just nonsense.
until it
gets encapsulation (in the sense of data hiding). That is simply a
fact, and no amount of pleading or obfuscation will change it.
IOW : "this is the HolyTruth(tm), because I said so". Sorry, won't work.
In fact this is true, C can be seen as an programming language
that has features of the OO model.
Yes. And FWIW, there are OO libraries and programs written in plain C.
Ever heard of GTK+ ?
I think one of the things you guys are missing out
here is that there are really only two Paradigms
or Machines. Functional and Imperative. And guess
what ? As it turns out we can implement functional
machines that run on top of imperative ones!
Should Python get true encapsulation? I don't know. Maybe
encapsulation cannot be added without excessive overhead or without
compromising other more important aspects and features of the
language. But I do know that not having encapsulation is a limitation
to the use of Python for good software engineering.
For a somewhat partial definition of "good software engineering". Mine
is that anything that leads to a correct, robuste and maintainable
program is good engineering, anything else is not. From this POV, and
given the proven fact that the bug/LOC ratio is nearly constant whatever
the language, anything that adds accidental complexity makes the program
less robust and less maintainable, and as such is _not_ "good software
engineering". Sorry for being pragmatic !-)
I may be in the
minority in the Python "community" on this one, but I am apparently in
the majority in the OO programming "community."
Again, stop confusing terminology.
Should Python get strict and enforce access control
of object members ? No. Why ? I can think of several
reasons.
Give me one use-case where you strictly require
that members of an object be private and their
access enforced as such ?
You're kidding, right? Think about a ten-million line program being
developed by 100 developers.
And ? Except that this code surely needs urgent surgery (sorry, I meant
refactoring), I don't see what the size of the project or the team has
to do with it. You'll find successful "monster" projects written in
languages that are even more permissive than Python (C anyone ?), and
failed "monster" projects written in highly unpermissive languages like
Java or ADA.
--
http://mail.python.org/mailman/listinfo/python-list
