Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Wed, 16 Mar 2005 23:31:10 +0100
Subject: Re: Gump3 or Gump 2.1
From: Leo Simons <mail@leosimons.com>
To: Gump code and data <general@gump.apache.org>
Message-ID: <BE5E723E.1FB2D%mail@leosimons.com>
In-Reply-To: <0dc501c52a70$b0264910$6501a8c0@sybase.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Brain dump :-D

On 16-03-2005 22:39, "Adam R. B. Jack" <ajack@apache.org> wrote:
>> What would you enjoy most? :-D
>> 
> Getting insights into a worldview outside of my head, and learning from/with
> others. :-)
> 
>> /I/ would love to see you helping out with Gump3.
> 
> I'll give it a shot.
> 
> I don't quite share your views that Gump needs to be so componentized, but
> (1) I don't object to them and (2) I do see a lot I'd do differently another
> time around & would like to tinker.

It doesn't have to be "components" or "plugins". Those are big words that
are fun because they sound intelligent and ring a bell with many people. As
long as its "KISS" I'm happy. Small testable units. Small testable functions
would do just as well and I'm definitely springkling those around where it
makes sense. The subwiki codebase is one example of a function table based
design in python that's extremely "componentized" in many ways :-D.

It's just that I'm so used to class-based programming, so that's how some of
it wound up. I'll argue though that plugging in various instances in
different locations is easier to understand than having lambda functions,
along with apply() and eval() and lots of metaprogramming. The latter is
perhaps less coding work, but a lot more thinking work :-D.

As I pick a new piece of work to get started on (built the beginnings of a
model verifier for example), I tend to spend a lot of time reading through a
lot of the code you wrote, which really is very educational. Try it :-D. It
works both ways...

1) Where is the code in Gump2 that handles the stuff that the
gump.engine.modellier.Verifier is supposed to do in Gump3? How do both of
them work and what's the difference?

2) Where is the code in Gump3 that handles the complete() functionality
found throughout the gump.model in Gump2? Why is it there and not part of
the model?

3) What are the extension points in Gump2 for adding a new build command
(for example, an <automake/>)? Where are they in Gump3? Which one is easier,
which one more intuitive? What would be optimal?

4) How does classpath management work in Gump2 and how could that be
"componentized" into the Gump3 system without leading to clutter or making
the core bits "language-aware"?

There are *so* many design questions like that to ask and so many answers to
be devised. It would amount to a whole lot of e-mails ;-)

--

Talking about "worldviews", I'm guessing that this test-based approach to
development I'm advocating is also something you're not that used to along
with a lot of people around here (I guess that's an assumption based on the
fact that gump2 doesn't have that many unit tests in relationship to the
amount of code and features it has, and gump1 was totally untestable). I
admit I've not been very disciplined about full test coverage, but I'm
definitely working towards it.

Maybe you'd like to take a stab at that as well, it's very liberating.
Really!

For example, look at my last commit on the Gump3 branch. Among other things,
I changed a whole bunch of

  assert isinstance(blah,str)

to

  assert isintance(blah,basestring)

Which I had to do because the DOM library returns unicode strings (which I
found out when doing a './gump run', which I hadn't done in a while as I was
cleaning up code. I got an AssertionError). When I found that problem, I
scattered some new code throughout the testModel.py test suite, creating
unicode() strings and feeding them to the model object. I wound up with a
nice list of test failures, making it trivial to be sort-of sure I fixed all
the assertions in the modelling code. Feels good! Of course, you can just
run tests using './gump test' and it takes only a few seconds to run them
all, which is kinda vital to productive test-based development.

Now, this made me realize that we probably need an assert_string(foo) method
in a utility library somewhere.

  test_assert_string(self):
    a = "blah"
    b = unicode(a)
    c = ""
    d = unicode(c)
    f = None
    f2 = self

    self.assert_(assert_string(a))
    self.assert_(assert_string(b))
    self.assert_(assert_string(c))
    self.assert_(assert_string(d))
    self.assert_(not assert_string(f))
    self.assert_(not assert_string(f2))

Followed by

  assert_string(argument):
    """Raises an AssertionError if the provided argument is not an instance
    of a string type. String types include 'str' and 'unicode'."""
    # Implementation note: unicode strings didn't exist in early versions
    # of python, but since we require 2.3 anyway for gump, that's not a
    # problem
    assert isinstance(argument,basestring), \
      "'%s' is not a string instance!" % argument

I've yet to implement that change. Anyone feel up to it? :-P

It gets more fun when the problem is complex and/or more difficult to test.
For example, could we figure out the test cases for our process management
woes? Once we do, writing the code that satisfies the tests will no doubt be
easy enough, or at least a lot easier.

Its those kinds of small steps which will lead to a much cleaner and much
more understandable codebase in the end. I'm sure it's worth it!


Cheers,


Leo


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org