So I have a class that I may want to instantiate multiple ways.
Here’s the signatures of the some so far:
def create_from_file(absolute_filename, archive_filename, fsg=nil,
def create_from_parts(archive_filename, mtime, sha512hash)
The canonical way to do this seems to be with branching in init. You
look at the types of your arguments, and you sort of try and figure
out in initialize a clever way to distinguish between them and invoke
However, as you can see above, some of the methods are in a state of
flux. Create_from_file has had several arguments appended to it, and
the first argument of each method is a string (in the second two
cases, I’m deserializing from a file, and having to convert to another
class, like Pathname, just to call a constructor is annoying).
Furthermore, I have changed the types and order of arguments from
time to time, this being a scripting language and all, and having to
validate the distinguisher in initialize each time is kinda lame.
Type systems are also a slightly arcane subject, deliberately avoided
in scripting languages, since not having to worry about them too much
is perceived as a major benefit.
Further, should you change the signature of the methods, you have to
go back and figure out whether that clever distinguisher in initialize
actually still works. If you forget, which will likely happen just as
often as C/C++ programmers forget to update function prototypes in
header files, your run-time behavior will be unpredictable. I
wouldn’t want to waste time debugging that.
What I did at first was avoid initialize do nothing (actually don’t
even define one) and have each of the create_from_* methods return
self at the end. Then, I could do this:
m = Metadata.new().create_from_file(…)
Great, that’s pretty cool, but it’s a little tedious (less so if you
leave off the empty parens).
So the other way I looked into was to create some static or class
methods which created the object myself, and avoid new entirely.
After all, there’s nothing too magic about new, and if it can’t do
anything too fancy, emulating polymorphism in a scripting language
using branching and RTTI is totally lame.
So I looked into this a bit, and I assume something like this could
Then I realized that I’ve got six methods now to do initialization;
three class methods (which are a little obscure to noobs) and three
instance methods. That’s a lot of verbosity… is there a better way?
Then it dawned on me:
def initialize(method=nil, *args)
when :file then create_from_file(*args)
when :parts then create_from_parts(*args)
when :string then create_from_string(*args) # unused
# if no method, do no intialization
This method seems to be the best of many worlds; I get a single
initialize, I don’t have to do any retarded run-time type checking to
emulate polymorphism, I can alter the signatures of the create_from_*
methods at will, and I never have to look at initialize, unless
I want to add a new kind of initializer, which is a bit rare.
Some suggest that this violates the POLS/POLA, but it seems quite
explicit to me (MUCH easier for a newbie to read than RTTI
comparisons), more terse than multiple class constructors,
substantially more robust in the face of changes to initializer type
signatures than the magic initializer technique, scales well to large
numbers of possible constructors, and is even backwards compatible
with my old method (due to method=nil; you simply don’t pass any
arguments and it gives you an uninitialized object; you can then call
create_from_* on it as before).
PS: As you see above, I’m passing verbose and debug around a lot and
hate it. I’d like to use globals, but it seems kind of fugly to have
classes accessing globals which are only used when the FILE ==
$0. In fact, I always want verbose and debug off except when invoked
as a script. Is there any cleaner way to deal with this?