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

Feature request: "Expect" method for TokenIterator #17

Closed
mnoskov opened this issue Aug 23, 2017 · 10 comments
Closed

Feature request: "Expect" method for TokenIterator #17

mnoskov opened this issue Aug 23, 2017 · 10 comments

Comments

@mnoskov
Copy link

@mnoskov mnoskov commented Aug 23, 2017

I think this method would be useful.

Like "nextToken", but throwing an exception with position coordinates if it does not match the expected token.

@JanTvrdik
Copy link
Contributor

@JanTvrdik JanTvrdik commented Aug 23, 2017

Terminology side note: such method is usually named consume.

Loading

@dg
Copy link
Member

@dg dg commented Sep 8, 2017

IMHO current next* works like consume*, so more consistent name should be something like nextTokenOrFail() & nextValueOrFail(). Or forceNextToken() & forceNextValue()

Loading

@hrach
Copy link

@hrach hrach commented Sep 8, 2017

more consistent name

the consitent name is the Jan Tvrdik's proposal.

Loading

@dg
Copy link
Member

@dg dg commented Sep 8, 2017

Can you explain it?

Loading

@JanTvrdik
Copy link
Contributor

@JanTvrdik JanTvrdik commented Sep 8, 2017

@dg Your proposal is consistent with your vision for Nette Tokenizer. My proposal is consistent with the rest of the world. But maybe @hrach meant sth else entirely.

Loading

@dg
Copy link
Member

@dg dg commented Sep 8, 2017

@hrach @Majkl578 Is consume usual name for a method that throws an exception in the event of failure instead of return null? Can you prove it with some links?

Loading

@dg
Copy link
Member

@dg dg commented Sep 8, 2017

I do not know ...

These are always methods from a higher layer than the tokenizer/lexer itself. So it makes sense to throw an exception when token not found - but it does not seem to me that it is their character.

However, it makes sense from a linguistic point of view. It's a verb, consume! and if you can't consume, it has sense to throw exception. While nextToken may not be theoretical none, ie null.

Loading

@JanTvrdik
Copy link
Contributor

@JanTvrdik JanTvrdik commented Sep 8, 2017

There are always methods from a higher layer than the tokenizer/lexer itself

Well, yes. The job of lexer ends by returning tokens array. The Stream object is a helper class used by parser. When no such helper class is available the consume() method is usually implemented as part of parser.

Maybe this practical usage of consume() will help?

Loading

@dg
Copy link
Member

@dg dg commented Sep 8, 2017

Loading

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

Successfully merging a pull request may close this issue.

None yet
4 participants