Hi -- On Sun, 11 Sep 2005, Mark Hubbart wrote: > I'm getting the idea that the people on each side of this discussion > disagree because they have different mental models of what ERB does, > and what a ERB document is: > > 1. ERB just implements very fancy, flexible, string interpolation. > or > 2. ERB documents are executable code (actual programs), where text > prints itself, and code blocks get run. > > #1 is, I gather, much like the JSP way (though I've never done JSP stuff) > #2 is much like PHP. > > If you are in the #1 camp, I suspect you think this RCR would not be > all that much different from one allowing this: > "#{puts 23}" #==> "23\n" Yes, that captures the problem exactly. #{} executes what's in side it and interpolates the value as a string, and having it do otherwise based on the name of the method would be anomalous and awkward. > If you are in camp #2, you probably just wonder why stuff you output > via #print or #puts doesn't end up with the rest of your ERB program's > output. If you want puts and print to behave anomalously, that's OK. But there's no mystery to why they don't. They behave exactly the same way every other method behaves. I don't think the *absence* of a "magic" or special case should be a source of wonder :-) > I'm in camp #2; I came to Ruby from PHP, and think of the template as > an actual program, an executable script with controlling statements > (Ruby code) embedded in self-printing text. I was shocked and > greatly disappointed when I found out that puts didn't work (yes, I > thought it was *broken*). I delved deeper and discovered that it was > simply due to an implementation issue; I assumed no one had fixed it > because it was too complicated a fix. The "coming from PHP" argument, I fear, is illogical. It predicates that whoever designed templating in PHP was empowered to make decisions for authors of future templating systems -- and by extension, presumably, everything else about future programming languages. That, in turn, would mean that there could be no further languages after PHP. In fact, there could only be one language at all, because the people who learned the first language would "come from" that language and therefore be constrained to do things as they were done in that language. I know you're not really suggesting that Ruby become PHP. But the "coming from" thing, while interesting in terms of our various biographies, has nothing to do with Ruby per se, and has no persuasive weight when it comes to discussing possible changes to Ruby. How could it? How could Ruby do everything everyone did in the last language they used? And *why* should Ruby play that kind of self-effacing, chameleon-like role? Why doesn't Ruby get to be Ruby, like PHP gets to be PHP? My advice is that you break the cycle: come from PHP when you're using PHP, and come from Ruby when you're using Ruby. It makes things more harmonious. It's also much more fair to Ruby: instead of viewing Ruby as "broken" because it doesn't do X like PHP, Y like C++, or Z like Perl, you get to explore and understand Ruby on its own terms. That doesn't mean you never think anything in Ruby should be changed. (It doesn't even mean that puts and print shouldn't be made to behave in a bizarre manner in ERB :-) It's just an acknowledgement of the fact that there's a design to Ruby, and of the fact that it is not incumbent on Ruby to play the role of a language-idiom sponge. > Now, I have a proposal: What if _erbout was made into a StringIO, and > we shifted the idea from an ERB template to an ERB program? Then would > it make sense for puts to output to _erbout? Yes, you should be able to do: $stdout = _erbout and have stuff go to that stream if _erbout is a StringIO object. I'm not sure about the template/program distinction. If you've got: Hello, my name is <%= name %>. and call that a "program", to me it implies that "Hello, my name is" is part of a programming language. Also I don't think redirecting $stdout causes a template not to be a template. But I may be looking at it wrongly (and it's more or less "academic", as they say :-) David -- David A. Black dblack / wobblini.net