Path.java update

[Thomas Haas <th...@haas-wyss.ch>]

Hi

Finally I had a closer look at Path.java and got rid of some stuff.
Thanks to Conor and Stephan for pointing at the problems.

Changes:

   * Remove inner class PathElement (there was really no use for it
     anymore)
   * Simplyfied translatePath method. DOS path detection changes:
     detection is only done, when PathSeparator is ";". It only checks
     for the second character being ":".
   * New translateFile method

What:
The Path class shall be used to represent path like strutuctures in Ant.
A path is a list of elements. Each element is a file or a directory. It
can be used to define CLASSPATH or PATH.


Discussion:
Prior to committing Path.java, we should decide on the translatePath
method, as there is another in Project. No matter where the methods go,
they should be accessible without a reference to Project, as this was my
problem and reason to redo translatePath as static method in Path.
May the functionality could be placed in a object of its own. Maybe even
in a way to allow people to replace the implementation of
translateFile/Path with their own.

- tom

Re: Path.java update

[Stefan Bodewig <bo...@bost.de>]

>>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:

 TH> Hmm, no. Absolut DOS file names should only be considered, if
 TH> running under DOS/Windows.

You are right.

Stefan

Re: Path.java update

[Thomas Haas <th...@softwired-inc.com>]

Thomas Haas wrote:

> Stefan Bodewig wrote:
>
> >  TH> Simplyfied translatePath method. DOS path detection changes:
> >  TH> detection is only done, when PathSeparator is ";". It only checks
> >  TH> for the second character being ":".
> >
> > I'm not sure this is a good thing. First you'd better check for
> > PathSeparator being not ':' instead of equals ';'.
>
> Done.

Hmm, no. Absolut DOS file names should only be considered, if running under
DOS/Windows. DOS/Windows detection is reduced to path seperator being ';'.
Which should be sufficent.
Support for other platforms should be added as soon as someone needs it and
really knows, what should be done.

- tom

Re: Path.java update

[Stefan Bodewig <bo...@bost.de>]

>>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:

 TH> However I may be pleased by doing it the other way round: let
 TH> translatePath first split the path into single elements and then
 TH> call translateFile for each element. What do you think?

Of course, this is the cleanest solution.

But this would mean you'd need to scan the full path twice, first to
split the path (and do the DOS check to detect ':') and then once
again. I feel the primary intention of Project.translatePath was to
avoid this - else you could do the / \ replacement with two
String.replace calls instead of the loop.

Personally I don't think you would notice the difference - how many
Path's do we need to split?

Stefan

Re: Path.java update

[Thomas Haas <th...@softwired-inc.com>]

Stefan Bodewig wrote:

> >>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:
>
>  >>  You could simply call translatePath for single >> filenames as
>  >>  well, couldn't you?
>
>  TH> translatePath returns a list of Strings, whereas translateFile
>  TH> returns a single String and does not mess with path separators.
>
> So just use the first one? Maybe
>
>     public static String translateFile(String source) {
>         if (source == null || source.length() == 0) return "";
>         return (String) translatePath(source).elementAt(0);
>     }
>
> instead of duplicating the / \ replacement. "Once And Only Once" to
> cite an XP mantra - that I wouldn't follow religously of course.

I dislike the dubilcate effort done here aswell. I decided to do it that
way mainly because of two reasons:

   * I did not want to ignore the case where more than one element is
     retuned, maybe just fail.
   * Strange platforms using : or ; differently can still be satisfied by
     not using translatePath.

However I may be pleased by doing it the other way round: let
translatePath first split the path into single elements and then call
translateFile for each element. What do you think?

- tom

Re: Path.java update

[Stefan Bodewig <bo...@bost.de>]

>>>>> "TH" == Thomas Haas <th...@softwired-inc.com> writes:

 >>  You could simply call translatePath for single >> filenames as
 >>  well, couldn't you?

 TH> translatePath returns a list of Strings, whereas translateFile
 TH> returns a single String and does not mess with path separators.

So just use the first one? Maybe

    public static String translateFile(String source) {
        if (source == null || source.length() == 0) return "";
        return (String) translatePath(source).elementAt(0);
    }

instead of duplicating the / \ replacement. "Once And Only Once" to
cite an XP mantra - that I wouldn't follow religously of course.

Either source doesn't include a PathSeparator or it's a : on DOS based
systems (forgot OS/2 in my list) or we are in trouble anyway.

Stefan

Re: Path.java update

[Thomas Haas <th...@softwired-inc.com>]

Stefan Bodewig wrote:

> Your attachment has an interesting MIME type
> (application/x-unknown-content-type-visualcafefile.document) haven't
> seen something like this before 8^). Must be Windows I guess.

Yes - an old '95 machine at home. Had Visual Cafe installed once (long,
long time ago). '95 still remembers those days and associates everything
.java with Visual Cafe. Long time ago I should have cleaned up (and
installed Linux) ;-)


> >>>>> "TH" == Thomas Haas <th...@haas-wyss.ch> writes:
>
>  TH> Simplyfied translatePath method. DOS path detection changes:
>  TH> detection is only done, when PathSeparator is ";". It only checks
>  TH> for the second character being ":".
>
> I'm not sure this is a good thing. First you'd better check for
> PathSeparator being not ':' instead of equals ';'.

Done.


> I've forgotten what VMS uses as a Path separator - too long ago - but
> it does have (logical) drive names separated from the rest of the
> filename by a : - and the drive name was anything but limited to one
> character BTW.
>
> The ; separated the version of a file from the rest of the filename so
> I doubt they would use ; as a separator.
>
> In the common case - i.e. Unix, Windows and Mac - your assumptions are
> correct but there are different beasts out there that could be better
> suited by the older version.

Correct. Path.translatePath does not better than Project.translatePath. To
me the problem can only be solved by customizing things. As you point out,
this may not be worth the effort.


>  TH> * New translateFile method
>
> For completeness? You could simply call translatePath for single
> filenames as well, couldn't you?

translatePath returns a list of Strings, whereas translateFile returns a
single String and does not mess with path separators.


>  TH> we should decide on the translatePath method, as there is another
>  TH> in Project.
>
> Yes, there are some other helper methods that don't really belong into
> Project (copyFile and toBoolean) and Path seems a far more natural
> place for the translate methods.
>
>  TH> May the functionality could be placed in a object of its
>  TH> own. Maybe even in a way to allow people to replace the
>  TH> implementation of translateFile/Path with their own.
>
> Don't think we would gain much from this flexibility. IMHO it's
> overkill but I could live with it.
>
> Stefan

thanks for your comments.
- tom

Re: Path.java update

[Stefan Bodewig <bo...@bost.de>]

Your attachment has an interesting MIME type
(application/x-unknown-content-type-visualcafefile.document) haven't
seen something like this before 8^). Must be Windows I guess.

>>>>> "TH" == Thomas Haas <th...@haas-wyss.ch> writes:

 TH> Simplyfied translatePath method. DOS path detection changes:
 TH> detection is only done, when PathSeparator is ";". It only checks
 TH> for the second character being ":".

I'm not sure this is a good thing. First you'd better check for
PathSeparator being not ':' instead of equals ';'. 

I've forgotten what VMS uses as a Path separator - too long ago - but
it does have (logical) drive names separated from the rest of the
filename by a : - and the drive name was anything but limited to one
character BTW.

The ; separated the version of a file from the rest of the filename so
I doubt they would use ; as a separator.

In the common case - i.e. Unix, Windows and Mac - your assumptions are
correct but there are different beasts out there that could be better
suited by the older version.

 TH> * New translateFile method

For completeness? You could simply call translatePath for single
filenames as well, couldn't you?

 TH> we should decide on the translatePath method, as there is another
 TH> in Project.

Yes, there are some other helper methods that don't really belong into
Project (copyFile and toBoolean) and Path seems a far more natural
place for the translate methods.

 TH> May the functionality could be placed in a object of its
 TH> own. Maybe even in a way to allow people to replace the
 TH> implementation of translateFile/Path with their own.

Don't think we would gain much from this flexibility. IMHO it's
overkill but I could live with it.

Stefan