Loading ...
Sorry, an error occurred while loading the content.

JSON as a function parameter

Expand Messages
  • TCQ
    Greetings fellow JSON Lovers. I have been spending building a great deal of complex Product/Business workflow wizards and tools that are required to handle
    Message 1 of 4 , Aug 20, 2005
    • 0 Attachment
      Greetings fellow JSON Lovers.

      I have been spending building a great deal of complex Product/Business
      workflow wizards and tools that are required to handle tons of data
      and great deal of client side functionality.

      As a result, many functions and methods have gotten to require longer
      and longer set of parameters. The worst case yet is about 12
      parameters with some being optional. In these cases, the calling code
      gets more and more un-readable as you add args. Also optional entries
      must have null ("") values all over the place making for unneeded code.

      With my ultimate goal of having clean and maintainable code, I have
      started using using json to pass the parameters and data to the
      function/method.

      before:
      . obj.init(
      . . "My Type","My Name","n",true, false...
      . )

      after:
      . obj.init({
      . . type: "My Type", name: "My Name", rev: "n", doThis: true, doThat:
      false...
      . })

      Has anybody conducted or seen tests on the performance of this json
      method vs regular calls.

      [Notes]

      [Advantages]
      . Cleaner calling code
      . Flexible calling API
      . Somewhat cleaner callee code from visually implied namespace (j.arg1)
      . Tightened API calls:
      . . obj.myMethod = function Obj_myMethod(j){// (singleton)
      . . . . if(!isJSON(j)){debugErr("j must be a JSON")}
      . . }
      . JSON variable can be easily passed around

      [Disadvantages]
      . Overall size of the calling code is a little larger
      . Hit on interpreter performance to parse json
      . Null value parameter assertions require additional code

      .:JsD:.

      (dupe post from comp.lang.javascript ... just discovered json group
      today :)
    • Ronny Hanssen
      In general my experience on this matter is only positive. I ve had *no* negative effects or side effects whatsoever. Specific comments inlined below. TCQ
      Message 2 of 4 , Aug 20, 2005
      • 0 Attachment
        In general my experience on this matter is only positive. I've had *no*
        negative effects or side effects whatsoever.

        Specific comments inlined below.

        TCQ wrote:
        (...snip...)
        > [Notes]
        >
        > [Advantages]
        > . Cleaner calling code
        > . Flexible calling API
        > . Somewhat cleaner callee code from visually implied namespace (j.arg1)
        > . Tightened API calls:
        > . . obj.myMethod = function Obj_myMethod(j){// (singleton)
        > . . . . if(!isJSON(j)){debugErr("j must be a JSON")}
        > . . }
        > . JSON variable can be easily passed around

        I'd like to add how easy it is to have backwards compatibility when
        upgrading the API. (Maybe that's what you meant with the flexible
        calling API? I interpreted that to be the advantage to mix the order as
        you like.
        Also - this might be personal preference only, but I like the way the
        calls are self-explanatory, instead of wondering what the third or
        fourth integer argument is actually doing.

        >
        > [Disadvantages]
        > . Overall size of the calling code is a little larger
        > . Hit on interpreter performance to parse json

        You are talking about code in a javascript interpreter/engine, right?
        Because then you'd have *no* extra JSON parsing. JSON *is* javascript,
        and what actually happens is that an object is created to hold your
        arguments. And this object creation is the extra fingerprint. This might
        be what you mean, I just wanted to be clear that we are not talking
        about JSON parsing, we are talking about creating a javascript native
        object. However, I've seen no comparisons on these two different ways of
        passing arguments. That would be easy though. Any parameters added - be
        it a string, a number, bool or whatever - will take time to get their
        own memory slot assigned anyhow. The last part is the creation of the
        container-object, and possible any differences in memory allocation
        depending on whether the args are local or a part of an object (might be
        some other situations. Someone more into the details of the javascript
        engine might be able to shed light on that.

        > . Null value parameter assertions require additional code

        I am not sure what you are referring to. Is it the fact that you in the
        function declared cannot use an arg.property, unless it has explicitly
        been given a value? In the later versions of javascript all you need to
        do is:
        if (arg.myprop) [action]

        which is exactly the same code you could use if it was indeed null. So
        there's no difference there. However. If you are using nested JSON
        structures, with subobjects, the above test is not good enough. If you
        have arg.myobj.myprop, then if the arg doesn't pass arg.myobj then you
        cannot test arg.myobject.myprop, then you have to something like this:
        if (arg.myobj && arg.myobj.myprop) [action]

        DISCLAIMER: It's about 6 months since I last programmed any JS, so there
        might be some issues regarding the techniques above. Don't expect all
        samples to work without correction :)

        Regards,
        ------------------------------------------------------------------------
        /*Ronny Hanssen*/
      • Michal Migurski
        ... I use this method in my PHP work pretty often, especially when consuming GET or POST vars, or instantiating objects which have a mix of required and
        Message 3 of 4 , Aug 20, 2005
        • 0 Attachment
          > [Advantages]
          > . Cleaner calling code
          > . Flexible calling API
          > . Somewhat cleaner callee code from visually implied namespace
          > (j.arg1)
          > . Tightened API calls:
          > . . obj.myMethod = function Obj_myMethod(j){// (singleton)
          > . . . . if(!isJSON(j)){debugErr("j must be a JSON")}
          > . . }
          > . JSON variable can be easily passed around
          >
          > [Disadvantages]
          > . Overall size of the calling code is a little larger
          > . Hit on interpreter performance to parse json
          > . Null value parameter assertions require additional code

          I use this method in my PHP work pretty often, especially when
          consuming GET or POST vars, or instantiating objects which have a mix
          of required and optional arguments. Some languages have explicit
          support for this sort of use, such as Python:

          def f(**kwargs):
          print kwargs['msg']

          # prints "hello world"
          f(msg='hello world')

          Ronny is right - there is no JSON parsing overhead in what you're
          doing, because you are passing plain old javascript object literals.
          http://developer.mozilla.org/en/docs/
          Core_JavaScript_1.5_Guide:Literals#Object_Literals

          ------------------------------------------------------
          michal migurski- contact info, blog, and pgp key:
          sf/ca http://mike.teczno.com/contact.html
        • George
          That is valid javascript code, as pointed out already, object literals. You can also create the object first, then pass it to the method: args = {type: My
          Message 4 of 4 , Aug 20, 2005
          • 0 Attachment
            That is valid javascript code, as pointed out already, object literals.

            You can also create the object first, then pass it to the method:

            args = {type:"My Type", name:null, rev:3, doThis:true};
            obj.init(args);


            --- In json@yahoogroups.com, "TCQ" <despam2004@y...> wrote:
            >
            > before:
            > . obj.init(
            > . . "My Type","My Name","n",true, false...
            > . )
            >
            > after:
            > . obj.init({
            > . . type: "My Type", name: "My Name", rev: "n", doThis: true, doThat:
            > false...
            > . })
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.