Specify ViewDefinition functions as members

[GoogleCodeExporter]

ie:

class MyViewDef(ViewDefinition):
    map = """
    function(doc) {
        emit(null, 1);
    }"""

Original issue reported on code.google.com by paul.jos...@gmail.com on 9 Mar 2009 at 10:29

[GoogleCodeExporter]

Couldn't manage to open the issue with the patch attached, so here it is. 
Hopefully.

Original comment by paul.jos...@gmail.com on 9 Mar 2009 at 10:30

Attachments:

• view_def_class_members.patch

[GoogleCodeExporter]

I'm not entirely sure the advantage in syntax is so big:

myview = ViewDefinition('mine', 'myview',
   map_fun = """
   function(doc) {
        emit(null, 1);
    }"""
)

What am I missing?

Original comment by cml...@gmx.de on 17 Mar 2009 at 10:07

[GoogleCodeExporter]

Hmmm.

Corresponding examples:

class MEDView(ViewDefinition):
    def __init__(self):
        super(MEDView, self).__init__("lookup", "med")
    map = """
    function(doc) {
        if(doc.type != "med") return;
        emit(doc.source, doc._rev);
    }"""

myview = ViewDefinition('lookup', 'med',
    map_fun = """ 
    function(doc) {
        if(doc.type != "med") return;
        emit(doc.source, doc._rev);
    }"""
)

Hmm. When written like that its not as much of a difference. Writing the map 
functions inline like that hadn't 
occurred to me when I was writing the patch. Its definitely subtle, but the 
inline version kind of bugs me. Not 
to mention that views either need to be redefined in code, or treat instance 
variables as globals which also 
bugs me a bit. But pragmatically I can't point at anything and say "won't work 
in situation X"

Original comment by paul.jos...@gmail.com on 17 Mar 2009 at 10:54

[GoogleCodeExporter]

I'm closing this, I don't think there's any/enough benefit compared with the 
current interface.

Original comment by cmlenz on 29 Jun 2009 at 1:44

• Changed state: WontFix