On Jul 15, 2011, at 10:56 AM, Dean Landolt wrote:
>
>
> On Fri, Jul 15, 2011 at 1:30 PM, Allen Wirfs-Brock <[email protected]>
> wrote:
>
> On Jul 15, 2011, at 10:00 AM, Jonas Sicking wrote:
> >
> > Except that you don't want to do that for host objects. T
...
>
> And a cloned JS object is a lot less useful if it has lost it's original
> [[Prototype]].
>
>
> Didn't you just argue you could communicate this kind of information with a
> schema? You couldn't share the actual [[Prototype]] anyway. So you'd have to
> pass the expected behaviors along with the object (this is why a Function
> serialization would be wonderful, but this could be done in a schema too).
>
> Sure, it won't be terribly efficient since (without mutable __proto__ or a <|
> like mechanism in JSON) your worker would have to another key pass to tack on
> the appropriate behaviors. There's no benefit to the branding info (again, no
> shared memory) so I don't really see the problem. Why would this JS object be
> substantially less useful? It just requires a slightly different paradigm --
> but this is to be expected. The only alternatives I can imagine would require
> some kind of spec. assistance (e.g. a specified schema format or a JSON++),
> which I gather you were trying to avoid.
>
I was only objecting to any argument that starts out by essentially saying host
objects are have unique requirements. Anything that is an issue host objects
is likely to be an issue for some pure JS application.
>
> Generalizations about host objects are no more or less valid than
> generalizations about pure JS objects.
>
> This issue applies to pure JS object graphs or any serialization scheme.
> Sometimes language specific physical clones won't capture the desired
> semantics. (Consider for example, an object that references a resource by
> using a symbolic token to access a local resource registry). That is why the
> ES5 JSON encoder/decoder includes extension points such as the toJSON method.
> To enable semantic encodings that are different form the physical object
> structure.
>
> The structured clone algorithm, as currently written allows the passing of
> strings, so it is possible to use in to transmit anything that can be encoded
> within a string. All it takes needs is an application specific
> encoder/decoder. It seems to me the real complication is a desire for some
> structured clone use cases to avoid serialization and permit sharing via a
> copy-on-right of a real JS object graph.
>
>
> There are alternatives to CoW (dherman alluded to safely transferring
> ownership in his post, for instance).
In either case there are contextual issues such as the [[Prototype]] problem.
More generally if you have a behavioral based (methods+accessors are the only
public interface) object model then you really can't CoW or transfer ownership
meaningfully and maintain no shared state illusion.
>
>
> If you define this sharing in terms of serialization then you probably
> eliminate some of the language-specific low level sharing semantic issues.
> But you are still going to have higher lever semantic issues such as what
> does it mean to serialize a File. It isn't clear to me that there is a
> general solution to the latter.
>
>
> Why does it matter what it means to serialize a File? For the use cases in
> question (IndexedDB and WebWorkers) there are various paths an app could
> take, why would this have to be spec'ed? What does toJSON do? And does a file
> handle really need to make it across this serialization boundary and into
> your IDB store for later retrieval? I suspect not.
Again, just an example and something that structured clone does deal even if
not in a very precise manner. I was trying to say that there probably isn't a
general solution communicate higher level semantic information. It needs to be
designed on a case by case basis.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
