Name seems deceiving about decorators

[parndt]

Naming is, of course, one of the hard problems in software... what would you call this strategy?

[robyurkowski]

I rather like 'Renovators'.

[parndt]

Wouldn't it still load app/decorators/*_/__decorator.rb though?

[robyurkowski]

Why not change it to app/renovators/**/*_renovator.rb? That seems like a more apt name and place. The decorator already exists in a couple different formats in Rails (it's also a shitty name for a pattern that's more like a view controller).

I do get why 'decorator' was used for that pattern, and what people do with Refinery-style decorators is the decorator pattern, but since it's applied to the object's class instance, it's stretching the definition.

Really, this is monkeypatching, but that has such negative connotations, and just 'patching' is already taken, too. What Refinery-style decorators do is renovate a class—take an existing behaviour, and tack on some cool crap. Renovation.

[jswanner]

I could not find a software pattern name for monkey patching.

How about "Extensions", and app/extensions/**/*_extension.rb?

Or, perhaps "Extenders".

[jswanner]

When I think of the "decorator pattern", such as described here, the decorator wraps an object to give the object extra behaviour; without modifying other objects of the same class.

Example:

class Person
  def save
    # saves record
  end
end

class NotificationDecorator
  def initialize person
    @person = person
  end

  def save
    # send notification
    @person.save
  end
end

NotificationDecorator.new(Person.new).save

Here NotificationDecorator would have the same public interface as Person, just adding behaviour where needed.

Using the Queen's english for Philip's sake.

[parndt]

So the decorator pattern is not 100% what we're doing because that involves decorating individual instances of the class. We're decorating the class.

A perfect name, keeping decorators, would be class_decorators or something along those lines.

Extenders seems legitimate too.. but there's a lot of applications already using app/decorators/ as a convention so it would be a hard sell.
If it were to change the convention now there'd have to be some sort of compatibility adapter for using decorators/ too with a nice little warning saying please update to extenders.

What do you all think?

[parndt]

Yep, and instance decorators are already a solved problem by Draper.

[jswanner]

Don't get me wrong, I'm not saying what this is intended for is not useful.

Draper does provide a pattern for decorators, but specifically intended to be used in views -- "View Decorators" if you will. But, the pattern itself is not limited to that.

[jswanner]

You're trying to solve a problem related to Refinery, but Refinery isn't mentioned anywhere. That alone might do it, IMHO.

[parndt]

Related to Refinery, Spree, Forem, etc.

[simi]

Since this is just simple monkey patching, we should call it Banana. Files will be stored in app/bananas/**/*_banana.rb path and for profit we should alias Kernel.class_eval into Kernel.monkey_patch.

[keram]

+1 for extenders but I'm also fine with decorators, (why change something that works?) .)

[radar]

I would prefer renovators/extenders. Actually, probably extenders because its 1chr shorter.

Or bananas. Bananas works too.

[robyurkowski]

But... but... Tim the Toolman.

[simi]

@radar I made little name length's benchmark for you:

name        | name.length
--------------------------
renovators  | 10
extenders   |  9
bananas     |  7

I think we have winner!

[simi]

@parndt :( ?