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 <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]>), your suggestion Chris > > > > (https://mail.gna.org/public/relax-devel/2007-03/msg00013.html, > > > > Message-id: <[EMAIL PROTECTED]>), and mine > > > > (https://mail.gna.org/public/relax-devel/2007-03/msg00012.html, > > > > Message-id: <[EMAIL PROTECTED]>) > > > > 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 _______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
