Re: [gobo-eiffel-develop] another point regarding FILE_SET

[Eric B. <er...@go...>]

Sven,

I had a look at you implementation of FILE_SET yesterday.
First I had to slightly modify the code to make it compile.
For example in STRING_TOOLS the occurrences of FILESET_SCANNER
should be replaced by WC_TO_RX_CONVERTER, and in
WC_TO_RX_CONVERTER there is an "ensure else" instead of
"ensure then" and the line:

  a_wildcard_pattern := "^" + a_wildcard_pattern + "$"

should be removed since it is already done in
STRING_TOOLS.convert_wildcardexp_to_regexp.

Now, more general remarks. I think that using 'gelex' to
parse **/, * and ? is a little bit overkill. It shouldn't
be that difficult to implement that "by hand" (if you don't
feel like doing it -- if I remember corretly you told me
that you already tried it unsuccessfully -- I can do it).

The routine STRING_TOOLS.string_tokens should definitely go
in a (yet to be implemented) string library (see the archive
of this mailing list for small description I made some months
ago about what classes and routines this string library
should contain and how it should be organized). This string
library (to go in $GOBO/library/string) is still in my TODO
list and should start being implemented soon now.

And now for RX_FILESET_SCANNER, which as far as I understood
will be renamed as FILE_SET, this is surely a reusable class,
but I'm not sure where it should go in the Gobo libraries.
Although it includes directory traversal, I don't want it
to go in library/kernel/io because it uses regexps and as
a rule of thumb the library/kernel should only depend on the
Eiffel compilers' kernel libraries (and nothing else in the
rest of the Gobo libraries). I need some time to think about
that. Otherwise, without this constraint, we could have had
a routine in KL_DIRECTORY which would have taken a regexp
(or a list of regexps) as argument, and would have returned
a list (or set) of filenames either matching or not (one of)
the regexp(s). Hmmm, we could have a descendant of KL_DIRECTORY
outside of library/kernel to do that, but then where do we put
this new class?

Now in your last message you spoke about having two different
FILE_SET objects for the included and excluded files. I see
no reason why not doing that. Did you already try to implement
this idea with a small example?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com