3 ms·
Excuse me for stating the obvious, but methods are not constants. They're functions inside classes. Thus they could theoretically return different results when
by laumars 11y ago
Excuse me for stating the obvious, but methods are not constants. They're functions inside classes. Thus they could theoretically return different results when called with the same arguments, even when called sequentially. For example, the methods could return a randomized number; or return an array with values added or removed from the stack; or uses logic based on the system clock.
It would be difficult for a compiler to reliably tell whenever a method behaves like a constant without adding to the compilation time - and that simply isn't an option for JIT runtimes nor Go. And given it's a pretty basic optimisation for humans to pick up, I reckon it's also pretty low down on the list of "must have" features for compiler optimisations.
- JoeAltmaier 11y agoSome languages have const methods. Exactly so the compiler can automatically optimize things like this (calling Itoa several times on the same value).
- masklinn 11y agoThe question is not about the result of the function it's about the function itself, aka if you have X.Y.Z.get("Q") X.Y.Z.get("R") does the runtime resolve the X.Y.Z.get chain once or twice.
- laumars 11y agoI don't know and wouldn't like to guess. But that's just namespacing anyway, so I doubt it's going to carry that much overhead. In any case, that's not what the article was discussing and not what the majority of the comments on HN were discussing either.
- laumars 11y agoSorry, I'm suffering from manflu at the moment so my brain isn't running at full capacity; which means someone will have to explicitly spell out why my comment was downvoted. I'm assuming I've errored somewhere - in which case I'd welcome the opportunity to learn something :)