gobo-eiffel-develop

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

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

Sven Ehrke wrote:
> 
> Hello Eric,
> 
> so far the FILE_SET class has several queries for the included files, the excluded files, and many others
> which more or less have to do with set operations. This is due to the fact that I would like to make file sets
> available for geant.
> This morning I had the idea the the FILE_SET class should only support one set of files so that there would
> be only one query instead of all those it supports now. Then there could be commands like `subtract', `add'
> `intersect' and so on. The <fileset> task/command internally would use two FILE_SETS internally: one for
> the things to include and one for the things to exclude. I am quite sure that I can reuse a lot from DS_SET.
> This would make FILE_SET much smaller and more flexible.

I promise that as soon as I come back home this weekend
I'll stop working on other things and review your file-set
implementation. But in the meantime your idea above seems
interesting indeed.

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

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

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

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

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

Sven Ehrke wrote:
> 
> I think the functionality of the fileset should not be mixed into KL_DIRECTORY.

I agree with that, for the reasons I gave in my previous message.
But on the other hand if you look at KL_DIRECTORY.filenames, isn't
that just a special case of the functionality we are talking about,
where the wildcard regular expression is *?

> What about somewhere under library/utility?

Yes. What do you suggest for the cluster name?

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

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

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

On 20/10/2001 at 8:01 PM Eric Bezault wrote:

>Sven Ehrke wrote:
>> 
>> I think the functionality of the fileset should not be mixed into
>KL_DIRECTORY.
>
>I agree with that, for the reasons I gave in my previous message.
>But on the other hand if you look at KL_DIRECTORY.filenames, isn't
>that just a special case of the functionality we are talking about,
>where the wildcard regular expression is *?

That's right. But I would prefer to have KL_DIRECTORY.filenames
as it is now rather than having a `filename' which tries to handle all=
 possible
cases (maybe including the ** notation as well). This would either
make `filenames' really complex or result in many more features
in KL_DIRECTORY.
The way it is now it provides the base for extended
functionality which can be built outside.

>
>> What about somewhere under library/utility?
>
>Yes. What do you suggest for the cluster name?

Maybe we could call it 'io' to be symmetrical with the kernel?
If you find that too general we could call it 'filesystem'.

- Sven

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

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

Sven Ehrke wrote:
> 
> That's right. But I would prefer to have KL_DIRECTORY.filenames
> as it is now rather than having a `filename' which tries to handle all possible
> cases (maybe including the ** notation as well). This would either
> make `filenames' really complex or result in many more features
> in KL_DIRECTORY.

I was not suggesting having a more complex `filenames' routine.
I was just saying that `filenames' is in the same category of
routines as the one we are talking about, so apart from other
considerations explained in previous messages, I don't see
why we should have one and not the other.

> The way it is now it provides the base for extended
> functionality which can be built outside.

Likewise if `filenames' was not implemented in KL_DIRECTORY.

Don't get me wrong. In practice we will end up keeping
`filenames' in KL_DIRECTORY and having the new functionality
in an external class in another library. But in theory I
don't see any difference between the two routines in 
terms of functionality and therefore (still in theory)
they should be either both in KL_DIRECTORY or both outside
in a common external class.
 
> Maybe we could call it 'io' to be symmetrical with the kernel?

Yes, good idea.

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

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

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

>Don't get me wrong. In practice we will end up keeping
>`filenames' in KL_DIRECTORY and having the new functionality
>in an external class in another library. But in theory I
>don't see any difference between the two routines in 
>terms of functionality and therefore (still in theory)
>they should be either both in KL_DIRECTORY or both outside
>in a common external class.

I agree completely (in theory and practice ;-) )

- Sven