Question: is it possible to create an array of here documents?
a = [<<END
some stuff
more stuff
END,
<<END
even more
END
]
?
Question: is it possible to create an array of here documents?
a = [<<END
some stuff
more stuff
END,
<<END
even more
END
]
?
On Feb 8, 4:09 pm, Roger P. [email protected] wrote:
Question: is it possible to create an array of here documents?
stuff = [ <<DOC1, <<DOC2, <<DOC3 ]
Hello World
DOC1
How’s it going?
DOC2
It’s just crazy, thanks.
DOC3
p stuff
#=> [“Hello World\n”, “How’s it going?\n”, “It’s just crazy, thanks.
\n”]
On Feb 9, 2008, at 12:09 AM, Roger P. wrote:
?
Yup:
a = [<<FOO, <<BAR]
some stuff
more stuff
FOO
even more
BAR
Gavin K. wrote:
Posted by Xavier N. (fxn) on 09.02.2008 00:19
Question: is it possible to create an array of here documents?
stuff = [ <<DOC1, <<DOC2, <<DOC3 ]
Hello World
DOC1
How’s it going?
DOC2
It’s just crazy, thanks.
DOC3p stuff
#=> [“Hello World\n”, “How’s it going?\n”, “It’s just crazy, thanks.
\n”]
Thanks.
On Fri, 8 Feb 2008 18:17:28 -0500
Xavier N. [email protected] wrote:
]
even more
BAR
Is there any reason you wouldn’t set up the heredocs first and then add
them to an array?
HD1 = <<ENDHD1
This is a heredoc.
The first of 2.
ENDHD1
HD2 = <<ENDHD2
This is the second heredoc.
ie the last.
ENDHD2
a=[HD1,HD2]
cheers,
On 09.02.2008 12:04, Mark W. wrote:
<<END
more stuff
The first of 2.
ENDHD1HD2 = <<ENDHD2
This is the second heredoc.
ie the last.
ENDHD2a=[HD1,HD2]
Waste of constants / variables.
robert
On Feb 9, 2008, at 12:04 PM, Mark W. wrote:
<<END
some stuff
HD1 = <<ENDHD1
This is a heredoc.
The first of 2.
ENDHD1HD2 = <<ENDHD2
This is the second heredoc.
ie the last.
ENDHD2a=[HD1,HD2]
Well, we are not advocating here documents in a row, we are just
answering a technical question about whether is possible to have them
that way.
On 2/9/08 3:09 AM, “Robert K.” [email protected] wrote:
ENDHD1
robert
I didn’t know constants and variables were in short supply, I’ll try to
be
more frugal.
I hope you laugh rather than take offense.
I do want to make the point that code that is easier to understand by
novices is inherently more maintainable. Writing “compact” code is often
over valued, IMHO. I would much prefer to see Marks code, because of the
ease of understanding it.
Leonard
On 15.02.2008 20:09, Leonard C. wrote:
a=[HD1,HD2]
Waste of constants / variables.robert
I didn’t know constants and variables were in short supply, I’ll try to be
more frugal.![]()
Simpler is often better so frugality might not be the worst course you
could take.
I hope you laugh rather than take offense.
No offense taken and it definitively made me smile. (-:
I do want to make the point that code that is easier to understand by
novices is inherently more maintainable. Writing “compact” code is often
over valued, IMHO. I would much prefer to see Marks code, because of the
ease of understanding it.
Completely agreed. There is of course room for interpretation. If code
is very elaborate to make understanding easier for novices it can defy
the purpose of ease of reading. If code gets compacted for compactness
reasons (famous one liners) then it usually becomes hard to read. A
simple example: some people (former C programmers?) like to use
assignments in if conditions, which is completely unnecessary and can
easily be confused with equivalence checks:
if foo = calc_foo()
…
foo = calc_foo()
if foo
…
There is really only one reason where assignment in conditions makes
sense because the code becomes easier that way: in loops:
while line = gets()
…
end
line = gets()
while line
…
line = gets()
end
Back to the particular example at hand: in this case I would at least
replace constants with regular local variables. If you use constants as
shown above, you would have to justify exposing these strings. This
usually only makes sense, if they are reused individually. If they are
not and are just temporarily there then local helper variables are
definitively preferred. I would even go as far as to put those here
docs directly into the array.
Kind regards
robert
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs