Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!nerim.net!novso.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAMjeLr_pr2OPYzR=tQgkV8ekk37_Uif3g+8nGzPVUY5Kd7+v7g@mail.gmail.com>
References: <15ba0011-bbf1-42f7-b3ea-1c1d4b70e56b@googlegroups.com> <51c66962$0$29999$c3e8da3$5496439d@news.astraweb.com> <20130623133546.GA2308@capricorn> <mailman.3729.1372004188.3114.python-list@python.org> <51c723b4$0$29999$c3e8da3$5496439d@news.astraweb.com> <51C74D6E.6030200@rece.vub.ac.be> <CALwzidnf0h3GUdeQFjwwhMYXXJVyOCFuE-kc564k-j_1icoC_g@mail.gmail.com> <CAMjeLr-Kqg1uu+CSn+jKXLF7bQHrci06WewgJHF+b+AwZwQAaw@mail.gmail.com> <CALwzidk2dsJz1eh0PhGdGR1Nj=atbuG09vMXjbPOf3k=LsoB2Q@mail.gmail.com> <CAMjeLr_pr2OPYzR=tQgkV8ekk37_Uif3g+8nGzPVUY5Kd7+v7g@mail.gmail.com>
From: Ian Kelly <ian.g.kelly@gmail.com>
Date: Tue, 25 Jun 2013 17:07:05 -0600
Subject: Re: What is the semantics meaning of 'object'?
To: Python <python-list@python.org>
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3861.1372201668.3114.python-list@python.org>
Lines: 43
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:49207

On Tue, Jun 25, 2013 at 4:38 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
> Sorry my last message got sent prematurely.  Retrying...
>
>> So instead of super(), you would have sub()?  It's an interesting
>> concept, but I don't think it changes anything.  You still have to
>> design your classes cooperatively if you expect to use them with
>> multiple inheritance.
>
> Yes, and let new instances of the child classes automatically ensure
> the contracts of the parent classes -- managed within the Python
> interpreter, not the developer.

It sounds like you want to be using Eiffel, not Python.

> As for sub(), I suppose it could be called delegate().

You can call it that, but you'll just be muddying the waters since
there's already a perfectly good pattern by that name, which involves
having multiple distinct objects and has nothing to do with
inheritance.

> The issue of classes cooperating isn't as big as it seems, because
> since you're working now from a useful, agreed-upon common base (the
> non-negotiable, but also non-arbitrary) machine types, you're now all
> (the python and ideally the *object* community) speaking the same
> language.   Who's going to argue about integers (as the atomic type)
> and sets (as the most basic grouping type) being THE common set of
> bases for everything else?  I mean, it doesn't get anymore ideal and
> pure than integers and sets.  Combining integers with sets I can make
> a Rational class and have infinite-precision arithmetic, for example.

I don't see how this solves anything.  At some point you have to be
able to add methods and attributes to your objects.  For example, your
Rational class is going to need some sort of "reduce" method to reduce
a Rational instance to lowest terms.  That's not a method that belongs
on an integer or set type.  If you can't add functionality, then all
you will ever have are integers and sets, and if you can add
functionality, then what difference does it make what your fundamental
base class is?

>From a programming perspective, I think it is proper that "object" is
the most fundamental base class, because all it has is identity.
Integers and sets add other functionality on top of that.