[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
