From: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>
To: Tomi Ollila <tomi.ollila@iki.fi>, notmuch@notmuchmail.org
Subject: Re: [PATCH 0/9] test: (hopefully) better test prerequisites
In-Reply-To: <yf6wrayg83d.fsf@taco2.nixu.fi>
References: <1321494986-18998-1-git-send-email-dmitry.kurochkin@gmail.com>
	<874ny36rhc.fsf@servo.finestructure.net>
	<yf64ny3gcu4.fsf@taco2.nixu.fi> <8739dmopcu.fsf@gmail.com>
	<yf6wrayg83d.fsf@taco2.nixu.fi>
User-Agent: Notmuch/0.10_rc1+9~g8270095 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Thu, 17 Nov 2011 19:17:16 +0400
Message-ID: <87zkfun5hf.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Thu, 17 Nov 2011 16:02:46 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> On Thu, 17 Nov 2011 17:22:41 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> > Hi Tomi.
> > 
> > On Thu, 17 Nov 2011 14:20:19 +0200, Tomi Ollila <tomi.ollila@iki.fi> wrote:
> > > 
> > > I.e. dynamically, at run-time, re-create test_emacs function...
> > > 
> > 
> > Could you please add some human-friendly description on what benefits
> > the code above has? :)
> 
> "All problems in computer science can be solved by another level of indirection"
> 
> > The only change I see (besides code refactoring) is 30sec timeout (BTW
> > you can replace the list of numbers with "seq 30") instead of infinite
> > wait loop.  Which may be a good, but unrelated change.
> 
> Can't do `seq 30` it is not portable. BSD world uses different command.
> 
> > As for re-creating functions dynamically, I find the above code more
> > complex than the existing one.  I think the current code is more
> > shell-style and easier to understand.  Just IMHO.
> 
> Think it as a function pointer (I should have renamed that as test_emacs_p ;)
> 
> Shell is hyper-dynamic being (like python). New functionality can be
> written 'on-the-fly' inside functions (often without eval) Even variables 
> can be referenced as function names. Hmm, even perl4 has this way of 
> working supported...
> 
> IMHO it is simpler when one get's used to.
> 

I have no problem with thinking about it as a function pointer.  The
problem is that shell does not have function pointers :)

I am all for abstraction.  And I like lisp and haskell :) But it should
make things easier and more clear, not more complex.  IMO the old code
is easier to follow.  E.g. at any moment I understand what the function
would do, depending on the EMACS_SERVER value.  With functions being
dynamically overwritten, I have no idea what code would be executed when
the function is called.

Another point: EMACS_SERVER variable and the "function pointer" are kind
of duplicating each other.  And both have to be in sync which brings
possibility for new bugs.

If we follow this pattern than all code like:

  f() {
    if (!done_once)
        do_once

    do_more
  }

Should be rewritten using dynamic functions. I do not think I agree with
this :)

Anyway, all above is just IMHO.  You should probably go ahead and
prepare a patch implementing this approach for others to review.

> ... just that the test "framework" needs some refactoring... along the
> way all of these "practises" should be defined. code style, variable names
> consistency, etc...  
> 

Yeah, there are some rough edges.  But it is just a test suite.  I care
more about core notmuch and emacs UI :)

> You've done good work with this 'prereq' -thing.

Thanks.

> It's just hard to see
> the elegance here.

Come on, it is sooo obvious :)

Regards,
  Dmitry

> I know this very well as I have to maintain my
> own 'evolutionary' developed code -- when priority is on short-term
> cost savings over code consistency..
> 
> > 
> > Regards,
> >   Dmitry
> > 
> > > 
> > > Tomi
> 
> Tomi