Final by default?

[deadalnix]

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.