«

Proposed RCR:

Modify ERB so that calls to #puts, #print, and #p inside the template
append the resulting string onto the local ERB output variable,
instead of sending the output to $stdout. #warn would still send to
STDERR (for debug messages seen but kept out of the result string)
and $stdout#<< could also be used.

Does anyone have any compelling reason why I should not make the
above RCR? I'll flesh it out as a proper RCR, citing the ruby-talk
threads with users wondering why it doesn't work as they expected.

As noted in another recent thread, I have in my possession an
implementation (perhaps not ideal) which accomplishes this already,
and would just need to be included. Would a C implementation also be
required for eruby, to keep feature parity between ERB and eruby?

(Should #p also be modified? Or is that logically a debug action
already?)

Hi --

On Sat, 10 Sep 2005, Gavin Kistner wrote:

> Proposed RCR:
>
> Modify ERB so that calls to #puts, #print, and #p inside the template append
> the resulting string onto the local ERB output variable, instead of sending
> the output to $stdout. #warn would still send to STDERR (for debug messages
> seen but kept out of the result string) and $stdout#<< could also be used.
>
> Does anyone have any compelling reason why I should not make the above RCR?
> I'll flesh it out as a proper RCR, citing the ruby-talk threads with users
> wondering why it doesn't work as they expected.

I can't think of any reason to do this other than the fact that people
who haven't learned how to use ERB expect it, and I don't consider
that a compelling reason. I would therefore not be in favor of it.
Further on the negative side, it would have the effect of collapsing
two very different logical levels into one. It just seems odd to have
three methods whose interpolated value is the value of an argument,
while everything else in the language is interpolated on the basis of
its actual value.


David

--
David A. Black

Hello Gavin,

GK> Proposed RCR:

GK> Modify ERB so that calls to #puts, #print, and #p inside the template
GK> append the resulting string onto the local ERB output variable,
GK> instead of sending the output to $stdout. #warn would still send to
GK> STDERR (for debug messages seen but kept out of the result string)
GK> and $stdout#<< could also be used.

GK> Does anyone have any compelling reason why I should not make the
GK> above RCR? I'll flesh it out as a proper RCR, citing the ruby-talk

I will vote against this RCR.

I don't think it is good to change this. I'm quite sure you break
backward compatibility in a lot of places and i don't see any real need
to do this.

If you write a RCR please explain more detailed why you want to do
this and where you see compatibility problems, maybe you can convince
me to accept the RCR.

GK> and would just need to be included. Would a C implementation also be
GK> required for eruby, to keep feature parity between ERB and eruby?

If it is accepted, then yes, please.
There is already the "-%>" problem with eruby vs. ERB and its going to
**** off a lot of people.

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

On Sep 10, 2005, at 9:40 AM, David A. Black wrote:

> Hi --
>
> On Sat, 10 Sep 2005, Gavin Kistner wrote:
>
>
>> Proposed RCR:
>>
>> Modify ERB so that calls to #puts, #print, and #p inside the
>> template append the resulting string onto the local ERB output
>> variable, instead of sending the output to $stdout. #warn would
>> still send to STDERR (for debug messages seen but kept out of the
>> result string) and $stdout#<< could also be used.
>>
>> Does anyone have any compelling reason why I should not make the
>> above RCR? I'll flesh it out as a proper RCR, citing the ruby-talk
>> threads with users wondering why it doesn't work as they expected.
>>
>
> I can't think of any reason to do this other than the fact that people
> who haven't learned how to use ERB expect it, and I don't consider
> that a compelling reason.

I have to agree. There's no advantage to having puts() work, since
you can just slap in the text itself with ERb tags as needed. I
personally think it's better that people confused by this aspect ask
here and get corrected, than it is to break puts() for them.

James Edward Gray II

On Sep 10, 2005, at 8:40 AM, David A. Black wrote:
> I can't think of any reason to do this other than the fact that people
> who haven't learned how to use ERB expect it, and I don't consider
> that a compelling reason.

Others have expressed similar sentiments, so I'm responding in general:

At work, our bug filing system has you rate each bug on several
different axes, one of which is "severity". One option is "Missing
functionality; workaround exists", and another (weightier) option is
"Missing functionality, no workaround". In general, having *a* way to
accomplish a task is not the same as having the 'ideal' way to
accomplish a task. It's better than nothing, but it's not perfect.

Separate from the "because it's what certain people expect" factor, I
consider the current method of appending strings to "_erbout" less
convenient/ideal than using muscle-memory-friendly methods like #puts.

To take it to the extreme, what if ERB did not support any Kernel
methods, but provided another mechanism for calling them? What if you
couldn't write "myobj.foo" but instead had to write "myobj.send
( :foo )" to invoke the method? The exact same functionality would
still be there...you would just need to remember, when using ERB, to
write your code in a different way than you do normally. My belief is
that it would be a PITA. The more the code you have to write inside
ERB blocks deviates from Ruby (syntax, idioms, or 'general use') the
less convenient it is to use. The more ERB 'just works' right out of
the box, the greater a tool it becomes to lure people to Ruby.

(I have coworkers who are considering using Ruby for code generation,
based on me showing how incredibly simple it was to use.)

Obviously (and thankfully) ERB is not at this far extreme, but it is
along this axis that I argue for including #puts and the like inside
ERB.

I understand the theoretical argument for backwards-compatibility.
Have you (dear reader) personally ever used #puts or #print inside an
ERB template for debugging output that you didn't want included in
the result? I know I haven't, but I accept that I'm a sample size of
one. If backwards compatibility is truly an issue (and this RCR were
accepted) then I suppose it would have to be something like an option
to the constructor. (But bleah, I really want it to just work,
without having to write "ERB.new( foo, nil, '%', nil, true )".)


If my above arguments do not sway the majority, then the feature
won't be added. I could just release some sort of "require
'erb_with_puts'" library that wraps around the existing ERB. No
worries. I'm just hoping to make Ruby better out of the box (IMHO)
for new-adopters and old alike.

--
"When I am working on a problem I never think about beauty. I only
think about how to solve the problem. But when I have finished, if
the solution is not beautiful, I know it is wrong."
- R. Buckminster Fuller

On Sep 10, 2005, at 9:39 AM, James Edward Gray II wrote:
> I personally think it's better that people confused by this aspect
> ask here and get corrected, than it is to break puts() for them.

IMHO, they way it behaves currently is what is broken.

My personal mental model says that #puts is for outputting content
that is the desired output of your program (unlike #warn). An ERB
template is a parametrized program in its own right, and its output
is the resulting string. If you want debug output, use #warn.

That's how I look at it, anyhow. Do others actually think of an ERB
template as an enormous HEREDOC string in another file that is going
to be included in your program, and ERB as an uber-powerful gsub to
run on that string?

Gavin Kistner wrote:

> Separate from the "because it's what certain people expect" factor, I
> consider the current method of appending strings to "_erbout" less
> convenient/ideal than using muscle-memory-friendly methods like #puts.

Can you give me an example of when appending to _erbout is necessary or
preferred rather than saying "%>some text<%" or "%><%=some value%><%"?

> To take it to the extreme, what if ERB did not support any Kernel
> methods, but provided another mechanism for calling them? What if you
> couldn't write "myobj.foo" but instead had to write "myobj.send ( :foo
> )" to invoke the method? The exact same functionality would still be
> there...you would just need to remember, when using ERB, to write
> your code in a different way than you do normally.

The exact same functionality *is* available when you puts or print. With
your change, people expecting to spit out debug messages would have to
do $stdout.puts...

> The more ERB 'just works' right out of the box, the greater a tool it
> becomes to lure people to Ruby.

Understood. Well, for what it's worth right now, the features it has
work almost exactly as they do in JSP, including the separation between
puts (System.out.println, as usual) and _erbout (newly conceived
out.println).

> That's how I look at it, anyhow. Do others actually think of an ERB
> template as an enormous HEREDOC string in another file that is going
> to be included in your program, and ERB as an uber-powerful gsub to
> run on that string?

Well, yes, but that's because I know how it works. I understand that
newbs don't see it that way. Those that know say, "Don't hide the truth!
Make the newbs learn!" You say, "Make the abstraction so pure that newbs
don't /need/ to learn!" There is some validity in that argument, but,
sadly, I'm going to side with Joel[1] on this one.

Devin
[1] http://www.joelonsoftware.com/articl...tractions.html

I would favor your RCR. I think no code will be broken because of the
new behavior.

Michel.

On 9/10/05, Gavin Kistner <> wrote:
> I understand the theoretical argument for backwards-compatibility.
> Have you (dear reader) personally ever used #puts or #print inside an
> ERB template for debugging output that you didn't want included in
> the result? I know I haven't, but I accept that I'm a sample size of
> one. If backwards compatibility is truly an issue (and this RCR were
> accepted) then I suppose it would have to be something like an option
> to the constructor. (But bleah, I really want it to just work,
> without having to write "ERB.new( foo, nil, '%', nil, true )".)

On Sep 10, 2005, at 12:53 PM, Devin Mullins wrote:
>> Separate from the "because it's what certain people expect"
>> factor, I consider the current method of appending strings to
>> "_erbout" less convenient/ideal than using muscle-memory-friendly
>> methods like #puts.
>
> Can you give me an example of when appending to _erbout is
> necessary or preferred rather than saying "%>some text<%" or "%><%
> =some value%><%"?

It's never necessary, as %><%=foo%><% is equivalent to _erbout <<
foo.to_s
It's preferred (by me) in cases where control whitespace is
important, or where the typing of the above is far more cumbersome
than typing "puts foo"

Contrived Example 1:
<ul>
<% items.each do |item|
_erbout << "\t<li>#{item.value}</li>\n"
end
%></ul>

compared with
<ul>
<% items.each do |item|
<li><%=item.value%></li>
<% end
%></ul>

(Not only is the newline sort of annoying in the above, but "\t" is
clearly a single tab character, where indentation on your editor may
use spaces to precede the <li>)

Contrived Example 2:
<%
sum = 0
100.times do |i|
_erbout << i.to_s
sum += i
end
_erbout << (sum / 100).to_s
foo.bar()
%>

compared with:
<%
sum = 0
100.times do |i|
%><%=i%><%
sum += i
end
%><%=sum/100%><%
foo.bar()
%>

compared with:
<%
sum = 0
100.times do |i|
print i
sum += i
end
print sum / 100
foo.bar()
%>


> The exact same functionality *is* available when you puts or print.
> With your change, people expecting to spit out debug messages would
> have to do $stdout.puts...

That's a good point. I suppose it seems 'correct' to me because (for
me) it's DWIM. As for for debug messages, I argue that debug messages
should be done with #warn anyhow (which would remain unchanged) as
STDERR is more appropriate (I think) than STDOUT. And, I simply
didn't believe that anyone was actually using the puts-in-erb-for-
debug functionality. (And I suppose I still won't, until someone says
"Yes, I use that!")


>> The more ERB 'just works' right out of the box, the greater a
>> tool it becomes to lure people to Ruby.
>
> Understood. Well, for what it's worth right now, the features it
> has work almost exactly as they do in JSP, including the separation
> between puts (System.out.println, as usual) and _erbout (newly
> conceived out.println).

So it currently meshes well for people coming from JSP, eh? That's
good to know.


> Well, yes, but that's because I know how it works. I understand
> that newbs don't see it that way. Those that know say, "Don't hide
> the truth! Make the newbs learn!" You say, "Make the abstraction so
> pure that newbs don't /need/ to learn!" There is some validity in
> that argument, but, sadly, I'm going to side with Joel[1] on this one.
>
> Devin
> [1] http://www.joelonsoftware.com/articl...tractions.html

Thanks for the article. I love reading Joel

Hi --

On Sun, 11 Sep 2005, Gavin Kistner wrote:

> On Sep 10, 2005, at 8:40 AM, David A. Black wrote:
>> I can't think of any reason to do this other than the fact that people
>> who haven't learned how to use ERB expect it, and I don't consider
>> that a compelling reason.
>
> Others have expressed similar sentiments, so I'm responding in general:
>
> At work, our bug filing system has you rate each bug on several different
> axes, one of which is "severity". One option is "Missing functionality;
> workaround exists", and another (weightier) option is "Missing functionality,
> no workaround". In general, having *a* way to accomplish a task is not the
> same as having the 'ideal' way to accomplish a task. It's better than
> nothing, but it's not perfect.
>
> Separate from the "because it's what certain people expect" factor, I
> consider the current method of appending strings to "_erbout" less
> convenient/ideal than using muscle-memory-friendly methods like #puts.
>
> To take it to the extreme, what if ERB did not support any Kernel methods,
> but provided another mechanism for calling them? What if you couldn't write
> "myobj.foo" but instead had to write "myobj.send( :foo )" to invoke the
> method? The exact same functionality would still be there...you would just
> need to remember, when using ERB, to write your code in a different way than
> you do normally.

But code isn't normally inserted into a text template. It's a
specialized situation. There's no way, and no reason, to sweep that
under the carpet.

> My belief is that it would be a PITA. The more the code you
> have to write inside ERB blocks deviates from Ruby (syntax, idioms, or
> 'general use') the less convenient it is to use. The more ERB 'just works'
> right out of the box, the greater a tool it becomes to lure people to Ruby.

I admit I am very down on luring people to Ruby by introducing
inconsistencies and anomalies into the language and libraries. What
this particular special case would do would be to mask the fact that
puts and print are method calls with return values. That creates the
need to explain one or both of two things: the fact that, elsewhere,
they do behave like normal methods, and the fact that, in ERB, they
don't. It's a double twist in the road; so why not just learn how it
really works in the first place?

In the short term, having the puts/print exception might allow a few
people to indulge habits that correspond to a novice's first
instincts. But in the long term, what makes Ruby simple and
attractive, in my view, is in part the fact that while there *are*
advanced features and techniques, those features and techniques tend
to be built up incrementally and transparently from the simple things.
I would rather see people invest effort in really understanding method
calls and return values, than have to learn ad hoc how particular
method calls operate in different contexts. It's sort of like having
to learn irregular verbs.


David

--
David A. Black