On Wed, Apr 06 2011, Sidu Ponnappa wrote: >> Why do you want to create a class that doesn't create itself when called? > It's interesting this came up today - we were just arguing about this > at work on Monday. Some of my colleagues are of the opinion that this > is a Bad Thing and should never be done. I agree that while it's a bad > thing, there are rare occasions where it's still the most elegant > solution. After all, the allocator is just a factory - I don't see why > it should be treated as something special. As long as you have some > rules (like the rules for overriding the default equality method in > any OO language) you should be fine.
Yup. It is a factory and seeing it that way makes things clearer. However, it's one of those things that comes after messing with stuff for a while rather than something taught. > FWIW, these are my two rules: > * Don't do it unless there's no other sensible option. Like, absolutely > nothing else exists that is more elegant. I'm not "against" it. Overriding the __new__ method in python (i.e. the allocator) is often done while metaclassing to create speciallised objects. e.g. with custom accessors and stuff like that. However, like you said, it's a rule to be broken only when you know what you're doing. > * Ensure that you're returning a sub-class of the class where you're > implementing a custom allocator. No returning a different type, and > definitely no returning a nil. This makes sense. Liskov's principle would be honoured and things would be more predictable. > Here's one occasion where I had call to do this. See > > https://github.com/kaiwren/wrest/blob/master/spec/wrest/native/response_spec.rb#L41 > > for the spec and > > https://github.com/kaiwren/wrest/blob/master/lib/wrest/native/response.rb#L43 > > for the code. It's in Ruby, though. So you'll actually build a redirection instead of just a response for the 3xx status codes? I don't know Wrest and the rest of the code well enough to have an opinion on being right or wrong but it does illustrate your point though. [...] -- _______________________________________________ BangPypers mailing list [email protected] http://mail.python.org/mailman/listinfo/bangpypers
