I wrote the patch that applies this behaviour and I don't think you have to worry.
1) As to Erb's behaviour, this is a clone of how ActionView/Erb work together to apply locals, including the superset behaviour. If you call a template once with one set of locals, then again with a smaller set of locals, the locals you don't pass in are defined and set to nil in the compiled template in Erb. I'd be interested in examples of where you are depending on a different behaviour. 2) Passing in assignments to nil works as you would expect. The supported local assigns are determined by the keys in the locals hash. If you assign nil to a local, the local will be defined and have the value nil. No special treatment is required. I would think that passing in different sets of locals is kind of unusual behaviour. Especially since Haml encourages not putting too much logic into templates, it seems like in the vast majority of cases, leaving a local undefined that is referenced in the template will result in an error. Which is why I think it's fine to deal with different sets of local variables as a corner case to prevent bugs but not worry too much about efficiency. However, I agree with Nathan's assessment that it would be faster to store the precompiled template so you could shove new local assigns into it and recreate the render function. In practice, I believe the ActionView implementation has the option to do this and doesn't. They build the render function and assignments bit in the template part, and the rendering of the erb inside of the erb engine and then kind of glue them together. So they could just cache the erb precompiled function and reuse it when they make the new template and assigns function, but I don't remember seeing this actually happening. Like I said, I think for most people's use cases, this doesn't happen much, I've certainly not seen it happen even once in our relatively large project. -Tom On May 16, 9:22 pm, Nick Howell <[EMAIL PROTECTED]> wrote: > Bingo; never mind the last message. I see now that in > Engine#initialize you ensure that a superset is supported. > > Problem with this is that a lot of people (myself included) depend on > locals that have not been sent explicitly remaining undefined. That's > pretty standard behavior with erb and earlier versions of haml, though > I understand if you want to break with this. Another question: what if > someone passes in nil for one of their locals? I guess they'd need a > workaround; a special MyNilClass. Or maybe just pass in false? > > Admittedly, you get better performance with this method, but I'm not > sure it's worth the lack of "niceness." > > Nick > > On May 16, 10:25 pm, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote: > > > Whoops! I should have caught that. I'll fix it as soon as I'm able (I > > just got a new computer, and I have yet to install Ruby or Subversion on > > it - soon, though!). > > > - Nathan > > > Nick Howell wrote: > > > Thought I'd seen the last of this one[1]. > > > > engine.rb: > > > 421 @scope_object.class.instance_eval do > > > 422 include CompiledTemplates > > > 423 end > > > > Should be > > > @scope_object.extend(CompiledTemplates) > > > > [1]:http://groups.google.com/group/haml/browse_frm/thread/c6a681ae92ae1b1... > > > > What're the chances? > > > > I'd be careful of ever doing .class.instance_eval. > > > > Nick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
