Support for inheritance. -- March 10, 2007

On Fri, 2007-03-09 at 18:14 +0000, Chris MacRaild wrote:

On Sat, 2007-03-10 at 00:33 흝㐑?귗䂺艷낮譞:

On 3/9/07, Chris MacRaild <c.a.macraild@xxxxxxxxxxx> wrote:

On Fri, 2007-03-09 at 17:38 흝㐑?귗䂺艷낮譞:

Looking back at the example you gave:

class Data:
   ...
Data = Data()

in the data module, then everywhere else:

from data import Data as relax_data

This is very similar to Gary's suggestion and is conceptually the same
as the code in the repository.  I just realised that the example is in
fact a singleton design pattern.  The Data class is being overwritten
by the single Data class instance reference.  Then every time Data is
imported, a reference is given by the module rather than the class
which no longer exists in the module namespace.  Although the
implementations are slightly different, Gary's singleton suggestion
(https://mail.gna.org/public/relax-devel/2007-03/msg00020.html,
Message-id: <45EFCABC.9040905@xxxxxxxxxxxxxxx>), your suggestion Chris
(https://mail.gna.org/public/relax-devel/2007-03/msg00013.html,
Message-id: <1173263918.8066.238.camel@mrspell>), and mine
(https://mail.gna.org/public/relax-devel/2007-03/msg00012.html,
Message-id: 
<7f080ed10703070006s309a1e1do38e621f48d8f6d9e@xxxxxxxxxxxxxx>)
are formally identical, each returns the reference to the single Data
instance.


I would argue that they are functionally identical, but formally quite
different. Quite apart from the differences in terms of __init__ that I
mentioned earlier, it is usefull to look at the differences in terms of
what a user will see if they examine a client module. In the current
implimentation, the user will see

relax_data = Data()

and wrongly assume that the client module has created its own instance
of Data, because that is what the code says. As they examine the rest of
the code, they are likely to be at a complete loss as to how that
instance communicates with the rest of the program, because each module
appears to create an independent instance. In my proposal, the user will
see

from data import Data as relax_data

and realise that each client module imports one and the same data object
every time.

It is this clarity of code and simplicty of concept that I am trying to
argue for here, not any functional difference.


Actually, the 'from data import Data as relax_data' is potentially
more confusing as you wouldn't normally expect a reference to an
instantiated class to be returned when importing (instead of the class
itself).


I'm not at all clear why importing an instance would be unexpected.
import simply makes any object of one module available to some other
module, it doesnt care what the object happens to be. That flexibility
is a design feature of the language - why would anyone expect developers
not to make use of it?


You could make use of the reference import but it is more standard to
import classes rather than class instance references.  You then have
access to the class namespace (and the instance namespace after
instantiation).  Hence the object supports inheritance and you can
create derived classes if you wish to extend the abilities of the object
and create new singleton objects with different properties.

Edward

Support for inheritance.

Header

Content

Related Messages