Property Improved #139
Property Improved #139
Conversation
| @primitive = self.class.primitive | ||
| @field = @options[:field].freeze unless @options[:field].nil? | ||
| @default = @options[:default] | ||
| @field = @options[:field].freeze unless @options[:field].nil? |
There was a problem hiding this comment.
I realize the original code did this, but this seems to be freezing the object that was provided to the method, even if it is a hash value.
In general we try not to mutate any objects passed into methods, unless that is the method's primary purpose (which is rare).
There was a problem hiding this comment.
The safest approach for freezing objects can be seen in veritas: https://github.com/dkubb/veritas/blob/master/lib/veritas/support/immutable.rb#L81-116
|
@solnic this is a pretty amazing reduction in code. Do the dm-types specs pass with this change? Most of the comments I've left are really minor in nature, I really think this is a pretty awesome change. I love removing code from DM and replacing it with library code that's better tested. It's also a nice way to get virtus used more now. |
Property Improved For more information read this: https://gist.github.com/784350
| @@ -266,7 +266,7 @@ module DataMapper | |||
| :unique => @unique | |||
| ) | |||
|
|
|||
| if target_property.primitive == Integer | |||
| if target_property.instance_of?(Property::Integer) | |||
There was a problem hiding this comment.
I think this purpose of this was to catch any property subclasses with Integer primitives, not necessarily only Property::Integer classes.
However, for other parts of DM to work, people would probably have to subclass Property::Integer anyway if the they needed to store an Integer, so maybe this should use #kind_of? ? What do you think @solnic?
There was a problem hiding this comment.
@dkubb yes in other gems (dm-validations for example) I used #kind_of? cause there we may deal with custom subclasses; notice that this code here deals with FKs which currently are always created as Integer properties. For this to fail somebody would have to manually create an fk using an integer sub-class. Maybe "just in case" we should use #kind_of? here too. I don't have a strong opinion to be honest.
There was a problem hiding this comment.
I tend to use the strongest match that works, and then fallback to something less specific or duck typing if I have a valid use case.
In this case I think we have a valid use case though, and it's probably best handled by duck typing rather than asserting the class. I would probably change this to if target_property.respond_to?(:min) && target_property.respond_to?(:max), which will pass-through the min/max if the property type supports it.
|
This is awesome! Nice work @solnic! @solnic do you have any further thoughts on ripping out the On Sep 11, 2011, at 1:33 PM, Piotr Solnica wrote:
|
|
@emmanuel thanks man, it was fun :) I'm not sure how to tackle the virtus transition to be honest. I still need to think about possible solutions. @dkubb suggested that I could turn Property into a sub-class of Virtus::Attribute to ease the transition. That seems like a good idea. What do you mean by 'has-a Virtus::Attribute'? Effectively we want to rip out Property and have it replaced by Virtus. |
Hey!
This is still a WIP but I'm opening a pull request early so we can be discussing changes while I'm finishing this stuff.
This branch makes two relatively small but significant changes. First it adds dump_as/load_as property options as described here: https://gist.github.com/784350; it also removes typecast logic from dm-core and replaces it with Virtus Coercion system.
Let me know what you think :)