More typescript exports #4143
Merged
More typescript exports #4143
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr>
|
@parrt ready to merge |
|
Cool. Are there other types to add? I see you've focused mostly on outer API types...do we need "internal" stuff like Recognizer.atn, Token.EPSILON, ATNState.INVALID_STATE_NUMBER, RuleStartState.ruleIndex, ...? Could we get an intern or something to typify all or is that too much work? |
|
I am indeed only exporting ‘outer’ types. I don’t think we should export inner ones. Envoyé de mon iPhoneLe 26 févr. 2023 à 20:25, Terence Parr ***@***.***> a écrit :
Cool. Are there other types to add? I see you've focused mostly on outer API types...do we need "internal" stuff like Recognizer.atn, Token.EPSILON, ATNState.INVALID_STATE_NUMBER, RuleStartState.ruleIndex, ...?
Could we get an intern or something to typify all or is that too much work?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Can you explain your reasoning? Seems like the Java stuff exposes all of
that and it’s occasionally useful. For example, when building tools on top
of antlr.
On Sun, Feb 26, 2023 at 1:33 PM ericvergnaud ***@***.***> wrote:
I am indeed only exporting ‘outer’ types. I don’t think we should export
inner ones. Envoyé de mon iPhoneLe 26 févr. 2023 à 20:25, Terence Parr
***@***.***> a écrit :
Cool. Are there other types to add? I see you've focused mostly on outer
API types...do we need "internal" stuff like Recognizer.atn, Token.EPSILON,
ATNState.INVALID_STATE_NUMBER, RuleStartState.ruleIndex, ...?
Could we get an intern or something to typify all or is that too much work?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are
receiving this because you authored the thread.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#4143 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABLUWNPJSB743K7FL6OMOTWZPDZPANCNFSM6AAAAAAVH422OA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
--
Dictation in use. Please excuse homophones, malapropisms, and nonsense.
|
|
It’s the general OOP reasoning: the more you expose, the more you bind yourself to your internal implementation making it harder to change it. I think you are correct that it may make it more difficult to build tools, but I’d rather have that conversation in the context of such a project than simply expose everything upfront. Happy to discuss the strategy.Envoyé de mon iPhoneLe 26 févr. 2023 à 22:36, Terence Parr ***@***.***> a écrit :
Can you explain your reasoning? Seems like the Java stuff exposes all of
that and it’s occasionally useful. For example, when building tools on top
of antlr.
On Sun, Feb 26, 2023 at 1:33 PM ericvergnaud ***@***.***> wrote:
I am indeed only exporting ‘outer’ types. I don’t think we should export
inner ones. Envoyé de mon iPhoneLe 26 févr. 2023 à 20:25, Terence Parr
***@***.***> a écrit :
Cool. Are there other types to add? I see you've focused mostly on outer
API types...do we need "internal" stuff like Recognizer.atn, Token.EPSILON,
ATNState.INVALID_STATE_NUMBER, RuleStartState.ruleIndex, ...?
Could we get an intern or something to typify all or is that too much work?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are
receiving this because you authored the thread.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#4143 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABLUWNPJSB743K7FL6OMOTWZPDZPANCNFSM6AAAAAAVH422OA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
--
Dictation in use. Please excuse homophones, malapropisms, and nonsense.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
that makes sense. We can add exposure as the needs arise. Let’s watch for such opportunities among support request I guess. |
jimidle
pushed a commit
to jimidle/antlr4
that referenced
this pull request
Mar 28, 2023
Signed-off-by: Eric Vergnaud <eric.vergnaud@wanadoo.fr> Signed-off-by: Jim.Idle <jimi@idle.ws>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.