Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation selection #37

Open
TitanNano opened this issue Feb 4, 2021 · 4 comments
Open

Implementation selection #37

TitanNano opened this issue Feb 4, 2021 · 4 comments

Comments

@TitanNano
Copy link

I read the proposal a couple of times now, but I'm still failing to see who implementation selection is going to work.

Let's say I create my own ToString protocol:

Protocol ToString {
    symbol;

    toString() {
       return this[ToString.symbol];
    } 
}

const myObject = {
    [ToString.symbol]: 'myObject',
};

console.log(myObject.toString());

How is the implementation of .toString() being selected? Will this run Object.prototype.toString() or ToString.toString()?

@ljharb
Copy link
Member

ljharb commented Feb 4, 2021

In your case, myObject doesn’t fully implement the protocol, so it’ll fall back to the Object.prototype method. If it did fully implement it, it’d use the ToString.toString method.

@TitanNano
Copy link
Author

@ljharb you are right, I forgot

Protocol.implements(myObject, ToString);

But what if I have two competing Protocols which both implement toString()? And how would I select the original Object.prototype.toString() implementation?

@ljharb
Copy link
Member

ljharb commented Feb 4, 2021

Generally speaking, there'd only be two options: to have the last one win, or to throw. I assume that rather than silently doing the wrong thing, this proposal would choose to throw, so that you couldn't mix competing protocols.

If a protocol you want to use provides a toString implementation, then either you use its toString, or you don't use that protocol.

@TitanNano
Copy link
Author

@ljharb I see, so a library can not use its own protocol internally without affecting the consuming application...

After I opened this, I saw PR #32 which appears to propose using myObject[ToString].toString(), that would avoid this issue, but also feels clunky.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants