Namespace conflict with model methods

[gbuesing]

My User model recommends :places, but it already has an Active Record association for recommended_places, so I am forced to access Recommendable recommendations via:

user.send :recommended_for, Place

... which is a bit clunky. To avoid this, and other potential namespace collisions for existing model methods, I suggest supporting an optional recommendable_ prefix on Recommendable finder methods, e.g.:

user.recommendable_recommended_places

Would be easy to implement -- we'd just need to add an optional check in the method regexes for the namespace. Existing finder methods would still work -- you'd only need to prepend recommendable_ if you had a namespace issue.

[Nuru]

I have a similar but different name collision: some of my models already implement a recommendable? function that of course has a different meaning. You might want to look into how elasticsearch-rails handles potential name collisions and do something similar.

[davidcelis]

@Nuru Thanks for that link; I like that idea a lot. I'll take a look at implementing something similar soon. In the meantime, I'm glad you found a workaround @gbuesing!

[Nuru]

@davidcelis There's also the issue that if a ratable class is within a module, e.g. Product::Song, then the generated methods are not callable directly because they contain a /. One ends up having to use user.send('recommended_product/song'). Since these all end up calling recommended_for anyway, perhaps make that public instead of private. (While you are at it, you could make liked_ids_for(klass) public, too.)

[davidcelis]

I completely forgot about that issue! 😳