Skip to content
This repository has been archived by the owner on Jun 11, 2022. It is now read-only.

Remove dependency on hashie #11

Open
maeve opened this issue Aug 24, 2012 · 0 comments
Open

Remove dependency on hashie #11

maeve opened this issue Aug 24, 2012 · 0 comments

Comments

@maeve
Copy link
Contributor

maeve commented Aug 24, 2012

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant