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

Generator Params vs. TypeGen Params #27

Closed
hofstee opened this issue Apr 22, 2017 · 2 comments
Closed

Generator Params vs. TypeGen Params #27

hofstee opened this issue Apr 22, 2017 · 2 comments

Comments

@hofstee
Copy link
Collaborator

hofstee commented Apr 22, 2017

Currently, the Generator constructor requires that the Params provided to the Generator match the Params provided to the TypeGen. There are cases where you would like the Generator to take additional parameters over the TypeGen. For example, consider a line buffer.

The line buffer needs to know at least 5 things: the width and height of the taps you want, the width of the image, the height of the image, and the bits per pixel. On the other hand, the type of the line buffer is very easily represented, it is just a single pixel in, and width*height pixels out. The TypeGen does not require any knowledge about the width and height of the image.

Instead, I propose that the Parameters provided to the Generator be a superset of the Parameters provided to the TypeGen.

@hofstee
Copy link
Collaborator Author

hofstee commented Apr 22, 2017

An argument against would be we would need to know the image width in order to know the delay of a module, but I'm going to disagree with that by saying the delay of a module should be a property of a module, not a property of its interface.

I'm open to hear what anyone else thinks.

@rdaly525
Copy link
Owner

I think this is good and allows typegens to be able to be used by a larger set of generators.

@rdaly525 rdaly525 closed this as completed May 2, 2017
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