in reply to Re^3: patchable settings
in thread patchable settings

My reluctance is based on two things, both very minor; first, it means taking really short simple code and making it less so; second, it reduces the readability of the raw data.

It's your call; if you say so, I'll take what you have above and integrate it with my unpackVars/packVars (though I'd much prefer just to use the escape() and unescape() that are already there).

Replies are listed 'Best First'.
Re^5: patchable settings
by demerphq (Chancellor) on Sep 28, 2004 at 07:57 UTC

    it means taking really short simple code and making it less so;

    Except that less code is actually executed and there is less stack overhead.

    second, it reduces the readability of the raw data.

    How does it do that? The current mechanism uses url encoding to handle \W chars. This mechanism would leave everything alone except for =,& and %. (Pick three less common chars if you want... I did in the personal nodelet stuff.)

    Im not saying you should definatively do anything, im just arguing that my suggestion is sound. Im hoping others pipe up with their thoughts too (although really only people that use setting's will have any experience to guide their thoughts). My position is that making my proposed changes would make a lot of things more robust and easy to deal with and actually be a marginaly net gain in efficiency due to less code and faster encoding. I dont see why we would give up those benefits for what we have now given the relative costs.


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi

      Flux8


      I've put our cb conversation (unedited, so there's surrounding cruft) here for the nonce.