-
Notifications
You must be signed in to change notification settings - Fork 9
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
feat(altnumber): Add NoLimit, AutoCalculate and AutoSize objects #44
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.
Looks good to me. Do you think it makes sense to add a value
field which returns the value? It will be identical to type but it might be closer to what one would expect. I don't think it is a required change as one can use .type
to get the same value during the translation process.
This commit brings the library up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44 Only the to_dict methods have been changed and the Python objects still internally use strings for simplicity. An alternative approach could use classes for AutoCalculate, AutoSize and NoLimit and use them similarly to how the `facetype` module is used. A change like this would involve a bunch of edits in a lot of different places, though. @mostaphaRoudsari, what do you think?
@chriswmackey I think this look great, This is more flexible and future-proofing. |
@mostaphaRoudsari , I think you might be confusing functionality of classes producing the schema with the schema itself. An extra redundant key in the schema seems like it only opens up the possibility for more typos or illegal combinations of values in the JSONs people submit. However, I can see the ability to get the |
This commit addresses [this issue here](ladybug-tools#30).
Just to clarify what I meant. Adding redundant keys to the schema seems fine from the perspective of people building schema JSONs thorough C# or Python bindings. But we should also think about people working with or building the JSONs in the absence of these bindings, as is the case with the energy_model_measure, Theo's web viewer, and I am sure many other applications. Having to edit two keys to make a change instead of one is not helpful from this perspective. |
This commit brings the library up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit brings the library up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit brings the measure in line with this recent change in the schema: ladybug-tools/honeybee-schema#44
This commit brings the plugin up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit brings the plugin up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit brings the library up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit brings the measure in line with this recent change in the schema: ladybug-tools/honeybee-schema#44
This commit brings the plugin up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
🎉 This PR is included in version 1.13.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This commit brings the library up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit brings the library up-to-date with these recent changes in honeybee-schema: ladybug-tools/honeybee-schema#44
This commit addresses this issue here.
The tests on this PR won't pass until I update the core Python libraries and re-export all of the samples. I am working on this now and will amend this PR shortly. In the meantime, @mostaphaRoudsari and @MingboPeng , can you let me know if these changes look good to you and confirm that they satisfy the issues you raised, Mingbo?