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

Limiting the visibility of reactor classes #194

Open
lhstrh opened this issue Jul 7, 2020 · 8 comments
Open

Limiting the visibility of reactor classes #194

lhstrh opened this issue Jul 7, 2020 · 8 comments
Labels
question Further information is requested

Comments

@lhstrh
Copy link
Member

lhstrh commented Jul 7, 2020

With the new import mechanism that we're working on, name conflicts between reactor classes across files can be avoided by putting them in a different package. We need to report duplicate names among reactor classes within the same package as errors, but there are situations in which duplicates could co-exist without problem, namely if they are only used locally, within the file of their definition. Our suite of regression tests is an example of such situation.

It might, therefore, make sense to limit which reactor classes are importable by other. We could achieve this by requiring an explicit export modifier before any class definition that can be referenced/imported by in another file. This would also make it possible to export a composite without exporting the class definitions of the reactors it contains, for instance.

Is this something we'd want?

@lhstrh lhstrh added the question Further information is requested label Jul 7, 2020
@edwardalee
Copy link
Collaborator

This sounds like a good step to me. Being able to export a composite without exporting the components is a clear win. It also removes the oddness that import does not import main reactors.

@cmnrd
Copy link
Collaborator

cmnrd commented Jul 7, 2020

Sounds also good to me. I would prefer private and public modifiers rather than export though

@lhstrh
Copy link
Member Author

lhstrh commented Jul 10, 2020

Just to clarify, do we want to be able to export main reactors? I'm assuming that if we do, we'd simply treat them as non-main once imported. Correct?

If we do this, then perhaps export really is more descriptive than public because it's not merely a visibility modifier; it actually changes the meaning of the definition of a main reactor.

Finally, what would it mean to import a federated reactor?

@edwardalee
Copy link
Collaborator

I doubt exporting main reactors will prove very useful. They won't have inputs or outputs, for one thing.

@lhstrh
Copy link
Member Author

lhstrh commented Jul 10, 2020

I agree. I just understood your comment to imply that the reason to not import a reactor should not be because it's main but because it isn't exported. This left open the possibility to export main reactors. I'm also fine disallow that. So is the suggested behavior to let export main reactor X { ...} yield a validation error?

@edwardalee
Copy link
Collaborator

Yes, I would think so.

@edwardalee
Copy link
Collaborator

Or just don't include it in the grammar.

@lhstrh
Copy link
Member Author

lhstrh commented Jul 10, 2020

Better to do it during validation because it allows for a more informative error message.

@lhstrh lhstrh mentioned this issue Jul 11, 2020
@lhstrh lhstrh changed the title Avoiding name conflicts within a package Limiting the visibility of reactor classes Aug 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants