On Wed, Aug 12, 2009 at 00:52, Johannes Janssen<[email protected]> wrote:
[...] > I propose a patch for resolve(), which makes to major changes: > > User defined resolve function: [...] This is a good idea to address a real need. The thing is that I am not sure this is the best approach to solve the problem. What I've been using for my last project using elixir (a few months ago) is a custom EntityCollection class (inheriting from the default one) overriding the resolve method. We could probably add a hook in the default one so that it's easier to provide a custom method though I'm unsure whether it's worth it. My main concern about your approach is that I fail to see any usecase where setting the resolve method on a per-entity basis instead of per-collection makes sense. I might be lacking imagination though. Can you provide an example of such a situation? > Resolving the module path: > > My second idea is to change the way module paths are resolved by > default. Basically I would like to have tow ways to do that: relative > and (pseudo) absolute paths. An relative path starts with a dot and is > relative to the entity which is passed to resolve(key, entity) or better > to entity.__module__. Therefore it is only possible to use relative > paths when an entity is passed to resolve(). > The absolute path instead must not start with a dot. They are by the > default real absolute path (that means they are relative to __main__). > Using "resolve_root" option you can change this. Good ideas. I didn't think of those. I was using an alternate resolve method to emulate your "resolve_root" option but since it's probably a common use case, it's a nice idea to have such an option. > (What I said about module paths (not) starting with a dot is not quite > true. "..foo.bar" will still be an abs path and while "...foo.bar" is an > rel path. Got it? Have a look at the example!) Hmmm, I lost you there. The relative path idea seems good. Using a leading dot seems good but this ".. is a no-op" idea seems artificial and very different to how python's relative imports work, hence very confusing. Honestly, I don't understand what's the point. > Thanks for reading this far ;) What do you think about it? Please have a > look at the patch, which is against svn trunk r455. Has this patch any > chance to get into elixir? Sure. Well, the patch as it is now probably won't but some modifications to address your issues will. They won't go into 0.7 which is already months (years?) late but will be in 0.8. I can't promise when that will come out though, but it will. > For backwards compatibility you might give users the > possibility to switch back manually to old behavior and give them a > deprecation warning (for a few versions if there are to be more;)). I don't want to break backward compatibility for the entity resolving code *again* (already broke it from 0.5 to 0.6) just yet. But providing a built-in alternate method wouldn't hurt. And if people use it a lot, we can still make it the default later on. -- Gaëtan de Menten http://openhex.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SQLElixir" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlelixir?hl=en -~----------~----~----~----~------~----~------~--~---
