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

[Sven E. <sve...@we...>]

On 20/10/2001 at 6:09 PM Eric Bezault wrote:

>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 :=3D "^" + a_wildcard_pattern + "$"
>
>should be removed since it is already done in
>STRING_TOOLS.convert_wildcardexp_to_regexp.
>

sorry for the confusion.

>Now, more general remarks. I think that using 'gelex' to
>parse **/, * and ? is a little bit overkill. It shouldn't

Yes, I am aware of this. At the beginning I just did not want
to spend too much time on this since it can be optimized now.

>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).

It would be great if you have the time to 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

I am aware of this too. Some stuff from geant could be removed
then as well. There is also a class UT_STRING_ROUTINES
in library/tools/xace/support which could be removed then.

>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?

I think the functionality of the fileset should not be mixed into=
 KL_DIRECTORY.
What about somewhere under library/utility?

Another note here: in the current implementation only files are considered=
 but I
could imagine that directories could be taken into account as well. I am=
 not
sure yet if it would make sense to have them in the same class like

  XX_FILE_SYSTEM_ENTRY_SET

or having two classes

  XX_FILE_SET
  XX_DIRECTORY_SET

with a parent class for the common functionality.

>
>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?

Not yet. Although this example is a special case for geant it would
be a good starting point. I'll try to make something up this weekend.

Thanks for looking into this.

- Sven