-
Couldn't load subscription status.
- Fork 525
Open
Description
Hi,
I'll work on that in the train.
Okay, using prototype substitution is maybe too soon for list/tupple/Array as their content will not have yet prototype substitution requiring to handle JSObj and PYObj at the same time that will kill a little performances now (as we'll have to handle 2 lists and 2 objects).
Here what I suggest for now:
new BrythonAPI(JSTarget, type)class, wheretypeis the current Python representation of a type, putting a[BrythonAPI]symbol on the prototype ofJSTarget. Therefore I won't have to rewrite the whole implementation oflistortupple, I'll make use of the current implementation.- I'll use that to add a
toJSWrapper(), to start delegating responsibilities injsobj2pyobj, and therefore cleaning it. I'll modifylistandtuppleclass to add a[PYOBJ2JSOBJ]symbol, to start delegating responsibilities inpyobj2jsobj, and therefore cleaning it (and making it symmetric). I'll do that for other python types latter.
Now handling of list/tupple/Array, is quite inefficient as lot of copies are made, with can be error prone.
What I suggest after thinking:
tupple: no need for copies during conversions, internal representation should beObject.isFreeze().list: send aProxyto JS. I know they will performances, but I'm not sure performances on the JS-side matters to us (we shouldn't use it/relies on it if we stick to Brython API). This will enable to convert content when accessed/set by JS (and I think the cost of theProxywill be mitigated by the conversions). This will enable array synchronisation without trouble, and will prevent to make copies and having different references when using JS API (e.g. storing alistinside of a JSMap). Not ideal, once we'll have prototype substitution for all types we will be able to do better.Array, ifObject.isFreeze(): convert to atupple. Else, copy the values and convert to alist. It would be as if the original object change reference when modified. It isn't true, but JS internals shouldn't be known to us, so it still make sense. Not ideal, once we'll have prototype substitution for all types we will be able to do better.
Then if I have time, I may work on Brython dict and to think about it (JS <=> Brython object conversion have issues I need to think about).
Cordially
Metadata
Metadata
Assignees
Labels
No labels