On Fri, Oct 17, 2008 at 8:31 AM, Bill Baxter <wbaxter@gmail.com> wrote:

> The reason is this:  these days it's en vogue to make classes contain as few functions as necessary, and to write everything else as non-member functions.

OT: is it?  What's this "model" called?  "Oh, C was right after all"?  ;)

What are the supposed advantages of developing like this?

Jarrett Billingsley wrote:
> On Fri, Oct 17, 2008 at 8:31 AM, Bill Baxter <wbaxter@gmail.com> wrote:
> 
>> The reason is this:  these days it's en vogue to make classes contain
>> as few functions as necessary, and to write everything else as
>> non-member functions.
> 
> OT: is it?  What's this "model" called?  "Oh, C was right after all"?  ;)
> 
> What are the supposed advantages of developing like this?

Sounds like a poor impersonation of aspect-oriented programming, maybe the idea is to make memberish functions not actually be members so that other imports can write memberish functions that are as "1st-class". Sort of ridiculous though.

 - Gregor Richards

Gregor Richards wrote:
> Jarrett Billingsley wrote:
>> On Fri, Oct 17, 2008 at 8:31 AM, Bill Baxter <wbaxter@gmail.com> wrote:
>>
>>> The reason is this:  these days it's en vogue to make classes contain
>>> as few functions as necessary, and to write everything else as
>>> non-member functions.
>>
>> OT: is it?  What's this "model" called?  "Oh, C was right after all"?  ;)
>>
>> What are the supposed advantages of developing like this?
> 
> Sounds like a poor impersonation of aspect-oriented programming, maybe the idea is to make memberish functions not actually be members so that other imports can write memberish functions that are as "1st-class". Sort of ridiculous though.
> 
>  - Gregor Richards

No. The goal is to provide better encapsulation.
There's a paper by Scott Meyers about it.

Don wrote:
> Gregor Richards wrote:
>> Jarrett Billingsley wrote:
>>> On Fri, Oct 17, 2008 at 8:31 AM, Bill Baxter <wbaxter@gmail.com> wrote:
>>>
>>>> The reason is this:  these days it's en vogue to make classes contain
>>>> as few functions as necessary, and to write everything else as
>>>> non-member functions.
>>>
>>> OT: is it?  What's this "model" called?  "Oh, C was right after all"?  ;)
>>>
>>> What are the supposed advantages of developing like this?
>>
>> Sounds like a poor impersonation of aspect-oriented programming, maybe the idea is to make memberish functions not actually be members so that other imports can write memberish functions that are as "1st-class". Sort of ridiculous though.
>>
>>  - Gregor Richards
> 
> No. The goal is to provide better encapsulation.
> There's a paper by Scott Meyers about it.

A great one:

http://www.drdobbs.com/cpp/184401197

This goes straight to the discussion I was trying to avoid the other day. People still have dogmatic views of OO...


Andrei

Andrei Alexandrescu:
> Don wrote:
> > No. The goal is to provide better encapsulation.
> > There's a paper by Scott Meyers about it.
>
> A great one:
> http://www.drdobbs.com/cpp/184401197
> This goes straight to the discussion I was trying to avoid the other
> day. People still have dogmatic views of OO...

Very nice article, written to the point. I did read it a lot of time ago, but now I have understood it.

D has modules, so they can be used to contain the free functions related to a class.

This page is less clear for me, but I presume in D there are ways to tell what T is: http://www.drdobbs.com/showArticle.jhtml?documentID=cuj0002meyers&pgno=2


>Such interfaces allow class clients to do anything they might reasonably want to do, but classes contain no more member functions than are absolutely necessary.<

There are no absolutes. You can perform some operation on a class both using those core member functions, or accessing fields more directly. Sometimes it happens that doing it using only the core member functions gives a slower code. Adding some non minimal methods may speed up your code. The author says the same thing few lines below:

>Of course, a minimal class interface is not necessarily the best interface. I remarked in Effective C++ that adding functions beyond those truly necessary may be justifiable if it significantly improves the performance of the class, makes the class easier to use, or prevents likely client errors<


Problems:
1) The asymmetry in the calling way between those free functions and the methods increases the complexity of the class, because for each function or method the programmer (or the IDE) has to remember an extra bit, that tells if it's a member or not. Free functions "happen" as the article says, but that's extra complexity that you are willing to pay if you want to add some exotic functionality; while you aren't ready to pay such price even if you want to use the class in a standard way (as it often happens if its API is well designed).
2) If you create a derived class it can't re-define some of those methods, because some of them are free functions, not virtual methods. In a dynamic language this isn't a problem, but in static brittle language this may give problems. I am not sure.

Bye,
bearophile

On Fri, Oct 17, 2008 at 11:47 PM, Don <nospam@nospam.com.au> wrote:
> Gregor Richards wrote:
>>
>> Jarrett Billingsley wrote:
>>>
>>> On Fri, Oct 17, 2008 at 8:31 AM, Bill Baxter <wbaxter@gmail.com> wrote:
>>>
>>>> The reason is this:  these days it's en vogue to make classes contain as few functions as necessary, and to write everything else as non-member functions.
>>>
>>> OT: is it?  What's this "model" called?  "Oh, C was right after all"?  ;)
>>>
>>> What are the supposed advantages of developing like this?
>>
>> Sounds like a poor impersonation of aspect-oriented programming, maybe the idea is to make memberish functions not actually be members so that other imports can write memberish functions that are as "1st-class". Sort of ridiculous though.
>>
>>  - Gregor Richards
>
> No. The goal is to provide better encapsulation.
> There's a paper by Scott Meyers about it.
>

Yeh, that's the one I was thinking of.  Just couldn't remember who wrote it.

--bb