On Saturday, 15 March 2014 at 08:32:32 UTC, Paulo Pinto wrote:
Am 15.03.2014 06:29, schrieb deadalnix:
On Saturday, 15 March 2014 at 04:03:20 UTC, Manu wrote:
That said, function inlining is perhaps the single most
important API
level
performance detail, and especially true in OO code (which
advocates
accessors/properties).
OOP say ask, don't tell. Accessors, especially getters, are
very anti
OOP. The haskell of OOP would prevent you from returning
anything from a
function.
What?!?
Looking at Smalltalk, SELF, CLOS and Eiffel I fail to see what
you mean, given that they are the grand daddies of OOP and all
have getters/properties.
And LISP is grand daddy of functional, and do not have most of
the features of modern functional languages.
OOP is about asking the object to do something, not getting infos
from an object and acting depending on that. In pseudo code,
you'd prefers
object.DoTheJob()
to
auto infos = object.getInfos();
doTheJob(infos);
If you push that principle to the extreme, you must not return
anything. Obviously, most principle pushed to the extreme often
become impractical, btu here you go.
Now, what about a processing that would give me back a result ?
Like the following:
auto f = new File("file");
writeln(f.getContent());
Sound cool, right ? But you are telling not asking. You could do:
interface FileProcessor {
void processContent(string);
}
class WritelnFileProcessor : FileProcessor {
void processContent(string s) { writeln(s); }
}
auto f = new File("file");
f.process(new WritelnFileProcessor());
This has several advantages that I don't have much time to expose
in detail. For instance, the FileContentProcessor could have more
methods, so it can express a richer interface that what could be
returned. If some checks need to be done (for security reasons
for instance) you can ensure withing the File class that they are
done properly. It makes things easier to test. You can completely
change the way the file class works internally without disturbing
any of the code that use it, etc ...
However, this is clear that it come at a cost. I don't doubt an
OO language pushing this to the extreme would see concept that
confuse everybody emerging, pretty much like monads confuse the
hell out of everybody in functional languages.
