This comment has been minimized.

Personally not a fan of introducing a mini DSL inside a method, particularly _changed?( from => to ). It seems like that didn't work out too well when we tried, like #to_json( a million nested options ).

changed?( from: ..., to: ... ) kind of has the same ring to it, but I guess it's really just a method that takes options that happens to read nicely, so maybe that one is better.

model.name_changed?(to: "Ringo")

Personally not a fan of introducing a mini DSL inside a method, particularly _changed?( from => to ). It seems like that didn't work out too well when we tried, like #to_json( a million nested options ).

changed?( from: ..., to: ... ) kind of has the same ring to it, but I guess it's really just a method that takes options that happens to read nicely, so maybe that one is better.

This comment has been minimized.

@dhh I can see the value in specifying 'to', and both 'from and to' together. The latter could be used to check if an object has moved from one state to another, and potentially trigger some action / callbacks.

@dhh I can see the value in specifying 'to', and both 'from and to' together. The latter could be used to check if an object has moved from one state to another, and potentially trigger some action / callbacks.

This comment has been minimized.

@dhh I can see the value in specifying to', and bothfrom and to' together. The latter could be used to check if an object has moved from one state to another, and potentially trigger some action / callbacks.

@dhh I can see the value in specifying to', and bothfrom and to' together. The latter could be used to check if an object has moved from one state to another, and potentially trigger some action / callbacks.

This comment has been minimized.

@gja I think using === for implementing proc support is definitely okay, it's a pretty common Ruby idiom, and it would allow things like Regexp etc to work as well.

Whether we should support procs, Regexp etc is a different question. I'm leaning towards no, because like I said I'm not a big fan of these "mini-DSL" things inside a method.

On the other hand, I went through some of my code that might find use for this xxx_changed?(...) feature, and most of them can't actually take advantage of this because I need to check more than simple equality (matching the old value against a regexp is most common)...

@gja I think using === for implementing proc support is definitely okay, it's a pretty common Ruby idiom, and it would allow things like Regexp etc to work as well.

Whether we should support procs, Regexp etc is a different question. I'm leaning towards no, because like I said I'm not a big fan of these "mini-DSL" things inside a method.

On the other hand, I went through some of my code that might find use for this xxx_changed?(...) feature, and most of them can't actually take advantage of this because I need to check more than simple equality (matching the old value against a regexp is most common)...

This comment has been minimized.

Considering this module is most used in active record, where sometimes tracking the changes can generate a bunch of code, could be nice, for example, use a method like:user.role_changed?(to: -> (role) { ["admin", "super_admin"].incude?(role) }) instead ofuser.role_changed?(to: -> "admin" }) or user.role_changed?(to: -> "super_admin" }

Considering this module is most used in active record, where sometimes tracking the changes can generate a bunch of code, could be nice, for example, use a method like:user.role_changed?(to: -> (role) { ["admin", "super_admin"].incude?(role) }) instead ofuser.role_changed?(to: -> "admin" }) or user.role_changed?(to: -> "super_admin" }

So speaking for myself, I'd probably never use a proc like this, and I'd prefer not having to read code that does that. However, using === does give you things like Regexp and Range matching that could be quite nice in theory. However i couldn't come up with any realistic examples for those. (I checked my code again, and then I realized the Regexp examples I mentioned earlier they can't actually use this, because they need to dereference associations.)

It also could in theory cause problems for certain Ruby types that overrides === to mean something that the user doesn't expect. However, I can't think of any realistic cases where that could cause a problem either.

So, in summary, I personally don't prefer the === unless there are cases that justifies them.

So speaking for myself, I'd probably never use a proc like this, and I'd prefer not having to read code that does that. However, using === does give you things like Regexp and Range matching that could be quite nice in theory. However i couldn't come up with any realistic examples for those. (I checked my code again, and then I realized the Regexp examples I mentioned earlier they can't actually use this, because they need to dereference associations.)

It also could in theory cause problems for certain Ruby types that overrides === to mean something that the user doesn't expect. However, I can't think of any realistic cases where that could cause a problem either.

So, in summary, I personally don't prefer the === unless there are cases that justifies them.