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

V2 Meta Issue #1341

Open
shivupa opened this issue Jan 8, 2024 · 3 comments
Open

V2 Meta Issue #1341

shivupa opened this issue Jan 8, 2024 · 3 comments
Milestone

Comments

@shivupa
Copy link
Contributor

shivupa commented Jan 8, 2024

This collects various comments during the development of v2 that have yet to be addressed

@shivupa
Copy link
Contributor Author

shivupa commented Jan 8, 2024

          This is too much to go over in a code review but this reminds me of https://craftinginterpreters.com/representing-code.html#the-expression-problem: is it better for us to have properties as classes/programs as methods, or programs as classes/properties as methods?  This implements the former, since the latter has been a mess, and I think doing anything fancier (visitor) is not user-facing.

My one concern here is that this method is public. Will it be able to be made private so a user never has to specialize their code for their specific program? (Visibility is a breaking API change.)

Originally posted by @berquist in #1325 (comment)

@shivupa
Copy link
Contributor Author

shivupa commented Jan 8, 2024

          This is the "same" in every parser.  The `atombasis.known_codes` can be abstracted if it's made a `classmethod`, then it becomes `cls.known_codes`, `getattr(cls, program)`, etc., which just leaves the return type.  Shouldn't the return type eventually be https://docs.python.org/3/library/typing.html#typing.Self?

Originally posted by @berquist in #1325 (comment)

          it feels like this might be a repeated paradigm can we factor this out? nothing to change right now

Originally posted by @shivupa in #1302 (comment)

@shivupa
Copy link
Contributor Author

shivupa commented Jan 8, 2024

          This is too much to go over in a code review but this reminds me of https://craftinginterpreters.com/representing-code.html#the-expression-problem: is it better for us to have properties as classes/programs as methods, or programs as classes/properties as methods?  This implements the former, since the latter has been a mess, and I think doing anything fancier (visitor) is not user-facing.

My one concern here is that this method is public. Will it be able to be made private so a user never has to specialize their code for their specific program? (Visibility is a breaking API change.)

Originally posted by @berquist in #1325 (comment)

These functions are user facing mainly because they are static methods. They are technically user accessible.. but one would always just call parse which would call the correct function. We could change this to something like __CODENAME to make it private or something? Not really sure what the way forward here would be

@berquist berquist added this to the v2.0 milestone Jan 27, 2024
@berquist berquist modified the milestones: v2.0, v2.0a Mar 22, 2024
@berquist berquist modified the milestones: v2.0a, v2.0 May 1, 2024
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