On Sat, Jun 14, 2008 at 11:47 AM, Allen Wirfs-Brock
<Allen.Wirfs-Brock at microsoft.com> wrote:
Off the top of my head the internal [[Construct]] and [[Call]]
methods come to mind. Given the things that host objects are
allowed to do the only way to determine if an object can be called
or used as a constructor appears to be by trying to use it as such.
Ok, host objects are irredeemably weird and apparently can't be fixed.
ES4 has a type Callable = {meta::invoke:*} that can be used on the
right of 'is' to tell if something is callable.
It's still possible a legacy host object would lack meta::invoke and
so not appear to be callable, even though you could call it (e.g.,
IE's window.alert host object). Such legacy creates the (or at least
one) "can't be fixed" problem, but new embeddings should try to avoid
injecting callable host objects without skinning them with veneer
that satisfies the 'x is Callable' relation.
AFAIK there is no meta::construct in ES4, so no analogous
Constructible type.
There may be other but I would need to look for them in the spec...
Host objects aside, if all other semantic state can be reflected on
except for the [[Scope]] encapsulated in a closure, then I'd recommend
providing a reflection of [[Extensible]] as well. It might enable
useful low-level forms of snapshotting/copying/persistence.
If there are some other bits of vampiric state, then we need to
discuss these on a case by case basis.
This topic, and the whole API design being developed, must be of
interest to es4-discuss because of the subset relation we're all
trying to uphold, so cross-posting.
On Jun 14, 2008, at 11:56 AM, Mark Miller wrote:
> On Sat, Jun 14, 2008 at 11:47 AM, Allen Wirfs-Brock
> <Allen.Wirfs-Brock at microsoft.com> wrote:
>> Off the top of my head the internal [[Construct]] and [[Call]]
>> methods come to mind. Given the things that host objects are
>> allowed to do the only way to determine if an object can be called
>> or used as a constructor appears to be by trying to use it as such.
>
> Ok, host objects are irredeemably weird and apparently can't be fixed.
ES4 has a type Callable = {meta::invoke:*} that can be used on the
right of 'is' to tell if something is callable.
It's still possible a legacy host object would lack meta::invoke and
so not appear to be callable, even though you could call it (e.g.,
IE's window.alert host object). Such legacy creates the (or at least
one) "can't be fixed" problem, but new embeddings should try to avoid
injecting callable host objects without skinning them with veneer
that satisfies the 'x is Callable' relation.
AFAIK there is no meta::construct in ES4, so no analogous
Constructible type.
>> There may be other but I would need to look for them in the spec...
>
> Host objects aside, if all other semantic state *can* be reflected on
> except for the [[Scope]] encapsulated in a closure, then I'd recommend
> providing a reflection of [[Extensible]] as well. It might enable
> useful low-level forms of snapshotting/copying/persistence.
>
> If there are some other bits of vampiric state, then we need to
> discuss these on a case by case basis.
This topic, and the whole API design being developed, must be of
interest to es4-discuss because of the subset relation we're all
trying to uphold, so cross-posting.
/be
>
> --
> Text by me above is hereby placed in the public domain
>
> Cheers,
> --MarkM
> _______________________________________________
> Es3.x-discuss mailing list
> Es3.x-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es3.x-discuss
>
On Jun 14, 2008, at 11:56 AM, Mark Miller wrote:
ES4 has a type Callable = {meta::invoke:*} that can be used on the
right of 'is' to tell if something is callable.
It's still possible a legacy host object would lack meta::invoke and
so not appear to be callable, even though you could call it (e.g.,
IE's window.alert host object). Such legacy creates the (or at least
one) "can't be fixed" problem, but new embeddings should try to avoid
injecting callable host objects without skinning them with veneer
that satisfies the 'x is Callable' relation.
AFAIK there is no meta::construct in ES4, so no analogous
Constructible type.
This topic, and the whole API design being developed, must be of
interest to es4-discuss because of the subset relation we're all
trying to uphold, so cross-posting.
On Jun 14, 2008, at 11:56 AM, Mark Miller wrote: > On Sat, Jun 14, 2008 at 11:47 AM, Allen Wirfs-Brock > <Allen.Wirfs-Brock at microsoft.com> wrote: >> Off the top of my head the internal [[Construct]] and [[Call]] >> methods come to mind. Given the things that host objects are >> allowed to do the only way to determine if an object can be called >> or used as a constructor appears to be by trying to use it as such. > > Ok, host objects are irredeemably weird and apparently can't be fixed. ES4 has a type Callable = {meta::invoke:*} that can be used on the right of 'is' to tell if something is callable. It's still possible a legacy host object would lack meta::invoke and so not appear to be callable, even though you could call it (e.g., IE's window.alert host object). Such legacy creates the (or at least one) "can't be fixed" problem, but new embeddings should try to avoid injecting callable host objects without skinning them with veneer that satisfies the 'x is Callable' relation. AFAIK there is no meta::construct in ES4, so no analogous Constructible type. >> There may be other but I would need to look for them in the spec... > > Host objects aside, if all other semantic state *can* be reflected on > except for the [[Scope]] encapsulated in a closure, then I'd recommend > providing a reflection of [[Extensible]] as well. It might enable > useful low-level forms of snapshotting/copying/persistence. > > If there are some other bits of vampiric state, then we need to > discuss these on a case by case basis. This topic, and the whole API design being developed, must be of interest to es4-discuss because of the subset relation we're all trying to uphold, so cross-posting. /be > > -- > Text by me above is hereby placed in the public domain > > Cheers, > --MarkM > _______________________________________________ > Es3.x-discuss mailing list > Es3.x-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es3.x-discuss >