-
Notifications
You must be signed in to change notification settings - Fork 4
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
Java/ #130
Comments
Agreed. I would disagree with #3 if this were a commercial tool, but it is a teaching tool, so it’s fine. - Jim
… On Apr 30, 2024, at 5:26 PM, Stoney Jackson ***@***.***> wrote:
I propose the following changes related to the generated Java/ directory.
Move the responsibility of cleaning up Java/ into plcc. plcc knows how to create it; so it best knows how to clean it.
[BREAKING] Make cleanup of Java/ unconditional. This is the common case.
[BREAKING] Don't allow the user to specify a different directory. All of the scripts (rep, parse, ...) require the directory to be Java/, and they do not take a parameter to specify the directory. The alternative is to add this parameter to these scripts making them more complicated and making the scripts harder to use.
—
Reply to this email directly, view it on GitHub <#130>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH53GSNYZPSL7JYGJ77HADZAAD6VAVCNFSM6AAAAABHBAQPYGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TENBXGQ4TGNA>.
You are receiving this because you are subscribed to this thread.
|
True... Alternatively, we could always require a target directory. That's what I advocated in #133 for the specification file. Maybe we should adopt The Zen of Python - PEP 20... then... If we follow "Explicit is better than implicit," then we should require a path to the generated language system. plccmk ./mylang.plcc ./mylang
scan ./mylang < hello.mylang
parse ./mylang < hello.mylang
rep ./mylang < hell.mylang Worth considering. |
My gut tells me this is going too far. Right now the plcc script creates a directory named Java (or Python, I guess), and all the other scripts assume that that is where the generated code is.
The only advantage of the scenario you describe below is that we could actually store several systems in one directory. But I hardly see that as useful.
Jim
… On May 1, 2024, at 2:32 PM, Stoney Jackson ***@***.***> wrote:
True... Alternatively, we could always require a target directory. That's what I advocated in #133 <#133> for the specification file. Maybe we should adopt The Zen of Python - PEP 20 <https://peps.python.org/pep-0020/>... then...
If we follow "Explicit is better than implicit," then we should require a path to the generated language system.
plccmk ./mylang.plcc ./mylang
scan ./mylang < hello.mylang
parse ./mylang < hello.mylang
rep ./mylang < hell.mylang
Worth considering.
—
Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH53GVQ2NWP5WBX54FTCJLZAEYMDAVCNFSM6AAAAABHBAQPYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYHA4TEOJWGA>.
You are receiving this because you commented.
|
I agree with the original. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I propose the following changes related to the generated Java/ directory.
The text was updated successfully, but these errors were encountered: