On 06/18/2014 08:08 AM, Marc Tamlyn wrote:
> Worth noting that Lookups now have exactly the same as_vendor API. The
> registration API simply allows you to overload the lookup table with a
> subclass rather than just monkeypatching.
> 
> This is harder here are the classes are used directly. We could provide
> an expressions registry I guess...

Am I missing something? It seems to me that the fact that Functions are
imported and used directly makes everything easier, and reduces the need
for monkeypatching compared to Lookups. If you need a Function in your
project (whether provided by Django or by a third-party library), and
the Function doesn't natively support the database backend you're using,
you can simply subclass it, add the appropriate as_vendor method, and
use your subclass.

I guess the case that isn't handled as nicely is where a third-party app
is itself doing the query and using the Function. In my experience, this
is much less common - I very rarely use third-party apps that define
models or perform queries themselves. Perhaps it's more common for
others. I suppose pushing implementation down to DatabaseOperations
would make this case a little easier to handle (at the cost of making
the above case harder - a custom database backend is a bigger deal than
subclassing a Function). Personally I think in this situation the
third-party app should make the querying behavior
extendable/overridable, or if all else fails you just monkeypatch the
Function it's using with the necessary as_vendor.

I may be missing something, but I don't see any need for / value in a
registration API for functions. Global registries should be a reluctant
last resort in API design.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53A1C9F9.3090701%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to