Before and After Hooks

[benhamill]

Expand the API to include:

before_assembly - takes a block that'll get called at the top of the initializer. Perfect for calling super or something. The block receives no arguments.

after_assembly takes a block that'll get called at the end of the initializer. Perfect for calling super if you need to pass it something that your class was assembled from. The block receives no arguments... but private methods on the object being assembled are in scope?

[benhamill]

@kerinin mentioned before_/after_assembling. I think they look more or less the same and operate more or less the same grammatically:

class Foo
  before_assembly do
    some.thing
  end

  after_assembling do
    some.thing_else
  end
end

Personally, I like "assembly" more than "assembling", but not by a huge margin. Another case where an alias would help?

[benhamill]

Inheritance is going to get tricky with this one. Imagine inheriting from an Assembler class that defines it's own after hook to do some post-processing. And that you want to add your post-processing to it.

class Employee
  extend Assembler

  after_assembly do
    @full_name = "#{first_name} #{last_name}"
  end
end

class Professor < Employee
  after_assembly do
    @title = "PhD of #{degree_subject}, #{department_name}"
  end
end

Doing this would overwrite the parent class's after block? Or should it append? What if you need to prepend? Do we then get into weird order-of-declaration dependency crap?

Would it be enough to mention in the documentation that you should keep this block SHORT and if you need to do more than a one-liner you should make an instance method (which child classes can then redefine and call super within)?

[benhamill]

@kerinin Check out these specs. Seem feature complete to you? If so, I'll restructure the README.

[benhamill]

I mean--it doesn't even pretend to address the Employee/Professor example above, but... I don't know what to do about that, so...

[kerinin]

Tests looks good - I also like that arguments are available as instance variables (for some reason I though they were stored in a hash)

My instinct is to make these block additive, but the more I think about it the less I think I'll ever use this functionality. I try very hard to avoid anything that's not assignment in constructors specifically to avoid the types of timing problems that we were discussing.

That said, if we're going to provide the functionality, I don't think that defining a before hook on Professor should over-write the before hook on Employee - seems like a violation of encapsulation.

Maybe they take an argument

class Foo
  extend Assembler

  before_assembly :prepend do
    # whatever
  end
end

That's not super elegant and doesn't necessarily resolve anything, but it's an idea...

[benhamill]

I guess... How do Rails before hooks work? Are they order-of-declaration dependent? Whatever they do, it's probably what would be least surprising to most Rubyists.

[kerinin]

Yeah, I think rails is order of declaration.

[benhamill]

@kerinin What do you think about this: Let's get a first implementation of this into master and then do a PR specifically about making the block additive. Seem OK? If so, does this seem good to go beside the additive aspect?

[kerinin]

Yeah, that sounds like a good idea :+1:

[benhamill]

@kerinin What do you think about the new shape of the README?

[kerinin]

Yay contents! Sounds good.

On Thu, Mar 13, 2014 at 1:24 PM, Ben Hamill notifications@github.comwrote:

@kerinin https://github.com/kerinin What do you think about the new shape of the READMEhttps://github.com/benhamill/assembler/blob/bh/before_and_after_hooks/README.md ?

Reply to this email directly or view it on GitHubhttps://github.com/benhamill/assembler/pull/12#issuecomment-37569008 .