I find it odd that getters and setters are implemented in Ruby … manually. attr_accessor is the idiomatic way to do it (or attr_reader / attr_writer if you want more granular control).
There’s no change in interface needed in the ruby example if you decide that you want to replace that with fully-written getter/setter methods like the post shows; attr_accessor generates exactly those same signatures for you.
>>> class Foo:
... @property
... def bar(self):
... return "hello from a property"
... @bar.setter
... def bar(self, value):
... print(f"tried to replace bar with {value}")
>>> Foo().bar
'hello from a property'
>>> Foo().bar = "asdf"
tried to replace bar with asdf @foo
def bar():
...
def bar():
...
bar = foo(bar)No that’s instance variables.
> Which part do you find ugly?
In Ruby to modify a method you just call a method. I guess I think a second, redundant, way to call methods is not elegant.
This is because there’s not a good way to pass two delayed computations - two blocks. Looping constructs were replaced by method variants.
> also blocks are not objects for some reason
Yeah they’re reifiable but not sure why not reified by default.
I don't know that much about Ruby's implementation but I think both the if else and blocks not being objects are that way to prevent Ruby from being even slower. My understanding is if you turn a block into a proc it gets a lot slower.
To migrate an API - that's what I said.