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

Re: [caplet] Mutability of functions in ECMAScript

Expand Messages
  • David-Sarah Hopwood
    ... You re right, I don t know what I was thinking of. Making functions immutable in ES3.1/4 is not practical. -- David-Sarah Hopwood
    Message 1 of 13 , Apr 6, 2008
    • 0 Attachment
      Kris Zyp wrote:
      >> If functions were immutable, joining would be a transparent optimization.
      >> Apart from the theoretical potential for backward incompatibility, why
      >> isn't this a better solution? I suspect that very few programs rely on
      >> mutating actual functions
      >
      > Really? It is actually even used in ADsafe's core library. Mutating functions
      > is pretty core functionality, and AFAIK it is necessary to form multi-level
      > prototypical inheritance. If I want object A to delegate/inherit from
      > preexisting object B, I must create a function and set the prototype (a
      > mutation) to object B and then construct with that function. See the beget
      > function in ADsafe. I would extremely surprised if function mutation is less
      > common than some of the things that the ES3.1 and ES4 groups have to maintain
      > for backwards compatibility (the latest was being able override the Error
      > built-in). I have used it other situations as well, like using storing a
      > list of listeners on a AOP advising function. AOP style event listeners are
      > common in popular JS libraries as well, and I would imagine they use such
      > techiniques as well.
      >
      >> (as opposed to creating mutable objects that are
      >> callable as functions, or mutating Function.prototype).
      >
      > How do make a regular object callable?

      You're right, I don't know what I was thinking of. Making functions
      immutable in ES3.1/4 is not practical.

      --
      David-Sarah Hopwood
    • Mark S. Miller
      ... I d guess it was to enable the optimization that David was suggesting. But I don t actually know. -- Cheers, --MarkM
      Message 2 of 13 , Apr 6, 2008
      • 0 Attachment
        On Sun, Apr 6, 2008 at 12:30 PM, Mike Samuel <mikesamuel@...> wrote:
        > Does anyone know the rationale for putting joining in the spec in the first
        > place?

        I'd guess it was to enable the optimization that David was suggesting.
        But I don't actually know.


        --
        Cheers,
        --MarkM
      • Douglas Crockford
        ... optimization. ... functions is pretty core functionality, and AFAIK it is necessary to form multi-level prototypical inheritance. If I want object A to
        Message 3 of 13 , Apr 8, 2008
        • 0 Attachment
          --- In caplet@yahoogroups.com, "Kris Zyp" <kris@...> wrote:
          > > If functions were immutable, joining would be a transparent
          optimization.
          > > Apart from the theoretical potential for backward incompatibility, why
          > > isn't this a better solution? I suspect that very few programs rely on
          > > mutating actual functions

          > Really? It is actually even used in ADsafe's core library. Mutating
          functions is pretty core functionality, and AFAIK it is necessary to
          form multi-level prototypical inheritance. If I want object A to
          delegate/inherit from preexisting object B, I must create a function
          and set the prototype (a mutation) to object B and then construct with
          that function. See the beget function in ADsafe.


          beget is a workaround for the lack of an operator that produces an
          object with a delegation relationship. It should not be interpreted as
          proof that mutable functions are desirable.
        Your message has been successfully submitted and would be delivered to recipients shortly.