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

Re: [caplet] Re: ADsafe rules

Expand Messages
  • 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 1 of 13 , Apr 6, 2008
      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 2 of 13 , Apr 8, 2008
        --- 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.