There is no such thing as a global method in Ruby
zverok.space
zverok.space
If the default object Kernel is always the same, then isn't it a global read variable? You can overwrite it, but it's globally accessible.
Also, the only true 'global' variables, are ones that you can access via Internet Protocol, everything you do in ruby, if you are not doing inter process communication, is going to be englobed by the process object.
Even if you write a variable to a file, it's still not 'global', it's encapsulated by the (physical) server object.
By reading or writing to a server through TCP to an open port public IP, the variable is then encapsulated only by the Earth object, so it's then and only then truly 'global'
class Foo
def puts(*)
Kernel.send(:puts, "Not what you expected")
end
def initialize
puts "hello"
end
end
Foo.new #=> prints "Not what you expected"
That looks like variable shadowing? "global" doesn't mean "can't be shadowed".
> The point the article makes is that the “default object” (self) is not always the same.
I don't understand this sentence. Of course self isn't always the same. What does [“default object” (self)] mean?
I don't think you and semiquaver are using the term "default object" the same way TZubiri was.
Either way, the ability to override doesn't mean the original value wasn't there. That original value was accessible from anywhere, and that sounds like it's pretty "global".
Since `self.class == Foo` at line 7, we must check that `self.class` (which is Foo) either defines an instance method `:puts`, or that some Module included in its ancestor list can `respond_to?(:puts)`:
Foo.ancestors.map { |a| [a, a.is_a?(Class) ? a.instance_methods.include?(:puts) : a.respond_to?(:puts)] }
=> [[Foo, true], [Object, false], [Kernel, true], [BasicObject, false]]
Foo.instance_method(:puts).source_location
=> ["(irb)", 2] # line 2 of semiquaver's example
class Bar
def initialize
puts "hello"
end
end
Bar.instance_method(:puts).source_location
=> nil
Bar.ancestors.map { |a| [a, a.is_a?(Class) ? a.instance_methods.include?(:puts) : a.respond_to?(:puts)] }
=> [[Bar, false], [Object, false], [Kernel, true], [BasicObject, false]]
module Kernel
alias_method :orig_puts, :puts
def puts(*args)
orig_puts "Receiver #{self.inspect}"
orig_puts(*args)
end
end
Bar.new
Receiver #<Bar:0x000000012006eae8>
hello
=> #<Bar:0x000000012006eae8>
Hence, there are no globals - every method is invoked on some `self`, explicit or implicit, and method lookup goes up the ancestor chain until you bottom out at Kernel or BasicObject. Note that Kernel is itself an Object.
This is still an oversimplification. I recommend reading Metaprogramming Ruby and playing around in a REPL after reading the docs on Object, Class, Module, and BasicObject.
In particular, the first post in this comment chain was talking about Kernel being the same from anywhere (unless overridden).
I would personally call any method that Kernel responds to a "global" method. Likewise for anything on BasicObject. I'm not worried about the receiver, I'm worried about access to the method.
But it's not really "global," because it's not actually accessible "everywhere," and so it's a poor choice of terminology. From the BasicObject docs [0]:
BasicObject does not include Kernel (for methods like puts)
class Quux < BasicObject
def initialize
puts "hello"
end
end
Quux.new # NoMethodError (undefined method `puts' for #<Quux:0x0000000134989768>)
Though maybe you could argue that methods on `BasicObject` are "global" in a way.
For example if running on an embedded system without a Kernel.
The fact that the kernel is globally accessible to all objects is not a criticism of the language, you can't make up purity where it doesn't exist, as much as we may desire our programs are not ethereal math incantations that exist on Plato's world of ideals, and sometimes they depend on the Kernel which is the same for the whole process, (Duh).
I didn't even get into CPU defined functions like addition, and assignment. How would you argue that + is not a global function? If you want to argue that it can be overloaded, recall that we speak of the default function in a read only capacity.
Kind of, but a) not all questions of semantics make for interesting philosophy, and b) the semantics in this case absolutely map to meaningful concerns regarding performance, behavior, and debugability/tactics for inspection of runtime environments. The fact that ruby doesn't have the concept of a function without a parent object whose method table is referenced by the caller complicates (for instance) passing around functions as values as well as whether or not you can expect the same function to even behave the same way when calling it twice.
Of course, much of this is hidden by syntax, and it certainly doesn't restrict you from acting as if it has proper functions rather than just methods, but it absolutely does matter if you want to understand how your code is running, particularly details like memory usage and garbage collection and whether or not ruby can inline code (spoiler: it generally can't).
“Default” implies that it is implicitly the case if no alternative is explicitly selected, but such alternatives exist. In Ruby “everything is an object” (or, at least, “every callable method is in a class and can only be called in context of an object”) is more immutable truth than default.
> and that `Object` is the unstated parent for anything not specified
Actually, an anonymous top-level instance of Object is the default object to which things apply; Object itself is an Object (and more specifically a Class), but it is not the default object, it is the class of the default object.
Take linux "everything is a file", yes, your word document and your sound device are files, also how do you increase the volume of your speakers, er.... it's a file and you can write to it!
The usefulness of a system lies in the stances it takes, it takes guts to be opinionated. It's easier to create a system of stem cells that can be anything and can be configured to your needs, all you need to do is write a turing complete configuration file.
However one isn't inherently less abstract than the other.
For example, while objects may have 'structure and type'. They don't have an inherent byte representation, so one could argue they are even more abstract.
The mixer is a separate device.
> it's a file and you can write to it!
Which means you don't need any special software or tooling to use it. So you can automate actions with it using scripts in ways that any other desktop system won't do for you nearly as easily.
> all you need to do is write a turing complete configuration file.
Welcome to "general purpose" computing. Go back 50 years and see what the alternatives were. Or check out Plan 9 to see the file concept taken to a much better conclusion.
This may seem like something all languages require but the way it works for me in Ruby is much different than when I am writing JS or Python. It's kind of hard to explain.