You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 11, 2022. It is now read-only.
Modelish's foundation is built on hashie. While I still like hashie's syntax, there have been some issues with the implementation.
Most importantly, hashie is architected around class inheritance, forcing modelish to also use the same pattern. It would be much nicer if all of modelish's functionality was available via mixin(s) instead of a base class. Of course, Modelish::Base should continue to exist for backward compatibility.
Since modelish was first implemented, hashie has made several breaking changes to the base classes on which modelish depends. In order to overcome these incompatibilities, modelish is now overriding a lot of hashie's internal implementation, including private methods (gack!). This should not continue.
Modelish property validations aren't applied until a client explicitly calls a validation method on a modelish object, whereas hashie applies validations during object initialization (one of those breaking changes mentioned above). Modelish also allows for a much wider range of validations, including support for arbitrary lambda validators.
Modelish presents value coercion and property name mapping as two separate areas of functionality, whereas hashie v2.0 (not yet released) presents these as related concepts in Hashie::Trash (and does not support the notion of typed properties or value coercion at all in any of the stable releases to date). Also, Hashie::Trash does not allow for mapping the same source property to multiple destination properties, which has proven necessary more often than one might think.
In the end, hashie is a really great general purpose tool. However, modelish is heading in a more specific direction (a lightweight modeling framework primarily designed for wrapping inputs and outputs from external web services), and it's time to consider alternative implementations.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Modelish's foundation is built on hashie. While I still like hashie's syntax, there have been some issues with the implementation.
Most importantly, hashie is architected around class inheritance, forcing modelish to also use the same pattern. It would be much nicer if all of modelish's functionality was available via mixin(s) instead of a base class. Of course, Modelish::Base should continue to exist for backward compatibility.
Since modelish was first implemented, hashie has made several breaking changes to the base classes on which modelish depends. In order to overcome these incompatibilities, modelish is now overriding a lot of hashie's internal implementation, including private methods (gack!). This should not continue.
Modelish property validations aren't applied until a client explicitly calls a validation method on a modelish object, whereas hashie applies validations during object initialization (one of those breaking changes mentioned above). Modelish also allows for a much wider range of validations, including support for arbitrary lambda validators.
Modelish presents value coercion and property name mapping as two separate areas of functionality, whereas hashie v2.0 (not yet released) presents these as related concepts in Hashie::Trash (and does not support the notion of typed properties or value coercion at all in any of the stable releases to date). Also, Hashie::Trash does not allow for mapping the same source property to multiple destination properties, which has proven necessary more often than one might think.
In the end, hashie is a really great general purpose tool. However, modelish is heading in a more specific direction (a lightweight modeling framework primarily designed for wrapping inputs and outputs from external web services), and it's time to consider alternative implementations.
The text was updated successfully, but these errors were encountered: