RE: Re[2]: Brain Dump of Towards FIT 1.0 OpenSpace session

Michael,

Thanks, we needed that. :-)

I enjoyed the article and it matches some of my experience.

One of the things I've noticed about attempts to reuse software
across a product line is that people often end up including the union
all the features that the various products use. I've had more success
by limiting such reusable components to the intersection of the features
and by making sure they were easily extensible.

That's not quite the same as a framework, of course, because one can
observe exactly what features are used. However, I think it's pretty
close to what we would see if we /could/ observe actual usage. And
we might actually get some mileage out of thinking about the various
fit implementations as "products" in a "product line." We obviously
won't share code between the different implementations but we might
share concepts and the implementations could package the their code
in three layers - two of which we would provide:

                            Core Fit Concepts

                      Language-specific Extensions

                             User Extensions

Of course, it's an incredibly simple idea, so others have probably
thought about it. Is it worth  considering?

Charlie Poole
[email protected]
www.pooleconsulting.com
www.charliepoole.org



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Michael Feathers
> Sent: Friday, August 22, 2003 9:43 AM
> To: [email protected]; [email protected]
> Cc: [email protected]
> Subject: Re[2]: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace
> session
>
>
>
> I was getting ready to make a suggestion, but then I realized that I
> had already written it up a while ago.  I offer these thoughts in the
> sincerest hope that they can help:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=8826
>
>
> Michael Feathers
>
>
> fjc> ----- Original Message -----
> fjc> From: "Al Chou" <[email protected]>
> fjc> To: "FIT Developers"
> <[email protected]>
> fjc> Sent: Friday, August 22, 2003 2:16 AM
> fjc> Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0
> OpenSpace session
>
>
> >> > > Thanks for the clarification, John.  OK, so let's
> substitute "FIT" for
> >> > > "FitNesse" in my original question.  Rather than (or in
> addition to,
> fjc> for
> >> > those
> >> > > languages that have no Java compatibility) having FIT
> re-implemented
> fjc> in
> >> > > numerous languages, why not have one core FIT that allows
> fixtures to
> fjc> be
> >> > > written in whatever language you choose?
> >> >
> >> > It's an interesting thought. You'd need an interface program in the
> >> > target language, though. You'd also need to do a considerable amount
> >> > of reengineering of the FIT core, and you'd have to insure that the
> >> > new style fixtures weren't substantially more difficult to write than
> fjc> the
> >> > older style fixtures.
> >>
> >> I guess the re-engineering might be in the form of having some core
> fjc> facility
> >> that would parse the HTML tables and send the meaning of the
> data therein
> fjc> to
> >> the fixture (so as not to be forced to implement type adapters in every
> >> language in which one wants to write fixtures, as you mention below).
> fjc> There's
> >> some perhaps difficult decoupling of the functionality in the current
> fjc> concept
> >> of a fixture that would need to be done.  Or maybe implementing type
> fjc> adapters
> >> in a language is the price that language's users have to pay
> in order to
> fjc> play
> >> with FIT.  It's less coding than re-implementing _all_ of FIT in the
> fjc> target
> >> language, right?
>
> fjc> Since the FIT core doesn't have access to the fixtures,
> there's no way
> fjc> it can know what the actual data types are without a lot of
> communication
> fjc> at the start of table interpretation. Also, it makes it very
> difficult to
> fjc> handle
> fjc> language and application specific type adapters.
>
> fjc> I don't see enough benefit to justify the additional
> complexity. In fact,
> fjc> at one point I thought of pushing type conversion to the fixtures
> fjc> themselves; the fixtures, after all, know what's needed
> better than some
> fjc> global framework. It's still an idea that has a bit of an appeal.
>
> >> Though it just occurred to me that if the interface/protocol used to
> >> communicate table data between the FIT core and the fixtures included a
> fjc> set of
> >> standard data types (reminiscent of XDR; or better, a set of
> fjc> self-describing
> >> data types, perhaps based on a core set of primitive types
> [such as n-byte
> >> integers, for integral types]), then type adapters could be implemented
> fjc> just
> >> once for all, and the main thing that would have to be provided per
> fjc> language is
> >> the protocol interpreter/translator.
>
> fjc> Standard data types are something we have to put up with when we're
> fjc> coupling systems built by different organizations to what
> are supposedly
> fjc> common specs. They are not something we should have to limit
> ourselves
> fjc> to in a test framework that is supposed to be customer friendly.
>
> >> > A much more lightweight text-based protocol would do fine.
> If you have
> fjc> to
> >> > have XML, so be it, but I consider it major overkill when
> all you need
> fjc> is to
> >> > transfer tables and counts back and forth.  A CSV variant would work
> >> > just fine.
> >> >
> >> > The more I think about it, the more I like it. There are a bunch of
> >> > possibilities here, I think.
> >> >
> >> > John Roth
> >>
> >> That's fine, I was just trying to point out possibilities that
> were new,
> fjc> at
> >> least to me.  I agree that there's no need for a heavy protocol yet, if
> fjc> ever.
>
> fjc> Here's a first cut at a protocol. It's basically a comma
> separated values
> fjc> (CSV)
> fjc> with one cell per line.
>
> fjc> Data sent to the language dependent stub have four fields:
> fjc> 1. table number - integer
> fjc> 2. row number - integer
> fjc> 3. column number - integer
> fjc> 4. content - character string with certain characters
> (comma, nl, lf, cr,
> fjc> esc) escaped.
>
> fjc> Data returned from the language dependent stub has more fields:
>
> fjc> 1. table number - integer
> fjc> 2. row number - integer
> fjc> 3. column number - integer
> fjc> 4. status - specific character values (see below)
> fjc> 5. returned value - character string (depends on status)
>
> fjc> status values:
>
> fjc> input-accepted (no return value)
> fjc> input-error message (error message returned)
> fjc> input-exception (stack trace returned)
>
> fjc> output-accepted (no returned value)
> fjc> output-incorrect (returned value)
> fjc> output-error message (error message returned)
> fjc> output-exception (stack trace returned)
>
> fjc> ignored (no returned value)
>
> fjc> However, there's a special case return for an inserted row:
>
> fjc> 1. I - literal character capital I
> fjc> 2. new row number - integer, counts from the last row in the
> original table
> fjc> 3. after row number - integer, row to insert this row after.
>
> fjc> Inserted columns are implicit; if the column number exceeds the
> fjc> highest number currently in the row, the row is extended.
>
> fjc> Escaping is always an issue with CSV, that's why there are so
> fjc> many different minor and incompatible variations out there!
> fjc> The escape character is a backslash.
>
> fjc> B - Backslash
> fjc> C - Comma
> fjc> n - new line
> fjc> r - carriage return
> fjc> l - line feed
>
> fjc> Note that to produce a backslash, you code \B, ***NOT*** \\,
> fjc> and to produce a comma, you produce \C, not \,.
> fjc> The reason for this rather unusual spec is that it makes the
> fjc> <string>.split(",") method work properly with the lines.
> fjc> The reasoning for the backslash is a bit murkier, but has to
> fjc> do with simplifying regex replacements.
>
> fjc> Another issue: ASCII or UTF-8? I'm leaning toward
> fjc> UTF-8, but I don't know how much trouble it would cause
> fjc> for other languages. Java is obviously cool, so is
> fjc> Python and I'd be very surprised if .NET couldn't handle
> fjc> it with ease. Ruby? Perl?
>
> fjc> Comments?
>
> fjc> John Roth
>
>
>
>
>
>
> >>
> >> Al
> >>
> >> =====
> >> Albert Davidson Chou
> >>
> >>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
> >>
> >> __________________________________
> >> Do you Yahoo!?
> >> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> >> http://sitebuilder.yahoo.com
> >>
> >> _______________________________________________
> >> Fit-dev mailing list
> >> [email protected]
> >> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev
>
>
> fjc> _______________________________________________
> fjc> Fit-dev mailing list
> fjc> [email protected]
> fjc> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev
>
>
>
> --
> Best regards,
>  Michael                            mailto:[email protected]
>
>
> _______________________________________________
> Fit-dev mailing list
> [email protected]
> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev
>