Subject: Re: Using an inner class for custom Manager in magic removal branch - msg#00215

[current sample with defined classes and used objects]

>The above feels a little clumsy to me. Here's my proposed alternative:

[sample with inner class]

Uhm - in what way is nowadays defining classes and using them "clumsy"?
Thought that's what OO is all about. The beast is named "removing the
magic" for a good reason, so why throw in another "magic" (one that
turns a scoped class definition into a - differently named! -
attribute)? And why should we do a full round again on the discussion
about wether we want managers the way we already decided in the
previous round to have them? Actually this discussion sounds clumsy ;-)

Sorry, but I am -1 on this change. Several reasons:

- multiple managers make it possible to have different ways to access
your data. Don't just think "multiple managers to the same storage" as
it is now, think "multiple managers to different - maybe even
technically different - storages". One thing I can see done with
multiple managers would be a way to define managers that link to
specific databases and so have a model definition where you have one
manager attaching to your PostgreSQL database and another attaching to
your RDF storage.

- managers that are decoupled from the model class could be reused in
multiple models. For example I have a model with four quite similar
tables - even though they carry different payload, they do carry
similar basic structure for identification. They could definitely share
the same manager definition that would just do basic selecting (like
limiting to objects from the current site).

- constructed managers become possible due to the fact that
instantiation is explicit - you could have your manager class accepting
parameters in its __init__ and so parameterized a shared manager
definition (or used multiple but differently parameterized instances of
the same manager class).

Oh, and I strongly dislike the handling of an attribute named 'objects'
you propose. That's backwards into the discussion we already had. This
"you have to rename your attribute objects_ because we clobber your
namespace and won't allow you to reclaim it" felt like a hack to me
then and feels like a hack to me now. I am definitely -1 (it's more
like -2, if that would exist) on changing that to your proposal. The
current idea of explicitely instantiating and naming managers is much
cleaner.

Actually in simple cases you won't have to instantiate managers at all
- there will be a default manager created behind the scenes, IIRC. It's
just needed in those cases where you _do_ need explicit managers. And
one really typical scenario would be a situaiton where someone has a
basic relation in all his tables that should be filtered - like for
example ManyToMany relations to the Sites table. In that case you set
up one manager class that adds that filter and just use that manager
class in your models. This scenario would be much clumsier with having
to define a inner class - you would have to subclass the shared manager
class in every inner class of the model. And sorry, but stub inner
classes that magically instantiate attributes with a different name
just look clumsier to me than simple attribute assignements where you
use the exact same named attribute as you assigned ...

bye, Georg