Michael Koziarski wrote:
The 1.2 boat has sailed, but perhaps there's room for something like
this in 2.0. A few things to consider though:
* Why'd you change deprecation.rb?
Because you can't presently deprecate setter methods (methods with
ending in "="). A setter method can't take a block.
* Should .template_root= override or supplement previously supplied
values to .view_paths=
The patch presently does this:
def template_root=(path)
view_paths.unshift(path)
end
def template_root
view_paths.first
end
But it could also be defined like this:
def template_root=(path)
self.view_paths = [path]
end
def template_root
view_paths.first
end
* Should we just expose the array, or provide methods to 'add_view_path'
I really like just exposing the array. It harmonizes well with
Config#additional_load_paths and Config#controller_paths.
* Does this play right with people's expectations around inheritance.
Inheritance is tricky. I thought about creating a custom class
InheritedArray that would allow changes to the parent class's array to
filter down, but decided it would be overkill.
It presently is defined like this:
def view_paths
if paths = @@view_paths[name]
paths
else
if superclass.respond_to?(:view_paths)
superclass.view_paths.dup.freeze
else
@@view_paths[name] =
end
end
end
Which causes the subclass to return a frozen version of the
superclass's array if it doesn't have it's own array defined. This is
to prevent modification of the superclass's array when doing:
subclass.view_paths << 'additional/path' # raises an error
Instead you need to set it directly:
subclass.view_paths += [ 'additional/path' ]
Somewhat messy, but it seemed the nicer alternative.
