[HN Gopher] There is no such thing as a global method in Ruby
___________________________________________________________________
There is no such thing as a global method in Ruby
Author : mpweiher
Score : 111 points
Date : 2024-10-28 05:11 UTC (3 days ago)
(HTM) web link (zverok.space)
(TXT) w3m dump (zverok.space)
| uticus wrote:
| Easier to understand if you come from Smalltalk
| nesarkvechnep wrote:
| Who does these days?
| PittleyDunkin wrote:
| I've been teaching a teenager how to code with smalltalk
| (Scratch): https://scratch.mit.edu/
| mostlysimilar wrote:
| The people who are going to save us when all the newer
| generations know how to do is describe their desired outcome
| to a machine and get slop output.
| PittleyDunkin wrote:
| I can't say smalltalk is popular even among this crowd.
| ElevenLathe wrote:
| I dabble in SmallTalk for hobby stuff, and it actually seems
| to be the other way around these days: People find SmallTalk
| after becoming enamored with Ruby. That's definitely my
| story.
| jonhohle wrote:
| Similar. I found small talk from Objective-C and Ruby.
| codr7 wrote:
| It's how I found SmallTalk back in the original pickaxe
| days, and Lisp, and Perl. Pretty serious expansion of
| consciousness compared to Basic, Pascal & C++.
| KerrAvon wrote:
| or Objective-C, the Objective portion of which is also derived
| from SmallTalk
| PittleyDunkin wrote:
| While I understand that objective-c has clear heritage from
| smalltalk, this comparison always struck me as farcical.
| Objective-C yields very few of the benefits of a proper
| Smalltalk VM outside of message passing, and i suppose some
| of the syntax. Meanwhile the burden of having to deal with C
| is absolutely staggering in comparison to the benefits.
| jonhohle wrote:
| The obvious benefit of C is speed and resource utilization.
| This was especially true on the late 80s.
| PittleyDunkin wrote:
| Oh, absolutely--this wasn't meant as a value judgement.
| I've written my fair share of objective-c for this very
| reason (well, that and wanting to write native GUIs ages
| ago). I'm just saying the parallels between it and
| smalltalk are highly exaggerated.
| cortesoft wrote:
| I think anyone who uses Ruby regularly knows that `everything is
| an object` is the default, and that `Object` is the unstated
| parent for anything not specified. The rest falls from that.
| dragonwriter wrote:
| > I think anyone who uses Ruby regularly knows that `everything
| is an object` is the defaul
|
| "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.
| TZubiri wrote:
| I hate those kinds of abstractions, ends up becoming as useless
| as it is all-encompassing.
|
| 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.
| KerrAvon wrote:
| I don't think it's quite the same thing as "everything is a
| file". Unix files are typeless byte streams. Ruby objects
| have actual structure and type, and being able to do, for
| example, `49.times {print "this is a time!"}` because
| integers are objects doesn't add any friction to your life.
| TZubiri wrote:
| Objects and files are different, yes.
|
| 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.
| akira2501 wrote:
| > also how do you increase the volume of your speakers
|
| 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.
| Alifatisk wrote:
| Man I love this blog series
| TZubiri wrote:
| This feels like a philosophical question at this point.
|
| 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'
| weatherlight wrote:
| its a take for sure, but it feels like it goes a bit off-topic.
| The OP article is about the idea that Ruby doesn't really have
| global methods since methods in Kernel are scoped within each
| object. Arguing that only network-accessible variables are
| truly global posits more philosophical than practical, thus
| lacking utility for this context. Especially when some langs do
| indeed, in fact have global methods/state that's accessible
| from anywhere.
| semiquaver wrote:
| Not at all. Consider the following: 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"
|
| The point the article makes is that the "default object" (self)
| is _not_ always the same.
| Dylan16807 wrote:
| > Consider the following:
|
| 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?
| int_19h wrote:
| It means that the default object (the one that receives the
| method call in the absence of a receiver) is not a global.
| layer8 wrote:
| I don't really know Ruby, but I imagine that if a subclass
| overrides _puts_ , then code in the base class calling _puts_
| will invoke that override instead of invoking the pseudo-global
| Kernel version. In other languages, the method definition in
| the subclass would be irrelevant, calling the global function
| wouldn't cause polymorphic method dispatch on the current
| object.
| Lammy wrote:
| Ruby has Refinements for a less-global way of doing this
| https://docs.ruby-
| lang.org/en/master/syntax/refinements_rdoc...
| PittleyDunkin wrote:
| > This feels like a philosophical question at this point.
|
| 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).
| 0x457 wrote:
| I think example about `avatar_url` shows that it isn't a
| philosophical question.
| kubectl_h wrote:
| I think most experienced Ruby engs tend to think of code as
| existing within a runtime which is one global space with many
| nested (and parallel) execution states and rationalizing what's
| happening in static code means simulating that runtime in your
| head and navigating around it up, down and sideways.
|
| 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.
| frou_dh wrote:
| I think it's because which files code resides in doesn't
| ultimately have much bearing on the modularity, unlike in
| Python and JS (ESM).
___________________________________________________________________
(page generated 2024-10-31 23:00 UTC)