History

i am against that, what about methods that are defined in Kernel, but you want when you are inside an BasicObject?
you need something like:
Kernel::Array([])
or
Kernel.Array([])
what does make more sense for you?

i am against that, what about methods that are defined in Kernel, but you want when you are inside an BasicObject?
you need something like:
Kernel::Array([])
or
Kernel.Array([])
what does make more sense for you?

You need :: before Kernel, unless you define const_get
::Kernel::Array(3)
And in that case I much prefer
::Kernel.Array(3)
even if it does not look as nice because at least is is clear :: is constant resolution.

This is a weird case due to the upper case first letter, what do you think about:
::Kernel::puts "Hello"
versus
::Kernel.puts "Hello"

i am against that, what about methods that are defined in Kernel, but you want when you are inside an BasicObject?
you need something like:
Kernel::Array([])
or
Kernel.Array([])
what does make more sense for you?

I actually prefer the '::Kernel.Array' example here (although I can see both sides of the argument), just because it makes it perfectly obvious that 'Array' is actually a method call and not something else.

On Wednesday, 8 May 2013 at 6:03 AM, Eregon (Benoit Daloze) wrote:

This is a weird case due to the upper case first letter, what do you think about:
::Kernel::puts "Hello"
versus
::Kernel.puts "Hello"

However I know that's not the case; and in fact (({::})) means different things if the right-hand parameter thingy is a constant or function. I.e. (({obj.foo})) ~ (({obj::foo()})) ~ (({obj::foo})), but (({obj.FOO})) ~ (({obj::FOO()})) ≁ (({obj::FOO})), irrespective of ((|obj|)) being a Class or not.

The whole thing would be made much more clear if (({::FOO()})) and (({::foo})) were removed, and (({::})) was always only used to resolve constants.

I'm in favour of deprecating :: for method calls as well. I'm all for
"multiple roads to Rome" but when it comes to the method calling syntax
I really want it to be consistent.

Actually getting rid of the operator is going to be interesting though
since I believe it's used in various places of MRI's core/std library as
well as third-party projects. This is probably something that shouldn't
be removed until at least 2.2.

Apart from having no advantages over ".", "::" for method calls is very rarely used even anyways. It has been effectively deprecated by the Ruby community and it now has to be deprecated by Ruby itself :-)

When I learned about Nokogiri, I had no idea how this was supposed to work: Nokogiri::XML('')
Simply changing the code to use a '.' instead of '::' makes it clear, that we're sending the '.XML' message.
So why not encourage people to write code that is easier to read?!

When I learned about Nokogiri, I had no idea how this was supposed to work: Nokogiri::XML('')
Simply changing the code to use a '.' instead of '::' makes it clear, that we're sending the '.XML' message.
So why not encourage people to write code that is easier to read?!

But '.' and '::' mean different things.
'::' means you are calling the method that is defined inside the Nokogiri module/namespace. Changing it to use a dot means that you are sending a message to the object Nokogiri.

Although in PHP you can also abuse the :: for both static and non
static method calls it's actually not used for namespaces (unlike Ruby),
instead it uses backslashes for that. Although this means that there's
still two ways to call a method (syntax wise) you at least don't end up
using a syntax feature meant for something completely unrelated to
method calls.

PHP is also a terrible language so I don't think it's worth comparing to
at all.

But '.' and '::' mean different things.
'::' means you are calling the method that is defined inside the Nokogiri module/namespace. Changing it to use a dot means that you are sending a message to the object Nokogiri.

This isn't correct. Nokogiri.XML() and Nokogiri::XML() are equivalent.

=begin
I'm not sure how I feel about this. I understand the potential for confusion, but at the same time there's a certain congruity of being able to inherit from classes or methods that create classes in the same way. For example:

If we remove the ability to call methods with (({::})), then the class definition lines don't match as nicely:

class Baz < Foo::Bar
...
class Quux < Foo.Bar("Howdy")
...

Though I'd be interested to hear Mr. Evans opinion, since I think Sequel is where I've seen this used to the greatest effect...

I'm against removing it, since I think there are places where the syntax looks nicer with :: (constructors such as Sequel::Model() and Nokogiri::XML()). Having only one way to do something for its own sake is not the ruby way, and I think the loss of backwards compatibility and nicer syntax outweighs the reduced confusion. I don't train new ruby programmers, though, so maybe I underestimate the confusion this causes.

If we remove the ability to call methods with (({::})), then the class
definition lines don't match as nicely:

class Baz < Foo::Bar
...
class Quux < Foo.Bar("Howdy")
...

Though I'd be interested to hear Mr. Evans opinion, since I think Sequel
is where I've seen this used to the greatest effect...

I'm against removing it, since I think there are places where the syntax
looks nicer with :: (constructors such as Sequel::Model() and
Nokogiri::XML()). Having only one way to do something for its own sake is
not the ruby way, and I think the loss of backwards compatibility and nicer
syntax outweighs the reduced confusion. I don't train new ruby
programmers, though, so maybe I underestimate the confusion this causes.

I'm against removing it, since I think there are places where the syntax
looks nicer with :: (constructors such as Sequel::Model() and
Nokogiri::XML()). Having only one way to do something for its own sake is
not the ruby way, and I think the loss of backwards compatibility and nicer
syntax outweighs the reduced confusion. I don't train new ruby
programmers, though, so maybe I underestimate the confusion this causes.

Can't you use use #[] for this?

class Quuz < Foo::Bar["Howdy"]
end

class User < Sequel::Model[:User]
end

doc = Nokogiri::XML[data]

In the case of Sequel::Model, no, since Sequel::Model.[] is already
defined and does something different than creating a subclass.

Usage of [] for constructors seems fairly uncommon (Hash.[] is the
exception that comes to mind), so from a syntax level it is more likely
to be confusing. Using capitalized methods for constructors is much
more common in ruby (e.g. Kernel::{String,Array,Integer,Float,...}).