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

Re: [json] JSON as a function parameter

Expand Messages
  • 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 1 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 2 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 3 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.