I have about a dozen reified request properties on an application. They're great.
It's entirely possible to abuse it – but that's what coding standards are for. We have about a dozen objects on our request. They could be consolidated into a smaller, nested, hierarchy... but they're all "request specific". A few of our properties are documented as "public" – and ensured to work across our application. A few of them are documented as "private" -- they're enabled(registered) by a single component that may or may not be enabled. No code outside that component can touch it. (for example, our caching layer and some environment-specific debugging). Pyramid's implementation of add_request_method + reify meant there's virtually no overhead during runtime (95% of them are never called during a request). We could have created a singular "api" namespace, but then we would need to re-implement the add_request_method for registration and management. That seemed onerous. Looking at the example you gave, since you're doing this on a framework, I think it would be a bit different. Personally, I would create a reify'd '.ringo' property on each request for the "public api" (and possibly use `_ringo` for non-public/core usage). I would have that property be a request-specific context object. `request.features.FOO` could be a way to handle the `request.registry.settings` data. functions could then either rely on `request.ringo` or be invoked with the context object as an argument. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
