A question about function names

6 views
Skip to first unread message

Ivan Kleshnin

unread,
Sep 9, 2014, 5:00:48 PM9/9/14
to clojure...@googlegroups.com
Disclaimer: I'm new to Clojure and Monger. 

If I understand correctly find-maps, find-one-map and find-map-by-id are more convenient to use
than find, find-one and find-by-id (which return plain Java Objects) and one'll be using mostly them.

If so, wouldn't it be great to use shorter func names instead of longer by default?

I mean, as naive example:

find-maps -> find
find-one-map -> find-one
find -> find-native
find-one -> find-one-native

I think It's a beneficial to follow mongo docs and be able to use it in Monger API  (same params, same function names).
I would stick with that approach whenever possible.
Does that Java objects provide any use in real-world situations?

I suppose there is the reason behind current naming style, but I can't see it for now :(
Can anybody help me to undestand?

Michael Klishin

unread,
Sep 10, 2014, 2:20:14 AM9/10/14
to clojure...@googlegroups.com, Ivan Kleshnin
On 10 September 2014 at 10:09:03, Ivan Kleshnin (jabber...@gmail.com) wrote:
> > If so, wouldn't it be great to use shorter func names instead
> of longer by default?
>
> I mean, as naive example:
>
> find-maps -> find
> find-one-map -> find-one
> find -> find-native
> find-one -> find-one-native

This is only a few characters shorter for the first two, which are by far the most
commonly used. Are you suggesting us to break the public API after over 3 years because of
a few characters per function? 

If you are new to ClojureWerkz projects, we value backwards compatibility like few
other things:
http://blog.clojurewerkz.org/blog/2013/04/20/how-to-make-your-open-source-project-really-awesome/

> I think It's a beneficial to follow mongo docs and be able to use
> it in Monger API (same params, same function names).
> I would stick with that approach whenever possible.
> Does that Java objects provide any use in real-world situations?

The "real-world situations" notion is not very specific. We have to provide a way
to use Monger even if the scenarios are pretty extreme, e.g. you depend on
map entry ordering or your keys use characters that makes them invalid or unintentionally
namespaced keywords.

> I suppose there is the reason behind current naming style, but
> I can't see it for now :(

You're putting too much thought into this. The answer is "this is how things
were named at first, and nobody complained to date". Like it is for the majority of
software out there.

There *is* a reasonable amount of consistency in how things are currently named.

To sum it up: it just doesn't matter in the grand scheme of things.
--
@michaelklishin, github.com/michaelklishin

Ivan Kleshnin

unread,
Sep 10, 2014, 3:29:41 PM9/10/14
to clojure...@googlegroups.com
Ok, I've got it, thanks for the answer.

Sean Corfield

unread,
Sep 10, 2014, 8:59:49 PM9/10/14
to clojure...@googlegroups.com
You could always :refer and :rename these as part of your :require of the Monger namespace. Here's an example from our code at work that deals with image-resizer which has some long and less than intuitive function names:

            [image-resizer.rotate
             :refer [rotate-270-counter-clockwise-fn
                     rotate-90-counter-clockwise-fn]
             :rename {rotate-270-counter-clockwise-fn rotate-left,
                      rotate-90-counter-clockwise-fn rotate-right}]

That allows us to use rotate-left and rotate-right in our code.

Sean
signature.asc
Reply all
Reply to author
Forward
0 new messages