Free functions versus member functions

[Kris]

Yes, that perspective resonates, though I tend to use the term 'client 
functions' to describe what Scott is calling non-member functions.

There's some specific interest here with regard to D:

1) the Widget factory example is less clear in D, due to that lack of an 
equivalent 'namespace' mechanism. This is why such methods tend to reside 
inside the respective class/struct in D. Yes, one could perhaps use "import 
as" instead, but that would tend to muddy usage further. I think this 
indicates a minor annoyance with the D namespace mechanism. One that's 
bothered me from time to time <g>

2) the section on "syntax issues" is something that D, on the other hand, is 
fairly adept at: the support for "flip that outside left-hand reference into 
the first argument instead", which people got excited about regarding 
arrays, does help to maintain syntactic symmetry. That's assuming you can 
avoid namespace collisions in the process. As I understand it, some of the 
changes in D v2 are intended to address that latter concern?

The interesting thing overall is this: what Scott describes has minimal 
bearing on the concerns within Tango, since we've mostly been attuned to the 
client/member issue from the beginning. Where we do currently deviate, it is 
due to concerns over #1 above.

Having said that, and assuming I correctly understand some of the comments 
made about Tango (over the last year), perhaps Tango just doesn't have 
sufficient 'client' functions?




"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:feju2r$1nsn$1 at digitalmars.com...
> Continuing the discussion from the thread "questions on PhanTango 
> 'merger'":
>
> Lars Ivar Igesund wrote:
> > It is not as if such functions are non-existant in Tango, so which exact
> > functionality do you think is better expressed through free standing
> > functions rather than objects? The answers of others shows that this
> > usually is wanted for objects where you often need only one operation on
> > the given object, even if others are available. This don't remove the
> fact
> > that an object (class) equally often is a useful abstraction, and
> when that
> > is established, free standing functions usually should be implemented as
> > wrappers around each method on the object, rather than the object being
> > implemented via free standing functions. This is why Tango looks as
> it does
> > today; we have avoided wrappers of our own code if possible, because 
> > they
> > degrade orthogonality of the API, and add more code to maintain.
> Whether we
> > have been to strict in enforcing that stance, is an open question.
>
> I've been stumped by this design issue before. Should functionality be 
> done as a set of free functions, or as member functions? I remember going 
> over this with Matthew Wilson, and he resolved it by implementing two 
> parallel sets of interfaces: one free, the other member. I thought that 
> doing both was a copout, but couldn't figure out which one was right.
>
> I eventually ran across this article by Scott Meyers 
> http://www.ddj.com/cpp/184401197
> which made a lot of sense. It gives some good guidelines to use to make 
> such decisions, and backs it up with reasoning that I find compelling.
>
> Isn't it funny how we've completed the circle? We went from all free 
> functions in C, to all member functions in C++, and now back to free 
> functions? <g>