[#4341] DRY and embedded docs. — Hugh Sasse Staff Elec Eng <hgs@...>
If I have a here document in some ruby program:
[#4347] Re: DATA and rewind. — ts <decoux@...>
>>>>> "H" == Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
[#4350] Re: Thirty-seven Reasons [Hal Fulton] Love[s] Ruby — "David Douthitt" <DDouthitt@...>
[#4396] Re: New Require (was: RAA development ideas (was: RE: Looking for inp ut on a 'links' page)) — Hugh Sasse Staff Elec Eng <hgs@...>
On 9 Aug 2000, Dave Thomas wrote:
[#4411] Re: RAA development ideas (was: RE: Lookin g for inp ut on a 'links' page) — Aleksi Niemel<aleksi.niemela@...>
Me:
On Thu, 10 Aug 2000, [iso-8859-1] Aleksi Niemelwrote:
[#4465] More RubyUnit questions. — Hugh Sasse Staff Elec Eng <hgs@...>
I am beginning to get a feel for this, but I still have a few more
[#4478] Re: RubyUnit. Warnings to be expected? — ts <decoux@...>
>>>>> "H" == Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes:
[#4481] Invoking an extension after compilation — Dave Thomas <Dave@...>
Hi,
[#4501] What's the biggest Ruby development? — Dave Thomas <Dave@...>
[#4502] methods w/ ! giving nil — Hugh Sasse Staff Elec Eng <hgs@...>
I have got used to the idea that methods that end in '!' return nil if
[#4503] RubyUnit and encapsulation. — Hugh Sasse Staff Elec Eng <hgs@...>
My_class's instance variables are not all "attr :<name>" type variables,
[#4537] Process.wait bug + fix — Brian Fundakowski Feldman <green@...>
If your system uses the rb_waitpid() codepath of rb_f_wait(),
[#4567] Re: What's the biggest Ruby development? — Aleksi Niemel<aleksi.niemela@...>
Dave said:
Robert Feldt <feldt@ce.chalmers.se> writes:
On Sat, 26 Aug 2000, Dave Thomas wrote:
Robert Feldt <feldt@ce.chalmers.se> writes:
On Mon, 28 Aug 2000, Dave Thomas wrote:
Robert Feldt <feldt@ce.chalmers.se> writes:
[#4591] Can't get Tcl/Tk working — Stephen White <steve@...>
I can't get any of the samples in the ext/tk/sample directory working. All
I'm sure looking forwards to buying the book. :)
Stephen White <steve@deaf.org> writes:
On Sun, 27 Aug 2000, Dave Thomas wrote:
Stephen White <steve@deaf.org> writes:
[#4608] Class methods — Mark Slagell <ms@...>
Reading the thread about regexp matches made me wonder about this:
[#4611] mod_ruby 0.1.19 — shreeve@...2s.org (Steve Shreeve)
Shugo (and others),
[#4633] Printing tables — DaVinci <bombadil@...>
Hi.
[#4647] Function argument lists in parentheses? — Toby Hutton <thutton@...>
Hello,
[#4652] Andy and Dave's European Tour 2000 — Dave Thomas <Dave@...>
Hi,
[#4672] calling super from c — Robert Feldt <feldt@...>
[#4699] Double parenthesis — Klaus Spreckelsen <ks@...1.ruhr-uni-bochum.de>
Why is the first line ok, but the second line is not?
[ruby-talk:04362] Re: Thirty-seven Reasons [Hal Fulton]Love[s] Ruby
Matz commented on this once; I won't speak for him, but my impression was that this was done rather in the interest of avoiding unnecessary rigidity. That's how I would view it, anyway. And I do like this (arguable) feature, as I 've said. As for syntax highlighters... well, I don't think these need to be made that "smart." It doesn't actually hurt anything if a word is colored incorrectly... in fact, for those who want this coding style discouraged, an incorrectly-marked word would do so -- alerting the coder that he had (perhaps inadvertently) used a keyword as a method name or whatever. Hal ----- Original Message ----- From: Conrad Schneiker <schneik@austin.ibm.com> To: ruby-talk ML <ruby-talk@netlab.co.jp> Sent: Tuesday, August 08, 2000 12:20 PM Subject: [ruby-talk:04357] Re: Thirty-seven Reasons [Hal Fulton]Love[s] Ruby > Hi, > > David Douthitt wrote: > > > > REASON 21 > > 21. Reserved words aren't. It's perfectly allowable to use an > > identifier that is a so-called "reserved word" as long as the parser > > doesn't perceive an amibiguity. This is a breath of fresh air. > > > > It is? I don't think anyone should use reserved words as normal variables. A compiler or interpreter writer should almost disallow reserved words as a matter of principle - though in extreme conditions, it might be useful to use them. > > Well, it's certainly nice for search purposes, general user > friendliness, and so on that variable names not be keywords. > > The big gotcha is: "... as long as the parser doesn't perceive an > ambiguity.". This gives the usability of this feature a somewhat > counter-intuitive Perl-like dependency on context. If you had a (say > "AI") program that dynamically generated Ruby code that turned incoming > text words (say with _a_ being substituted for apostrophes and so on) > into variable names, your code would likely be sooner or later tripped > up by this feature. > > Does use of this feature trip up vim and emacs syntax highlighters? > > Perhaps use of this feature is something that -w mode should always > complain about. > > But first, I would like to know why this feature was implemented the way > it was. Were there any strong reasons for it, was it something that > seemed interesting to do at the time, or what? > > -- > Conrad Schneiker > (This note is unofficial and subject to improvement without notice.) >