At 04:46 PM 2/25/2002 -0500, Magesh Umasankar wrote:
On the same note, isn't <include> too another
name for <filenamecull>?  You cull those files
which match a specified file name pattern.

No, I would say that <include> is the thing that can _add_ entries to a pattern and <exclude> is the thing that can take entries back out but only once they are put in by an <include>. Now, with cullers and selectors, there are other things that can take entries out of a pattern. Thus, <exclude> is a form of culler/selector whereas <include> is its own beast.


Anyway, the basic difference _conceptually_
is you ask the user to select a set of files
using <include> and then select a subset of
them. Whereas, my proposal lets the user to
select just the set of files that is needed.

Huh? Did I completely misunderstand your code?

My understanding is that selectors cannot add entries to a pattern, despite their name. They can only choose to veto the entries supplied by an <include>. So if you have two files like:

File.java - 10K
File.class - 8K

then this:

<fileset>
  <include name="*.java">
    <selector type="size"
      operation="greater-than"
      value="4K"/>
  </include>
</fileset>

selects only File.java, despite the fact that File.class passes the selector condition. Looks to me like it is selecting a subset of the files indicated by <include>, as well. If I am confused about this, then this is another argument against selectors since I doubt I'd be the only one confused (although perhaps I just confuse easily).

Let us say, I want to include all files
that have a size > 4 K but exclude those
that are readonly with names beginning
with "Test" with extension "jar" whose size
is greater than 5K

 <fileset>
     <include name="**/*">
         <selector type="size"
             operation="greater-than"
             value="4K"/>
     </include>
     <exclude name="**/Test*.jar">
         <selector type="permission"
             value="r"/>
         <selector type="size"
             operation="greater-than"
             value="5K"/>
     </exclude>
 </fileset>

How would you do that in your proposal?

(I pasted in your corrected version above).

You want a way to specify that all cullers should agree before a file is culled. Not a problem:

<fileset>
    <include name="**/*">
    <sizecull size="4" units="k" when="less"/>
    <agreecull>
        <sizecull size="5" units="k" when="more">
        <permcull attrib="readonly"/>
        <filenamecull name="**/Test*.jar/>
    </agreecull>
</fileset>

But your example is carefully selected, which demonstrates my point. It relies on the selection being related to the file name. If you remove that requirement, the problem becomes: I want to include all files that have a size > 4 K but exclude those that are readonly whose size is greater than 5K. The answer flows nicely out of the problem:

<fileset>
    <include name="**/*">
    <sizecull size="4" units="k" when="less"/>
    <agreecull>
        <sizecull size="5" units="k" when="more">
        <permcull attrib="readonly"/>
    </agreecull>
</fileset>

The solution using selectors, though, is a little bizarre because it involves an <exclude> that starts off excluding everything, and then relies on its selectors to trim it to size. Is this trip really necessary?

<fileset>
    <include name="**/*">
        <selector type="size"
            operation="greater-than"
            value="4K"/>
    </include>
    <exclude name="**/*">
        <selector type="permission"
            value="r"/>
        <selector type="size"
            operation="greater-than"
            value="5K"/>
    </exclude>
</fileset>


I am not saying I am happy with the generic
way in which I have implemented it - I recognize
though that there is no _clean_ solution
in Ant1, where we can have Ant's selectors and
user-defined pluggable selectors match up in
syntax.

Ahh, but why is that necessary? What benefit is there in forcing every selector/culler into the same straightjacket?


With the cullers proposal, <sizecull> and <extendcull> are two different tags, with different attributes. User-defined cullers have to "match up" with the <extendcull> syntax, but there is still freedom for the standard cullers to do the right thing. I don't see a benefit to limiting all of them to a single interface, just because they belong to the same general category.

Yes, that had been pointed out earlier.
I was planning to rework it such that it
could be defined from build.xml as well,
just as you say youhave done it.

If it will help, I can clean up <extendcull> and post it. Let me know.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



Reply via email to