There shouldn't be a Tree::MixinNode type. It's just semantically wrong. I also don't like #append_to. This should be implementable without touching anything in tree/ at all.
Really, I'd prefer duplicating a little appending code to kludges like this. You could even avoid the duplication by making some sort of append_all_children method. Garry Hill wrote: > Hi, > > On Apr 1, 9:12 pm, "Nathan Weizenbaum" <[EMAIL PROTECTED]> wrote: > >> Pastie seems to be down at the moment, but I can comment on your >> description. My suggestion was to return a string from parse_line on a mixin >> declaration, but just returning a normal Node from a mixin include. Then you >> could do the @mixin stuff in a parse_mixin method, and not add anything to >> the tree (actually, a more consistent way to do this would be to return >> :mixin), and an include wouldn't require much extra code at all. >> > > I've had another bash but haven't been able to make the method you > suggest above > work. > > On one hand, returning ':mixin' on a mixin declaration means that all > the work > currently done by build_tree in actually assigning directives to the > mixin > would have to be done somewhere else -- which I think would mean a > fair bit > of code duplication. > > On the other hand, returning a simple Node from a mixin include > doesn't work > either because Node's lack any formatting in the to_s method so I just > get an > error. Node could perhaps more usefully be called RootNode because as > far as I > can tell, this is the only place it can be used. Is there another type > of Node > I could use here (apart from a new MixinNode of course ;)? > > I did have another go though, and moved more of the parsing logic into > the > Node object. This required replacing a 'node << child' call with a > rather > awkward 'child.append_to(node)' so that mixins can append their > children > rather than appending themselves. This keeps the case handing in > build_tree > to a more acceptable level though. > > http://pastie.org/174037 > > All in all, the amount of code is pretty minimal in either version. To > make > things even cleaner I would have to take out the returning of arrays > from > import directives (returning a DirectiveNode instead I guess) so that > I > could return an array of mixin.children on a mixin include without > falling > foul of the "nested import" tests. However this feels like too much > messin' > with lots of code that works just fine. > > > Best, > > Garry > > p.s. pastie.org's back up > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
