On 26-05-2005 16:39, "Adam R. B. Jack" <[EMAIL PROTECTED]> wrote: >>> 1) Removed Homedir, since <home> isn't an output. >> >> Yes it is! Just think JAVA_HOME, ANT_HOME, JIKES_HOME, etc. A lot of > native >> code projects find each other via a "prefix" directory. Step out of the >> confines of the java world :-) > > I'm not thinking Java, I'm thinking Gump.[1] What you are describing is done > via properties [2]. > > That said, I'm game to come up with new ideas.
Yes please. Those docs are just confusing as hell. Please do take the lead here, you have more experience with the actual needs than I do :-) >>> 5) Zapped some tests. >> >> WHAT?!? Without reading on and knowing what this about (I see it has to do >> with removing Homedir), you really scared me :). We need more tests not >> less, and test removal really should be motivated well :-) > > The tests (based upon mock objects, or where a project is a 'string') are > incredibly simple to write when Gump3 is simple, but as it gets fleshed out > the tests are less and less practical. I did some DynaGumper work yesterday, > but stumbled 'cos the tests could no longer be made to work 'cos they passed > in a string for a project, not an object. Basically, the unit test's > simplicity is in the way. I strongly disagree here. A simple test that fails is usually, at a minimum, a test that can be "inverted" to test failure condititions. Passing a string for a project was a bad idea. Having a test for it was a good idea. Changing the code to not accept a string for a project is a good idea. Removing the test is a bad idea. Add a test that ensures failure if you pass a string for the project. Testing simple things is simple. Testing hard things is hard. We should work hard to make the hard things simple enough to be able to test them. That probably means DynaGumper needs to change a lot more so you can make the tests work. > With Gump2 I had unit tests running models I loaded from pre-defined test > workspaces. That worked, but it made things more like an integration test, > not a unit test. I think we need to make a whole "mock model" (irrespective > of XML format) and have the unit tests be able to tap into these. I'd > appreciate some help here. I thought about that, and I don't think we should be doing that. If you have small partial mock models (just enough to run a particular test), it helps you ensure that your code is loosely coupled. > Also, I want to do small/incremental commits, so we can view as we go. +1 > If that sometimes breaks unit tests, and forces a discussion, thatis fine by > me. I've got some reservations, but I suggest we don't discuss this much further. Every developer on the planet has a different opinion on how to be a developer. We'll see where we go :-) >> That's just ugly, right? > > Do I have to mark #UGLY to let you know I know? ;-) No, you need to let your mind soar and think of the beautiful alternative. I know you've thought about it (I read 4 years of gump e-mail the other day :-)), I just want to get you to live up to your own ideals. Aim high! > And to me. Please do read [1] below, as it might explain how it came into > existence. I will. >> I understand now why it was so hard to get this right in previous versions >> of gump. The design is seriously broken. It probably makes sense when > you're >> magically transforming xml into a bash script, but otherwise... > > Hindsight is 20/20, and although I didn't write it, I do take "credit" for > perpetuating not improving. Even in hindsight, the decision you made in "perpetuating not improving" with gump2 was the right decision and we all knew that then and there. I still know it. You have no right to blame yourself! > Thankfully we have Gump2 (heck, probably still > some Gump1s) working well (so there is broken, and broken broken ;-) and we > can take as much time, leveraging as many lessons as we can, to do Gump3. Exactly. - LSD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
