On Apr 12, 5:50 am, byrnejb <[email protected]> wrote:
> On Apr 10, 2:56 pm, Jeremy Evans <[email protected]> wrote:
> My own feelings about this is that instead of Class methods that alter
> Class behaviour one should instead subclass the desired options.
> Then, when people read the code they know exactly what they are
> dealing with, instead of having to run it to find out what options are
> set on a class when a problem happens.
When you use the class methods, you are setting the options in the
class. For example:
# global default for all classes
Sequel::Model.raise_on_save_failure = true
class Album < Sequel::Model
# override global default, make this the default for
# all instances of this class
self.raise_on_save_failure = false
end
album = Album.new
# override class default for this specific instance
album.raise_on_save_failure = true
album.save
Other than the overriding raise_on_save_failure on the instance using
the setter method, I'm not sure what problem you have with this.
In general, the global and class defaults are going to set in only one
place, and if the instance setter is used at all, it's probably in
close proximity to the save method call, so it should be fairly
obvious what is going on.
> > A different approach is to add additional options to the save method,
> > which currently accepts :changed, :transaction,
> > and :validate. :transaction overrides the use_transactions flag if
> > present, but there isn't a option to override the
> > raise_on_save_failure flag (one could be added, but nobody has
> > requested it).
>
> I strongly agree. If one needs override default behaviour at the
> instance level then those parameters should be passed in the method
> calls that require the overrides and not squirreled away in some
> obscure corner of the code base.
The instance setter isn't exactly "squirreled away", it's mentioned on
the same RDoc page as the save method, right at the top of the page:
http://sequel.rubyforge.org/rdoc/classes/Sequel/Model/InstanceMethods.html
I do agree that accepting an option for it is a nicer approach, but
there is a cost to adding such an option. That cost is modifying the
internal private methods that don't currently accept option hashes to
accept them, and there could be multiple internal methods involved.
While not a major cost, until I see a significant benefit, I don't
plan on adding such an option.
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
