Conversation
gonuke
left a comment
There was a problem hiding this comment.
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.
Do you really assign the "Snippet" with a value???
Co-Authored-By: Paul Wilson <paul.wilson@wisc.edu>
gonuke
left a comment
There was a problem hiding this comment.
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.
This sentence kind of runs on... Maybe consider making it a couple of sentences.
Co-Authored-By: Paul Wilson <paul.wilson@wisc.edu>
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.
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.
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.
it also changes in the implementation of the archetype
There was a problem hiding this comment.
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.
if we use C++11 can we initialize these in the snippet?
There was a problem hiding this comment.
yes that's true, this will be way better !
There was a problem hiding this comment.
I'll try this in my Position PR and see how it does work out!
There was a problem hiding this comment.
it seems to be working, I updated both the PR and the CEP accordingly
Co-Authored-By: Paul Wilson <paul.wilson@wisc.edu>
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.
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.
I mean the only difference in the snippet. It would be great if the same snippet could be used in both modes.
gonuke
left a comment
There was a problem hiding this comment.
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 <paul.wilson@wisc.edu>
bam241
left a comment
There was a problem hiding this comment.
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.
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.
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
#includetoolkit/snippet.cycpp.h` in the class core.
(this is also why without inheritance has my (slight) preference.)
There was a problem hiding this comment.
the good thing with removing the variable it would allow both with and without inheritance
There was a problem hiding this comment.
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.
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.
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.
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 <katyhuff@users.noreply.github.com>
gonuke
left a comment
There was a problem hiding this comment.
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: