[#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:04504] Re: RubyUnit and encapsulation.
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> writes: > My_class's instance variables are not all "attr :<name>" type variables, > so some can only be accessed from inside the class. That is fine, it is > what OO is all about. Encapsulation is good. > It seems like 1 is the only sensible way to do this, and "If the > errors don't localise the bugs, then Tough!". Is such a question too > case-specific to have any useful general answer(s)? I wouldn't put it so negatively. Instead say: all that matters about my class is its external interface. Therefore, the first and most basic thing I must test is that interface. Do that. Then form an opinion. Are those tests revealing a multitude of internal bugs that are proving difficult to find because you only know that the external test fails? I'd suspect not. However, if I'm wrong, then you have a couple of options when it comes to increasing the scope of your testing: 1. Produce a subclass of your main class with accessors for the internal state and private functions (remember, you can override scope in a subclass in Ruby). 2. Refactor your main class. If you really are finding these kind of errors, then perhaps your main class is too complex. Maybe it should be refactored, allowing you to write tests for the refactored-out helper classes. However, I suspect that if you take the "don't do it until you need it" approach, you'll find that you won't need it. In any case, I would personally fight against breaking encapsulation just so I could test. Instead, I'd treat it as being a symptom of some deeper issue. > The implication seems to be that I should redesign my class, but in > what way(s)? My class currently holds arrays, hashes, and booleans > in a unified whole. Most of the methos setup the correct values in > these as files are processed. Not knowing the details, it's difficult to be specific, but perhaps an initial refactoring might involve separating the data storage (the interacting hashes, arrays etc) from the file reading. Regards Dave