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

Re: [caplet] Mutability of functions in ECMAScript

Expand Messages
  • Kris Zyp
    ... 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
    Message 1 of 13 , Apr 6, 2008
    • 0 Attachment
      > 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?
       
      Kris
       
       
       
      ----- Original Message -----
      Sent: Sunday, April 06, 2008 9:17 AM
      Subject: Re: [caplet] Mutability of functions in ECMAScript

      Mark Miller wrote:
      > On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@sitepen. com> wrote:
      >> AFAIK, no implementation has ever actually done this "joining", and I
      >> believe ES3.1 and ES4 will very likely dissallow joining to prevent it from
      >> ever happening in the future.
      >
      > Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
      > this regard. No joining.

      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 (as opposed to creating mutable objects that are
      callable as functions, or mutating Function.prototype) .

      --
      David-Sarah Hopwood

    • Mike Samuel
      Does anyone know the rationale for putting joining in the spec in the first place? mike
      Message 2 of 13 , Apr 6, 2008
      • 0 Attachment
        Does anyone know the rationale for putting joining in the spec in the first place?

        mike




        On 06/04/2008, Mark Miller <erights@...> wrote:

        On Sat, Apr 5, 2008 at 9:09 PM, Kris Zyp <kris@...> wrote:
        > AFAIK, no implementation has ever actually done this "joining", and I
        > believe ES3.1 and ES4 will very likely dissallow joining to prevent it from
        > ever happening in the future.

        Yes, that's what we decided. ES3.1 and ES4 will be deterministic in
        this regard. No joining.

        --
        Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM


      • 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 3 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 4 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 5 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.