Hi --
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
