Pathname


#1

About 6 months ago or so, I rewrote the Pathname library to internally
store a path as an Array instead of a String. It appears to be about
20% faster than the original and the code is a good bit less complex. I
no longer subscribte to ruby-dev and I’m not sure who is responsible
for such things, so I’m posting here. Would a Ruby developer like to
have a look and consider it as an update of the current lib?

Thanks,
T.


#2

Hi,

akr-san is responsible for pathname library.

						matz.

In message “Re: Pathname”
on Sun, 28 May 2006 11:56:05 +0900, removed_email_address@domain.invalid writes:
|
|About 6 months ago or so, I rewrote the Pathname library to internally
|store a path as an Array instead of a String. It appears to be about
|20% faster than the original and the code is a good bit less complex. I
|no longer subscribte to ruby-dev and I’m not sure who is responsible
|for such things, so I’m posting here. Would a Ruby developer like to
|have a look and consider it as an update of the current lib?
|
|Thanks,
|T.


#3

In article removed_email_address@domain.invalid,
removed_email_address@domain.invalid writes:

About 6 months ago or so, I rewrote the Pathname library to internally
store a path as an Array instead of a String. It appears to be about
20% faster than the original and the code is a good bit less complex. I
no longer subscribte to ruby-dev and I’m not sure who is responsible
for such things, so I’m posting here. Would a Ruby developer like to
have a look and consider it as an update of the current lib?

I don’t like it. A pathname may have different structure on
different environment.

I think rewriting it in C is appropriate way to make it faster.


#4

Tanaka wrote:

I think rewriting it in C is appropriate way to make it faster.

I won’t disagree with you there. So if that’s in the works than no
worries.

Two thoughts though. I liked being about to use << to add to a path.
Eg.

pn = Pathname.new(‘a/b’)
pn << ‘c’
pn #=> #Pathname:a/b/c

Some other array-like methods seem useful too, #each for instance.

More importantly, I think it would be nice if there were a shorter way
to define a path, perhaps a percent literal like %p{a/b}. Haing to
spell out Pathname.new all the time deters one from using it over a
simple String and the File class methods.

Thanks for responding Tanaka,
T.


#5

Daniel B. wrote:

removed_email_address@domain.invalid wrote:

More importantly, I think it would be nice if there were a shorter way
to define a path, perhaps a percent literal like %p{a/b}.

Good idea. I’m stealing it for pathname2. :slight_smile:

Well, I would have stolen it, except that I forgot that there’s no way
to define % literals in Ruby 1.8 afaik. I’m not sure about 1.9.

Related RCR: http://www.rcrchive.net/rcr/show/279

Regards,

Dan


#6

On May 30, 2006, at 12:55 AM, Daniel B. wrote:

Well, I would have stolen it, except that I forgot that there’s no
way to define % literals in Ruby 1.8 afaik. I’m not sure about 1.9.

Related RCR: http://www.rcrchive.net/rcr/show/279

Regards,

Dan

Well, is this close enough?

module Kernel
def pn(s)
Pathname.new(s)
end
end

pn %{a/b}

It almost looks like a % literal.


#7

removed_email_address@domain.invalid wrote:

pn << ‘c’
pn #=> #Pathname:a/b/c

Some other array-like methods seem useful too, #each for instance.

The pathname2 package already does this (although you use ‘+’ instead of
‘<<’).

More importantly, I think it would be nice if there were a shorter way
to define a path, perhaps a percent literal like %p{a/b}.

Good idea. I’m stealing it for pathname2. :slight_smile:

Regards,

Dan


#8

Although you just end up doing this

pn(‘a/b’)

when it’s within other calls anyway. Plus it’s yet another pass through
kernel method. Maybe this would be better:

$P = lambda { |s| Pathname.new(s) }

$P[‘a/b’]

Just a thought.
T.


#9

2006/5/31, removed_email_address@domain.invalid removed_email_address@domain.invalid:

$P = lambda { |s| Pathname.new(s) }

$P[‘a/b’]

class << Pathname
alias [] new
end

Pathname[‘a/b’]

P = Pathname
P[‘a/b’]