On 2009-Aug-19, at 4:38 pm, 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.
I was thinking === rather than eq might be enough distinction, but
you're right, confusion is too likely.
Maybe $
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,|
| E-ma
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 t
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 fact
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
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
want
On Tue, Aug 18, 2009 at 15:20, Carl Mäsak 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 opaque
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 any
+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 underwater.
On Tue, Aug 18, 2009 at 3:20 PM, Carl Mäsak 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.
>
> To quote Kernighan and Pike: Simplicity. Clarity. Generality.
> I
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
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 di
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 trou
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
On Tue, 18 Aug 2009, Troels Liebe Bentsen wrote:
Glob's are special and should properly have it's own sub format, the problem of
including * and ? in Path's is that on Unix this is a allowed file system name.
Agreed about the subformat, but I think the "glob" function is
sufficient in this c
On Mon, Aug 17, 2009 at 23:11, Jon Lang wrote:
>> The default p{} should only allow "/" as separator and should not allow
>> characters that won't work on modern Windows and Unix like \ / ? % * : | " >
>> <,
>> etc. The reason for this is that portable Path's should be the default and if
>> you re
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 wrapped
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 wo
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 w
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
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 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? If so, could you
give some examples of how such a distinction c
On Sat, Aug 15, 2009 at 7:17 AM, Timothy S. Nelson 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 specify a file
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 str
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, 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 ba
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,
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
On Fri, Aug 14, 2009 at 7:41 PM, David Green 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 percentage
encoding
On Aug 14, 2009, at 16:17 , Mark J. Reed wrote:
On Fri, Aug 14, 2009 at 3:35 PM, Darren
Duncan wrote:
Under Mac OS X, all drives, root or otherwise, are accessible under
'/Volumes//...', and Unix in general lets you mount
drives
anywhere. I imagine Windows supports more ways of denoting driv
On Fri, Aug 14, 2009 at 3:35 PM, Darren Duncan wrote:
> Under Mac OS X, all drives, root or otherwise, are accessible under
> '/Volumes//...', and Unix in general lets you mount drives
> anywhere. I imagine Windows supports more ways of denoting drives than the
> drive letter.
Nope. Have to use
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
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
constr
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:
IO::F
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, Aug 14, 2009 at 12:34 PM, David Green wrote:
> Of course, this being P6, we can have some kind of "io" macro that parses
> the single item after it:
>
> my $file1 = io file://some/dir/some%20file; # the
> quick way
I don't think that's a good idea. In general, parsin
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 equi
On 2009-Aug-13, at 10:25 am, Hinrik Örn Sigurðsson wrote:
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. That
way Str wouldn't have all these file test methods, which is good
because
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 (
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. Tha
40 matches
Mail list logo
