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

Implement accessors for gen::* struct fields #47

Open
milesgranger opened this issue Nov 10, 2019 · 3 comments
Open

Implement accessors for gen::* struct fields #47

milesgranger opened this issue Nov 10, 2019 · 3 comments
Milestone

Comments

@milesgranger
Copy link
Owner

milesgranger commented Nov 10, 2019

When using the lib, I find myself wanting to access things like the parameters of a FunctionSignature.

Should either make these kinds of things public or add accessor methods to them.

Easiest would be adding pub to everything, but this might backfire when we later try to add validation as a user builds up items; as they could directly manipulate the fields. While maintaining a strict mutation pattern as we have now, sets us up better for later work in this.

So maybe adding read-only accessors to these is better?

@DarkDrek what are your thoughts?

@milesgranger milesgranger added this to the v1.0 milestone Nov 10, 2019
@DarkDrek
Copy link
Collaborator

I think read-only accessors would be better than just giving direct access to the underlying items.
Do you have an interface in mind? Do we want to implement read-only iterators or slices to the underlying items?

@milesgranger
Copy link
Owner Author

I lean slightly towards using slices, but I don't think I have strong feelings here.

@DarkDrek
Copy link
Collaborator

Slices would be easier to implement if we have the items stored in something like a vec. But we can't use other storage containers or transform the items before giving a read-only view. So in the long run iterators would give us more flexibility.
We can do slices now but change it to iterators once we have the need and release a new major version then.

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