Easy Pathname

Ruby
#1

I find myself always using File.join, and never utilizing Pathname b/c
it’s not as convenient to construct. This snippet occured to me to make
it more paletable:

class String
def /(dir)
Pathname.new( File.join(self,dir) )
end
end

class Pathname
def /(dir)
join(dir)
end
end

path = ‘’ / ‘usr’ / ‘local’ #=> #Pathname:/usr/local

Good idea? Improvements? Better alternatives?

T.

#2

On Jul 6, 2006, at 6:39 PM, [email protected] wrote:

T.

It’s neat but I’ve always thought that this should be the definition
of String#/:

class String
alias_method :/, :split
end

#3

Logan C. wrote:

It’s neat but I’ve always thought that this should be the definition of
String#/:

class String
alias_method :/, :split
end

Yeah, why isn’t it?

irb(main):015:0> “now is the time” / " "
=> [“now”, “is”, “the”, “time”]
irb(main):016:0> (“now is the time” / " ") * " "
=> “now is the time”
irb(main):017:0> (“now is the time” / " ") * “-”
=> “now-is-the-time”

Since Array#* is the same as Array#join when the arg is a string, it’s a
no-brainer to define String#/ like you did.

#4

On 7/7/06, Joel VanderWerf [email protected] wrote:

What about

path = Pathname[’’] / ‘usr’ / ‘local’ #=> #Pathname:/usr/local

A bit more palatable (?) without affecting String.

Even better would be for [] to split on “/” itself for literal paths:

path = Pathname[’/usr/local/src’]
path = Pathname[’/usr’]/foo/bar

martin

#5

Joel VanderWerf wrote:

path = Pathname[’’] / ‘usr’ / ‘local’ #=> #Pathname:/usr/local

A bit more palatable (?) without affecting String.

Except, what about paths not starting with root?

I wonder why Pathname.[] and Pathname#/ are not defined this way? The
former seems safe and conservative, at least. Maybe #/ is not defined
because #+ already has that behavior and it would be strange for + and /
to be the same.

#+ does? I would rathe plus did a straight concat like string.

T.

#6

[email protected] wrote:

class Pathname

Think about MS Windows. Then think about UNC paths.

Have fun.

  • Dan
#7

[email protected] wrote:

class Pathname
def /(dir)
join(dir)
end
end

path = ‘’ / ‘usr’ / ‘local’ #=> #Pathname:/usr/local

What about

path = Pathname[’’] / ‘usr’ / ‘local’ #=> #Pathname:/usr/local

A bit more palatable (?) without affecting String.

I wonder why Pathname.[] and Pathname#/ are not defined this way? The
former seems safe and conservative, at least. Maybe #/ is not defined
because #+ already has that behavior and it would be strange for + and /
to be the same.

#8

Daniel B. wrote:

Think about MS Windows. Then think about UNC paths.

What’s problem there?

T.

#9

On 7/7/06, [email protected] [email protected] wrote:

Daniel B. wrote:

Think about MS Windows. Then think about UNC paths.
What’s problem there?

They work differently than most people expect. Remember, on most
Windows paths, you need a drive: C:\Foo\Bar\Baz. But on UNC paths, you
need \server\share\Foo\Bar\Baz.

C:\ is like / and so is \server\share.

-austin

#10

In article
[email protected],
“Martin DeMello” [email protected] writes:

Even better would be for [] to split on “/” itself for literal paths:

path = Pathname[’/usr/local/src’]
path = Pathname[’/usr’]/foo/bar

I added Pathname() few weeks ago.

% ./ruby -rpathname -ve ‘p Pathname(“foo/bar”)’
ruby 1.8.5 (2006-07-07) [i686-linux]
#Pathname:foo/bar

#11

On 7/7/06, Tanaka A. [email protected] wrote:

% ./ruby -rpathname -ve ‘p Pathname(“foo/bar”)’
ruby 1.8.5 (2006-07-07) [i686-linux]
#Pathname:foo/bar

Tanaka A.

I don’t want to hijack this thread but I do think it would be nice if
Klass() were a synonym for Klass.new(). As far as I know, this
wouldn’t conflict with anything in the Ruby standard lib (apart from
Array(), String() and maybe some others which I forget). I personally
use it all the time for my own classes.

Regards,
Sean

#12

On 2006-07-08, Sean O’Halpin [email protected] wrote:

… I do think it would be nice if Klass() were a synonym for
Klass.new(). As far as I know, this wouldn’t conflict with anything
in the Ruby standard lib …

Yes it would:

$ irb
irb(main):001:0> x = Object.new
=> #Object:0xb7c8c7a8
irb(main):002:0> def x.to_i ; 42 ; end
=> nil
irb(main):003:0> Integer(x)
=> 42
irb(main):004:0> Integer
=> Integer
irb(main):005:0> Integer.new
NoMethodError: undefined method `new’ for Integer:Class
from (irb):5
from :0
irb(main):006:0>

Regards,

Jeremy H.

#13

Sean O’Halpin wrote:

I don’t want to hijack this thread but I do think it would be nice if
Klass() were a synonym for Klass.new(). As far as I know, this
wouldn’t conflict with anything in the Ruby standard lib (apart from
Array(), String() and maybe some others which I forget). I personally
use it all the time for my own classes.

Right now those functions are used as casting/conversion operators, and
I think
you should continue that “standard” if you defined your own Klass()
methods.
There’s little point in having 2 ways of doing MyClass.new really.

Daniel

#14

Austin Z. wrote:

On 7/7/06, [email protected] [email protected] wrote:

Daniel B. wrote:

Think about MS Windows. Then think about UNC paths.
What’s problem there?

They work differently than most people expect. Remember, on most
Windows paths, you need a drive: C:\Foo\Bar\Baz. But on UNC paths, you
need \server\share\Foo\Bar\Baz.

C:\ is like / and so is \server\share.

Okay, I realize that. But how is this not taking that into account
where as File.join or Pathname does?

T.

#15

Sean O’Halpin wrote:

I don’t want to hijack this thread but I do think it would be nice if
Klass() were a synonym for Klass.new(). As far as I know, this
wouldn’t conflict with anything in the Ruby standard lib (apart from
Array(), String() and maybe some others which I forget). I personally
use it all the time for my own classes.

I think its an elegant practice. I know others have argured that it is
too implicit, but if it were standard it would quickly seem rather
explicit. And the current Array(), Integer(), etc. methods really just
help you’re case, since they set the precedent. They just happen to
work slightly different than the normal #new counterparts. For even if
Ruby were to make it automatic, they should still be overridable, BUT
in that case they could take on a special existance as a
“constant-method”, rather than a method of Kernel, which would be more
robust.

T.

#16

On 7/8/06, Jeremy H. [email protected] wrote:

On 2006-07-08, Sean O’Halpin [email protected] wrote:

… I do think it would be nice if Klass() were a synonym for
Klass.new(). As far as I know, this wouldn’t conflict with anything
in the Ruby standard lib …

Yes it would:

You left out the qualification I made - “(apart from Array(), String()
and maybe some others which I forget)”. It might have been more
gentlemanly to expand on the “maybe some others” than to make me
appear to have made an incorrect assertion by selectively quoting from
what I said.

Sean

#17

On 2006-07-08, Sean O’Halpin [email protected] wrote:

String() and maybe some others which I forget)". It might have been
more gentlemanly to expand on the “maybe some others” than to make
me appear to have made an incorrect assertion by selectively quoting
from what I said.

Sorry about that. I was just trying to be concise. The point I was
making (which Daniel DeLorme also makes elsewhere in the thread) is
that the convention already exists that Klass(x) means “coerce x to an
instance of Klass”, rather than “call Klass.new()”. As least it does
for many values of Klass, so to make all instances of Klass() synonyms
for Klass.new() would be seriously incompatible. I’m sure there’s no
chance of it happening in Ruby 1 . I don’t know if anyone’s suggested
making Ruby 2 more consistent about this.

Regards,

Jeremy H.

#18

On 2006-07-08, [email protected] [email protected] wrote:

is the case with some of those built in.
Maybe, but how would it work? On what criterion would you override?
You’d want all calls to Klass() with a single argument to be
interpreted as coercion, since one might in principle want to coerce
any object to a <#Klass>. So what do you do when it’s natural to call
Klass.new with one argument? Maybe you could work around it, but I’d
be worried you’d be making a messy situation even worse.

I don’t object to you doing this with your own classes, I just don’t
see a good way of extending this convention to all Ruby classes, at
least not without breaking compatibility enough to rule it out for
Ruby 1.x .

Regards,

Jeremy H.

#19

On 7/9/06, Jeremy H. [email protected] wrote:

they could not be overriden with a variation of functionality – as
see a good way of extending this convention to all Ruby classes, at
least not without breaking compatibility enough to rule it out for
Ruby 1.x .

Regards,

Jeremy H.

There’s no need to introduce complicated rules for this. Just have
Klass() be a synonym for Klass.new() except for the built-in Kernel
methods. Even those could do with some rationalisation.

There are exactly four such methods in Kernel: String(), Integer(),
Float() and Array().

String(), Integer() and Float() coerce their arguments using to_s,
to_i and to_f respectively.

Array() is slightly more complicated trying to_ary, then to_a then
creating a single element array from the arg if the first two fail.

String.new accepts only strings. Integer and Float have no
corresponding new() method (as you yourself pointed out).

I see no reason why String.new couldn’t use to_s on its args and why
there couldn’t be Integer.new and Float.new with the same
functionality as Integer() and Float().

That only leaves Array.new, which to my mind is not the most intuitive
of methods anyway.
I would argue that it’s a source of confusion that Array() and
Array.new behave so differently. However, changing this would break a
lot of code so it’s probably best left alone.

I seriously doubt whether having Klass() = Klass.new() would break
much code. I think most people would be surprised to find out you can
even define a method with the same name as a class (I was).

With the scheme I’ve laid out, the only exception would be Array which
is already somewhat out on its own.

However, as you said, I can do this myself if I want to. I do and I
find it very convenient.

Regards,
Sean

#20

Jeremy H. wrote:

Sorry about that. I was just trying to be concise. The point I was
making (which Daniel DeLorme also makes elsewhere in the thread) is
that the convention already exists that Klass(x) means “coerce x to an
instance of Klass”, rather than “call Klass.new()”. As least it does
for many values of Klass, so to make all instances of Klass() synonyms
for Klass.new() would be seriously incompatible. I’m sure there’s no
chance of it happening in Ruby 1 . I don’t know if anyone’s suggested
making Ruby 2 more consistent about this.

Not so. Just becaue they would default to Klass.new does not mean they
could not be overriden with a variation of functionality – as is the
case with some of those built in.

T.