[#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:4612] Object#inspect
A suggestion regarding Object#inspect: I feel that the Object#inspect feature should be unfolded into several procedures. Currently the code for inspect seems to be mostly in the Array and Hash classes/files, and the entry point seems to be only the Object#inspect method. This seems bad for those trying to implement containers. Also this is bad for when you don't want to show certain fields in an inspect. I have several ideas. First of all, just implementing your own inspect as a simple call to #each doesn't protect you from loops (or from repeating yourself in cases where it matters). there are #inspected? / #protect_inspect methods/procs, but they are not in Ruby, they are only in the internals. Second, there could be a method in Object called #fields_to_inspect which would return fields that should be inspected; or there could be a method #fields_not_to_inspect (a reversed effect). There is also the case when you only want to see "#<%s:0x%8x>" % [type,__id__*2] (the default Object#to_s), which is not hiding the field, but not a full sub-inspect on that field. There is also the case when you want the ability to distinguish between "..."'s and actually associate them to other parts of the dump, like Perl's Data::Dumper does. More generally, in dumping object contents there's a difference between what's useful to see as a user, and what's useful for freezing/thawing of an object (which allows a reasonable way to clone Objects across address spaces using eval, for purposes of persistency/IPC. Also there is a difference between what you wish to see as a user, and what's generally useful/wanted by users; if this is an important difference, it might be worthwhile to create a class of Dumper objects that hold the options for dumping/inspecting. It might also be worthwhile to use Dumper objects simply to hold the set of visited objects. _________________________________________________________________ matju | Sevareid's Law: The chief cause of problems is solutions.