-
Notifications
You must be signed in to change notification settings - Fork 30
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
CEP27: toolkit Snippet #297
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A bunch of editorial changes - I'm not sure I fully understand all the usage details, either.
source/cep/cep27.rst
Outdated
2. Add the proper default initialisation of the variable required for the | ||
snippet. | ||
|
||
3. In the ``Archetype::EnterNotify()``, assign the Snippet with value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really assign the "Snippet" with a value???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This nearly there - thanks for the updates.
source/cep/cep27.rst
Outdated
add characteristics to archetypes such as Position or Metadata, the actual | ||
implementation method is very verbose, where in each archetypes one needs to add | ||
the new specification in the arcehtype header, then assign it and use it in the | ||
cpp file, with no guarantee on the consistency in the variable naming and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sentence kind of runs on... Maybe consider making it a couple of sentences.
Co-Authored-By: Paul Wilson <[email protected]>
source/cep/cep27.rst
Outdated
var1(0.0), | ||
var2(0.0), | ||
..., | ||
coordinates(0,0), //coordinates constructor (toolkit feature class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This initializer is not necessary/valid because the snippet in this example doesn't include the coordinates
variable.
source/cep/cep27.rst
Outdated
-------------------- | ||
``toolkit/my_snippet.cycpp.h``: | ||
.. highlight:: c | ||
cyclus::toolkit::Position coordinates; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this only in the version without inheritance? Is this the only difference between the with and without?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it also changes in the implementation of the archetype
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean the only difference in the snippet. It would be great if the same snippet could be used in both modes.
source/cep/cep27.rst
Outdated
var1(0.0), | ||
var2(0.0), | ||
..., | ||
coordinates(0,0), //coordinates constructor (toolkit feature class) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we use C++11 can we initialize these in the snippet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes that's true, this will be way better !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try this in my Position PR and see how it does work out!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems to be working, I updated both the PR and the CEP accordingly
source/cep/cep27.rst
Outdated
|
||
The |Cyclus| toolkit is designed to easily implement specific capabilities in | ||
newly developed archetypes, such as a trading policy, commodity producers, etc. To | ||
add characteristics to archetypes such as `Position` or `Metadata`, the actual |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is still a long, awkward sentence.
source/cep/cep27.rst
Outdated
-------------------- | ||
``toolkit/my_snippet.cycpp.h``: | ||
.. highlight:: c | ||
cyclus::toolkit::Position coordinates; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean the only difference in the snippet. It would be great if the same snippet could be used in both modes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry - just one more suggestion...
And then we need review from others!
…ader, and renameing my_snippet into my_feature_snippet
Co-Authored-By: Paul Wilson <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also renamed my_snippet
into my_feature_snippet
.
I believe it was making more sense.
I still wonder if there is a way for the same snippet to be used for inheritance and membership? |
that would be nice ! maybe an other way to do this would be to let |
Maybe we don't include the member variable in the snippet? The user needs to define the name for that member variable? That relaxes one kind of imposed consistency, but maybe that variable name is purely internal and doesn't need to be consistent... just a thought |
I liked the snippet idea for the variables exposed in the --- edit --- |
-------------------- | ||
``toolkit/my_feature_snippet.cycpp.h``: | ||
.. highlight:: c | ||
cyclus::toolkit::Position coordinates(0,0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you remove only this line (not exposed in input), then the snippet can be used in both modes, and developer chooses name of member variable.
In fact, that might be better, because otherwise developer has to know name of member variable defined in the snippet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is correct, (and I like the versatility it provides)
I guess it is a balance between versatility and amount of work on the developer side:
if we only support without-inheritance everything should be includable in the snippet.
if we want to support both, developers have to add:
#include 'toolkit/my_toolkit.h
- inheritance or feature element
#include
toolkit/snippet.cycpp.h` in the class core.
(this is also why without inheritance has my (slight) preference.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the good thing with removing the variable it would allow both with and without inheritance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even without inheritance, I'm not sure we want to assume that the member variable is always defined by the snippet... what if you want two positions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure but then what is the use of the snippet ? because some member variable are defined in the snippet (at least the one expose in the input.)
I don't see how to use the snippet with 2 positions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might not be the best example of including more than one instance. In addition, there may be a need to initialize each instance which gets complicated again. Nevertheless, I think asking the developer to explicitly declare their member variable is not too much to ask.
We should open this up to additional discussion, e.g. on the mailing list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think there is a benefit to having a single snippet file and then letting user choose the variable name in the non-inheritance case. We can include that in the example in the documentation.
Once we get that resolved, and clean up this CEP, I think I'm ready to approve/merge this and the follow-up PR's in the code repos.
Just a couple little grammar comments suggested above -- otherwise looks good to me. |
Co-Authored-By: Katy Huff <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ready to move forward
This is a suggestion to improve, ease and homogenize an the usage of toolkit capability in archetypes.
This idea is to limit as much as possible the need for implementation in a newly develop archetypes to avoid divergence in the implementation and the convention by providing a snippet that one can simply includes in the archetypes class definition header (inside the core definition of the class) to ensure variable name are identical.
Example can be found in: