Comments on: Constructors in Ruby are not guaranteed to be called

By: 3hv » Blog Archive » Default values in your models

3hv » Blog Archive » Default values in your models — Fri, 05 Jun 2009 16:46:05 +0000

[...] default value code into your initialize method, it turns out that, under certain circumstances, it may not be called. Instead, move it to [...]

By: Rahoul Baruah

Rahoul Baruah — Thu, 04 Jun 2009 09:22:48 +0000

It looks to me like #allocate is for situations where an object’s state is about to be specified by some other means (such as when deserialising from an external source) – so whatever happens in #initialise would be overridden.

Which kind of makes sense, as far as ActiveRecord is concerned, IF you hold that an ActiveRecord model is merely a thin wrapper around the state in the database.

Unfortunately, because we also use ActiveRecord models as a holder for business logic (which may require _temporary_ state) the assumption that all a model’s state is in the database is invalid. Another flaw in the “mixing-business-logic-and-persistence” model that ActiveRecord follows.

By: Paul Horsfall

Paul Horsfall — Wed, 03 Jun 2009 22:46:53 +0000

I was aware of, or at the very least not surprised by this. And for whatever reason, I don’t think I’ve ever thought of Ruby’s initialize as a constructor. If you were to override YourClass.new and not call super you’d see something similar I suppose, although you wouldn’t get a new instance either in that case would you?

It would be interesting to know why ActiveRecord calls allocate directly though, it seems as though you’d only do so if you specifically wanted an uninitialised instance, but maybe that’s the point.