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

Re: [caplet] Re: ADsafe rules

Expand Messages
  • Mike Samuel
    Does anyone know the rationale for putting joining in the spec in the first place? mike
    Message 1 of 13 , Apr 6 12:30 PM
    • 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 2 of 13 , Apr 6 1:46 PM
      • 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 3 of 13 , Apr 6 2:01 PM
        • 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 4 of 13 , Apr 8 9:39 AM
          • 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.