Skip to content

Conversation

@murgatroid99
Copy link
Member

This should make the ChannelCredentials classes in the two libraries have the same API.

@kjin
Copy link
Contributor

kjin commented Aug 23, 2018

Would it be possible to make all hidden methods protected, and expose them through an internal subclass? E.g.

class ChannelCredentials {
  protected _getConnectionState() {}
}

class InternalChannelCredentials {
  getConnectionState() { return this._getConnectionState(); }
}

// ... SecureChannelCredentialsImpl overrides InternalChannelCredentials

Or, we could use symbols for the hidden methods? Though, I'm not sure if TS supports exporting classes with public symbol fields.

@murgatroid99
Copy link
Member Author

I don't think I like that option because it ends up requiring some typecasts that I would prefer to avoid. The Channel API accepts a generic ChannelCredentials object that the user gets from the ChannelCredentials API, and it would have to typecast it to whatever internal type to access the internal functions.

@nicolasnoble
Copy link
Contributor

Right, as long as we don't have a proper system to declare friend classes, this is the best we might come up with.

@murgatroid99 murgatroid99 merged commit 28cc844 into grpc:master Aug 24, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Nov 22, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants