3 ms·
Author could use a little more memoization in his example, but I suspect that breaks some of the simplicity of his argument. If shape Area is computed often en
by e28eta 4y ago
Author could use a little more memoization in his example, but I suspect that breaks some of the simplicity of his argument.
If shape Area is computed often enough that you care about inlining the calculation, why not compute & store it every time the height / width change. That’d be easy enough in an architecture based on information hiding, and might illustrate a legitimate engineering trade-off between those architectural choices.
- cratermoon 4y agoRight? His Area() function does the calculation from the scratch every call. Either a) make the Shape immutable and calculate area once, at create time, or have the mutator functions recompute the area when they are called. At that point Area() just returns an f32, and the compiler can do all kinds of optimizations.
- cratermoon 4y agoSpeaking of mutators, his example depends the code executing in a single thread. What happens if calls to mutate the shape and calls to calculate the area are interleaved?
- incrudible 4y agoYou are completely changing the problem. Remember, this is an example, the code does the same thing in either implementation.
- cratermoon 4y ago> completely changing the problem Indeed. That's the point. Why let someone with an axe to grind define the problem in a way they can solve with their axe? The author is using optimization as the frame for rejecting a particular way of working, I'm pointing out that the definition is set up to make the solution work. I don't concede the terms of the debate before it even begins.