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

Re: [caplet] Fwd: [Caja] secure string interpolation in javascript

Expand Messages
  • Mike Samuel
    ... Fair enough. It s tough to implement sophisticated and efficient parsers in javascript, but I m sure that it s worthwhile in some contexts. Perhaps if
    Message 1 of 6 , Jan 30, 2008
    • 0 Attachment
      On 30/01/2008, Freeman, Tim <tim.freeman@...> wrote:
      >
      >
      >
      >
      >
      >
      >
      > Seems like a good idea.
      >
      > As a user, I'd rather see the SQL problem solved right by having a parser that's more sophisticated than a finite state machine than to not have it solved right.

      Fair enough. It's tough to implement sophisticated and efficient
      parsers in javascript, but I'm sure that it's worthwhile in some
      contexts.

      Perhaps if StringInterpolation.interpolate instead of taking a
      contextScanner and an escaper published events like ('Literal, "foo")
      or ('Substitution bar) to an interpolationEventSink then the current
      contextScanner&escaper could be built on top of it, or an
      implementation could route those events to an AST builder instead.


      > In the paper, every result from Template is immediately passed to open. Did I miss one? If not, then why make people write both? I'd expect to have "openedTemplate(...blah...)" as an abbreviation for "open(Template(...blah...))", although maybe a name shorter than "openedTemplate" should be selected.

      You didn't miss anything. This is an implementation detail leaking
      out through the API.

      The `Template` part converts the "Hello $name_of_planet!" to "new
      StringInterpolation(['Hello ', name_of_planet, '!'])" and the `open`
      part is really `eval` in disguise which parses the string and invokes
      the constructor. Thus, two function calls are needed for this macro
      expansion to work in javascript.


      > -----
      > Tim Freeman
      > Email: tim.freeman@...
      > Desk in Palo Alto: (650) 857-2581
      > Home: (408) 774-1298
      > Cell: (408) 348-7536
    • Monty Zukowski
      ... ... Now that ANTLR 3 has a retargetable backend, this might be a good motivation to get a JavaScript backend implemented. ActionScript, perl, Python &
      Message 2 of 6 , Feb 1, 2008
      • 0 Attachment
        On Jan 30, 2008 2:42 PM, Mike Samuel <mikesamuel@...> wrote:

        > > As a user, I'd rather see the SQL problem solved right by having a parser
        > that's more sophisticated than a finite state machine than to not have it
        > solved right.
        >
        > Fair enough. It's tough to implement sophisticated and efficient
        > parsers in javascript, but I'm sure that it's worthwhile in some
        > contexts.
        ...

        Now that ANTLR 3 has a retargetable backend, this might be a good
        motivation to get a JavaScript backend implemented. ActionScript,
        perl, Python & Ruby are all implemented as examples to draw upon. See
        antlr.org

        Monty
      Your message has been successfully submitted and would be delivered to recipients shortly.