fix: delete broken objectFromEntries#1306
Conversation
|
Hmmm. https://github.com/endojs/endo/actions/runs/3162163428/jobs/5148508233 shows a platform compat failure, presumably because it is testing a platform only enough to still not have its own If we decide we no longer support such platforms, we should remove that test, or at least make not Required. |
09ba3e4 to
b463d77
Compare
44f9480 to
17c44e3
Compare
kriskowal
left a comment
kriskowal
left a comment
There was a problem hiding this comment.
Thank you. I’m surprised that we no longer use fromEntries anywhere, but I trust the tests.
|
Thank you. I’m surprised that we no longer use Look again. I'm still exporting |
|
Huh. But maybe we don't actually import it anyway. I'm just as surprised. |
|
It is imported by |
17c44e3 to
92194e3
Compare
b463d77 to
b9bb49f
Compare
2 participants
commons.js contains its own ponyFill (aka shim, polyfill) of
Object.fromEntriesbecause it was relevant at the time. It no longer is. Fortunately it was dead code anyway because it was only exported (asfromEntries) when on a platform on which it is absent. Thus deleting it causes no transition cost. We can avoid the deprecation dance. By this criteria of course, fixing this is also low priority.The reason to bother getting rid of it is that it uses assignment semantics to initialize the object it creates and returns. The resulting problems explained at #1303 this has some terrible problems do apply to this code as well.