On 2009-Aug-18, at 7:20 am, Timothy S. Nelson wrote:
On Tue, 18 Aug 2009, David Green wrote:
Some ways in which different paths can be considered equivalent:
Spelling: ... Simplification: ... Resolution: ... Content-wise: ...
Ok, my next commit will have canonpath (stolen directly from p5's
I don't think $file1.name == $file2.name should talk to the FS,
because I think File#name t+r whatever) should return a plain Str.
Having magical FilePathName objects is handy, but sometimes you want
to get the filename as a dumb string to do stringish things without
having to worry about the
On Wed, 19 Aug 2009, Mark J. Reed wrote:
I don't think $file1.name == $file2.name should talk to the FS,
because I think File#name t+r whatever) should return a plain Str.
Having magical FilePathName objects is handy, but sometimes you want
to get the filename as a dumb string to do stringish
I should've mentioned, though, we're currently using the smartmatch
operator for this, so I'm thinking maybe I'll just stick with that.
:)
-
| Name: Tim Nelson | Because the Creator is,|
|
On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
Well, my main thought in this context is that the stuff that
can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are differences, but the two are
a lot
the
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making any more assumptions
is bound to get you into
On Tue, 18 Aug 2009, David Green wrote:
On 2009-Aug-17, at 8:36 am, Jon Lang wrote:
Timothy S. Nelson wrote:
Well, my main thought in this context is that the stuff that can be
done to the inside of a file can also be done to other streams -- TCP
sockets for example (I know, there are
Leon ():
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making any more assumptions
is bound to
On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak cma...@gmail.com wrote:
Let's make a solid ground to stand on; something so stable that it
works uphill and underwater. People with expertise and tuits will
write the facilitating modules.
PerlJam To quote Kernighan and Pike: Simplicity.
+1
Carl Mäsak wrote:
Very nicely put. We can't predict the future, but in creating
something that'll at least persist through the next decade, let's not
do elaborate things with lots of moving parts.
Let's make a solid ground to stand on; something so stable that it
works uphill and
On Tue, 18 Aug 2009, Leon Timmermans wrote:
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as opaque binary strings, making
On Tue, Aug 18, 2009 at 15:20, Carl Mäsakcma...@gmail.com wrote:
Leon ():
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. The only sane way to deal with filenames
is treating them as
Leon Timmermans wrote:
Reading this discussion, I'm getting the feeling that filename
literals are increasingly getting magical, something that I don't
think is a good development. [...]. I don't want to deal with Windows'
strange restrictions on characters when I'm working on Linux. I don't
Timothy S. Nelson wrote:
David Green wrote:
Jon Lang wrote:
If so, could you give some examples of how such a distinction could be
beneficial, or of how the lack of such a distinction is problematic?
Well, my main thought in this context is that the stuff that can be
done to the
Hey,
Just joined the list, and I too have been thinking about a good path literal
for Perl 6. Nice to see so many other people are thinking the same :).
Not knowing where to start in this long thread, I will instead try to show how
I would like a path literal to work. For me a path literal is a
Troels Liebe Bentsen wrote:
Hey,
Just joined the list, and I too have been thinking about a good path literal
for Perl 6. Nice to see so many other people are thinking the same :).
Welcome to the list!
Not knowing where to start in this long thread, I will instead try to show how
I would
On Mon, 17 Aug 2009, Jon Lang wrote:
Well, I definitely think there needs to be a class that combines the
inside and the outside, or the data and the metadata. Certainly the
separate parts will exist separately for purposes of implementation, but
there needs to be a user-friendlier view
On Sun, 16 Aug 2009, David Green wrote:
On 2009-Aug-15, at 9:22 am, Jon Lang wrote:
IOW, your outside the file stuff is whatever can be done without
having to open the file, and your inside the file is whatever only
makes sense once the file has been opened. Correct?
Pretty much,
On Fri, 14 Aug 2009, Darren Duncan wrote:
Richard Hainsworth wrote:
Would it be possible to remove the special purpose of \ from strings within
IO constructs?
This would mean '\' could be used in naming paths as an alternative to '/',
thus allowing windows and unix strings to be equivalent,
On Sat, 15 Aug 2009, Timothy S. Nelson wrote:
Considering, though, that we're talking about a magic perl quoting
syntax, we could offer people the option of the following two:
q:io{C:\Windows} # Does what you want
q:io:qq:{C:\\Windows} # Does the same thing
Wouldn't that cover the
This whole thread seems oriented around two points:
1. Strings should not carry the burden of umpty-ump filesystem checking
methods.
2. It should be possible to specify a filesystem entity using something
nearly indistinguishable from standard string syntax.
I agree with the first, but the
On Sat, 15 Aug 2009, Austin Hastings wrote:
This whole thread seems oriented around two points:
1. Strings should not carry the burden of umpty-ump filesystem checking
methods.
2. It should be possible to specify a filesystem entity using something
nearly indistinguishable from standard
On Sat, Aug 15, 2009 at 7:17 AM, Timothy S. Nelsonwayl...@wayland.id.au wrote:
On Sat, 15 Aug 2009, Austin Hastings wrote:
This whole thread seems oriented around two points:
1. Strings should not carry the burden of umpty-ump filesystem checking
methods.
2. It should be possible to
More ideas:
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote:
# bin/perl on Unix
my $rel = qf/usr bin perl/;
# /usr/bin/perl
my $abs = qf[/usr bin perl];
...and on Windows, would the above result in C:\/usr\bin\perl ? :)
# The following both result in the same object
I like this way.
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
This would mean '\' could be used in naming paths as an alternative to
'/', thus allowing windows and unix strings to be equivalent, eg.
IO(:path{$root-path}/data/new) would be
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote:
Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I
...or imagine just one, called IO::FSNode.
http://perlcabal.org/syn/S32/IO.html#IO::FSNode
Btw, kudos for the special quoting idea -- I love it
On Fri, 14 Aug 2009, Timothy S. Nelson wrote:
On Thu, 13 Aug 2009, Hinrik Örn Sigurðsson wrote:
Imagine two roles, Filename and Dirname (or Path::File / Path::Dir). I
...or imagine just one, called IO::FSNode.
Sorry, I was stupiding again. I'll ask you to imagine 4:
On 2009-Aug-14, at 5:36 am, Richard Hainsworth wrote:
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
It's P6, anything's possible! I probably wouldn't change [what look
like] ordinary quoted strings, but maybe something with a qf//-type
Richard Hainsworth wrote:
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
This would mean '\' could be used in naming paths as an alternative to
'/', thus allowing windows and unix strings to be equivalent, eg.
IO(:path{$root-path}/data/new) would be
On Fri, Aug 14, 2009 at 3:35 PM, Darren Duncandar...@darrenduncan.net wrote:
Under Mac OS X, all drives, root or otherwise, are accessible under
'/Volumes/drive-name/...', and Unix in general lets you mount drives
anywhere. I imagine Windows supports more ways of denoting drives than the
On Aug 14, 2009, at 16:17 , Mark J. Reed wrote:
On Fri, Aug 14, 2009 at 3:35 PM, Darren
Duncandar...@darrenduncan.net wrote:
Under Mac OS X, all drives, root or otherwise, are accessible under
'/Volumes/drive-name/...', and Unix in general lets you mount
drives
anywhere. I imagine Windows
On Fri, Aug 14, 2009 at 7:41 PM, David Greendavid.gr...@telus.net wrote:
Well, we can encode a URI any way we like -- I was thinking of anything up
to the next whitespace or semicolon, and internal semicolons, etc. being
%-encoded.
Semicolons are reserved characters in URIs: inappropriately
I'll just butt in here and say that while the URI format is nice for
alternate schemes, it is not nice for accessing files.
The general case in most programming languages is to assume that a
non-URI file name is local, specifying
file://wherever/whatever/filename is unnecessary additional syntax.
Hinrik Örn Sigurðsson wrote:
I was wondering if there had been any discussion about how to type
file and directory names in Perl 6. I've read a couple of posts about
file test operators, where some have suggested making filenames
special, either as a subtype of Str or something else entirely.
34 matches
Mail list logo
