4 ms·
I agree with this. I don't see why new syntax (which looks kinda confusing, IMO) should be added to solve a problem which can be solved with a method. A naive-2
by spoiler 11y ago
I agree with this. I don't see why new syntax (which looks kinda confusing, IMO) should be added to solve a problem which can be solved with a method. A naive-2-minute implementation:
module Chainable
def chain(*kl)
k = kl.shift
if self.respond_to?(k)
v = self.public_send(k)
else
v = nil
end
return v if kl.empty?
unless v.respond_to? :chain
raise ArgumentError, "can't chain on `#{k.inspect} => #{v.inspect}:#{v.class}`"
end
return v.chain(*kl)
end
end
and then this:
class Object
include Chainable
end
- vidarh 11y agoBecause the proposed version can be made a lot faster, even before considering that your version doesn't handle method arguments
- forgotpwtomain 11y ago> Because the proposed version can be made a lot faster It being faster has nothing to do with the syntactical appearance of the operator. I think it's more pertinent to ask why does .chain_try or .tries or .fetches need a special operator than whether it's a convenient addition.
- vidarh 11y agoIt doesn't need a special operator for other reason than that by specifying the VM-level behaviour it can be made a lot more efficient. And at that point naming it after something that are legal method names would be problematic.
- spoiler 11y agoIt would be trivially easy to support arguments, though. What comes to mind is to send a Hash or Array after a method (represented by a Symbol) that expects/accepts an argument: o.chain :foo, [1, 2, 3], :bar, :baz, {key: 'value'} Here `foo` and `baz` accept arguments, but `bar` does not. Also, it shouldn't make any significant performance difference whether this was implemented as a syntactic sugar, an operator or a method (this doesn't mean it won't perform better than my example method).
- vidarh 11y agoAt this point it's getting complex enough that it defeats the purpose. There are ways of "fixing" that (e.g. by wrapping return values and overriding method_missing or similar instead), but most of the ones I can thing of that would look nice would perform worse than yours. > Also, it shouldn't make any significant performance difference whether this was implemented as a syntactic sugar, an operator or a method (this doesn't mean it won't perform better than my example method). It potentially would make a massive difference. Firstly there's a minimum of 5 method calls just in the success-path in your example, plus at least one object creation (constructing a new argument array in the final call), but potentially more. And that's not nearly all. Method calls in MRI are expensive, even with caching. Compare that to implementing the vm-level logic which can do the actual method calls and a nil check and branch.
- spoiler 11y agoSorry for the late reply. I still don't understand why special syntax is needed for it, though. As far as I understood your arguments, they keep pointing out flaws in my implementation (which is far from optimised). You could mimic its behaviour through C. Could you elaborate more clearly, if I'm misunderstanding something (I do want to understand).
- deleted 11y ago[deleted]