www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Required Reading: "How Non-Member Functions Improve Encapsulation"

reply Walter Bright <newshound2 digitalmars.com> writes:
for core D devs.

"How Non-Member Functions Improve Encapsulation" by Scott Meyers

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

Note that I'm as guilty as anyone for not understanding or following these 
guidelines. I expect we can do much better.
Oct 25 2017
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2017 11:19 PM, Walter Bright wrote:

 for core D devs.
 
 "How Non-Member Functions Improve Encapsulation" by Scott Meyers
 
 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 
 
 
 Note that I'm as guilty as anyone for not understanding or following 
 these guidelines. I expect we can do much better.


UFCS kills off a good part of those arguments, but point still stands.

```D
struct Point {
	private int[2] d;

	this(int x, int y) {
		d[0] = x;
		d[1] = y;
	}
	
	 property {
		ref int x() { return d[0]; }
		ref int y() { return d[1]; }
	}
}

void main() {
	Point p = Point(1, 3);
	p.y = 2;
}
```


Hehe ;)
Oct 25 2017
prev sibling next sibling parent reply who cares <wsffws 12345678.cz> writes:
On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright 
wrote:

 for core D devs.

 "How Non-Member Functions Improve Encapsulation" by Scott Meyers

 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

 Note that I'm as guilty as anyone for not understanding or 
 following these guidelines. I expect we can do much better.


I tend to agree. When a member function can be written with only 
the public declarations (aka the "public API") it can be set as a 
free function. However during my youth i've written lots of huge 
classes...now that i don't write much anymore it's too late to 
apply the rule :/
Oct 25 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-10-26 08:56, who cares wrote:


 I tend to agree. When a member function can be written with only the 
 public declarations (aka the "public API") it can be set as a free 
 function. However during my youth i've written lots of huge 
 classes...now that i don't write much anymore it's too late to apply the 
 rule :/


In D, protection attributes applies to the module. So if the free 
functions are defined in the same module, it's easy to accidentally 
access private data.

-- 
/Jacob Carlborg
Oct 26 2017
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright 
wrote:

 for core D devs.

 "How Non-Member Functions Improve Encapsulation" by Scott Meyers

 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197


You mean non-member functions are preferred? I encountered this 
more from performance point: especially in case of small 
structures like Point it would be more beneficial to pass them by 
value than by reference, which can be achieved by extension 
methods, but then you need to import the respective module to 
have those extension methods available. It would work more 
palatable if extension methods from the structure's module were 
available without requiring import. It may rely on static 


struct Size
{
   int width,height;
   alias add=.add; //?
}

Size add(Size s1, Size s2)
{
   return Size(s1.width+s2.width, s1.height+s2.height);
}

or just work without it. Such alias would allow to provide 
extension methods from other modules, though this would mean 
circular dependency between modules.
Oct 26 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-10-26 12:42, Kagamin wrote:


 You mean non-member functions are preferred? I encountered this more 
 from performance point: especially in case of small structures like 
 Point it would be more beneficial to pass them by value than by 
 reference, which can be achieved by extension methods, but then you need 
 to import the respective module to have those extension methods 
 available.


Adding methods to a struct will not increase its size.

-- 
/Jacob Carlborg
Oct 27 2017
parent reply Kagamin <spam here.lot> writes:
On Friday, 27 October 2017 at 07:36:45 UTC, Jacob Carlborg wrote:

 On 2017-10-26 12:42, Kagamin wrote:


 You mean non-member functions are preferred? I encountered 
 this more from performance point: especially in case of small 
 structures like Point it would be more beneficial to pass them 
 by value than by reference, which can be achieved by extension 
 methods, but then you need to import the respective module to 
 have those extension methods available.


 Adding methods to a struct will not increase its size.


Instance methods require this be passed by reference, which 
requires storage fiddling on the caller side. It's likely to 
disappear after inlining, but still.
Oct 27 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-10-27 11:06, Kagamin wrote:


 Instance methods require this be passed by reference, which requires 
 storage fiddling on the caller side. It's likely to disappear after 
 inlining, but still.


Ah, right.

-- 
/Jacob Carlborg
Oct 27 2017
parent reply w0rp <devw0rp gmail.com> writes:
I've noticed the benefits of writing non member functions in 
Python codebases. Say if you have a User model in a Django ORM, 
and you have a Thing model, and some operation on User and Thing. 
I've noticed that your code is almost always better if you write 
a non member function on User and Thing, instead of a member of 
User or Thing.

Often a function belongs to neither type. Instead the logic cuts 
across those two types. The key disadvantage I notice is ending 
up with very large and unreadable classes which poorly categorise 
business logic, when you could have been categorising functions 
in modules based on different business needs.
Oct 29 2017
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, October 29, 2017 08:45:15 w0rp via Digitalmars-d wrote:

 I've noticed the benefits of writing non member functions in
 Python codebases. Say if you have a User model in a Django ORM,
 and you have a Thing model, and some operation on User and Thing.
 I've noticed that your code is almost always better if you write
 a non member function on User and Thing, instead of a member of
 User or Thing.


Yeah, making functions generic can be a big win. The bigger question is what
to do when it doesn't really make sense to make the function generic, and it
doesn't need access to the private members of the type that it would always
be used with. In that case, it doesn't need to be a member function, but it
could be.

- Jonathan M Davis
Oct 29 2017
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/25/17 6:19 PM, Walter Bright wrote:

 for core D devs.
 
 "How Non-Member Functions Improve Encapsulation" by Scott Meyers
 
 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 
 
 
 Note that I'm as guilty as anyone for not understanding or following 
 these guidelines. I expect we can do much better.


I'm pretty sure I read that before.

However, D's lookup rules fail miserably when it comes to templates:

mod1.d:

auto callFoo(T)(T t)
{
   return t.foo;
}

mod2.d:

struct S
{
    int x;
}

int foo(S s) { return s.x * 5; }

void main()
{
    auto s = S(1);
    assert(s.foo == 5);
    assert(s.callFoo == 5); // can't compile
}

Would be nice to have a way around this. Not sure what it would look like.

Also in D, it's harder to make this help for encapsulation since the 
non-member functions would have to be in another module.

-Steve
Oct 26 2017
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 26 October 2017 at 12:19:33 UTC, Steven 
Schveighoffer wrote:

 D's lookup rules fail miserably when it comes to templates:

 mod1.d:

 auto callFoo(T)(T t)
 {
   return t.foo;
 }

 mod2.d:

 struct S
 {
    int x;
 }

 int foo(S s) { return s.x * 5; }

 void main()
 {
    auto s = S(1);
    assert(s.foo == 5);
    assert(s.callFoo == 5); // can't compile
 }

 Would be nice to have a way around this. Not sure what it would 
 look like.


Assuming you don't want to change the original struct, this can 
be worked around by making a wrapper type using alias this. I 
think that's logical because you have to be explicit about which 
foreign functions you want the imported algorithm to see. There 
would be a function hijacking problem otherwise.

What is the catch here, is that alias this won't solve cases 
where the free function takes a reference to the wrapped type or 
returns it.
Oct 27 2017
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright 
wrote:

 for core D devs.

 "How Non-Member Functions Improve Encapsulation" by Scott Meyers

 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

 Note that I'm as guilty as anyone for not understanding or 
 following these guidelines. I expect we can do much better.


As a counterpoint. I guess UFCS makes it less of a problem, but 
it's nice when using an IDE to just type foo. , press ctrl-space 
and see a nice list of methods that can be used with the class. 
When having free functions, you don't get to enjoy that :)
Oct 26 2017
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, October 26, 2017 12:53:38 JN via Digitalmars-d wrote:

 On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright

 wrote:

 for core D devs.

 "How Non-Member Functions Improve Encapsulation" by Scott Meyers

 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/1844
 01197

 Note that I'm as guilty as anyone for not understanding or
 following these guidelines. I expect we can do much better.


 As a counterpoint. I guess UFCS makes it less of a problem, but
 it's nice when using an IDE to just type foo. , press ctrl-space
 and see a nice list of methods that can be used with the class.
 When having free functions, you don't get to enjoy that :)


At a previous job, we had our own string class which wrapped std::string
just because some of the developers wanted our extra string functions on the
type where they would be easy to find (even just for documentation
purposes). They were of the opinion that once you separate the functions
from the class, your project will ultimately end up with multiple header
files of functions doing similar things, because at least some of the time,
developers wouldn't know about the existing functions and would add their
own own. And with sufficiently large projects, that does seem to happen all
too often. I still don't agree with the idea that putting stuff on the class
is better just because it makes stuff easier to find, but I can see why
someone would think that.

As has been pointed out elsewhere in this thread, the encapsulation benefits
don't exist in the same way in D unless you put the free functions in
separate modules, and then you have to import other stuff to use them,
whereas in C++, you can just put the free functions next to the type and
still get the encapsulation benefits. So, the benefit of splitting the
functions out within a module is fairly minimal in D. Rather, the main
reason I see for splitting functions out is in order to make them more
generic, and I think that the push to do that in D has a tendency to make a
lot of functions free functions that might have been member functions in
most other languages.

And in D, there's the issue that declaring a function to be used with UFCS
instead of as a member function can be a bit of a pain when the type is
templated. You have to repeat a bunch of stuff that's just part of the
templated struct or class. You end up with additional templates and template
constraints (much of which is duplicated) just to separate the functions
from the type.

That being said, the time that I'm most likely to turn a member function
into a free function when the function isn't going to be made generic is
when the type is templated simply because then I can put the unittest block
right next to the function without having it be part of the template (since
that's almost always the wrong thing to do if you don't do some boilerplate
with static ifs to make it so that they're only compiled into a single
instantiation that's intended just for testing).

Overall, I think that the idea that functions should be free functions where
reasonable is good advice, but it needs to be taken with a grain of salt.

- Jonathan M Davis
Oct 26 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/26/2017 3:05 PM, Jonathan M Davis wrote:

 As has been pointed out elsewhere in this thread, the encapsulation benefits
 don't exist in the same way in D unless you put the free functions in
 separate modules, and then you have to import other stuff to use them,
 whereas in C++, you can just put the free functions next to the type and
 still get the encapsulation benefits. So, the benefit of splitting the
 functions out within a module is fairly minimal in D. Rather, the main
 reason I see for splitting functions out is in order to make them more
 generic, and I think that the push to do that in D has a tendency to make a
 lot of functions free functions that might have been member functions in
 most other languages.


The point is that functions that do not need access to private fields should
NOT 
be part of the class. Most of the discussion here is based on the idea that 
those functions should still be semantically part of the class, even if not 
physically. That idea should be revisited. Why should they be semantically part 
of the class?


You can also do things like:

--- s.d -------
struct S { int x; ref int X() { return x; } }

--- splus.d ----
public import s;
int increment(S s) { s.X() += 1; } // note no access to S.x

--- user.d ----
import splus;
void foo(ref S s) { s.increment(); }
Oct 26 2017
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, October 26, 2017 16:29:24 Walter Bright via Digitalmars-d 
wrote:

 On 10/26/2017 3:05 PM, Jonathan M Davis wrote:

 As has been pointed out elsewhere in this thread, the encapsulation
 benefits don't exist in the same way in D unless you put the free
 functions in separate modules, and then you have to import other stuff
 to use them, whereas in C++, you can just put the free functions next
 to the type and still get the encapsulation benefits. So, the benefit
 of splitting the functions out within a module is fairly minimal in D.
 Rather, the main reason I see for splitting functions out is in order
 to make them more generic, and I think that the push to do that in D
 has a tendency to make a lot of functions free functions that might
 have been member functions in most other languages.


 The point is that functions that do not need access to private fields
 should NOT be part of the class. Most of the discussion here is based on
 the idea that those functions should still be semantically part of the
 class, even if not physically. That idea should be revisited. Why should
 they be semantically part of the class?


 You can also do things like:

 --- s.d -------
 struct S { int x; ref int X() { return x; } }

 --- splus.d ----
 public import s;
 int increment(S s) { s.X() += 1; } // note no access to S.x

 --- user.d ----
 import splus;
 void foo(ref S s) { s.increment(); }


I agree that it's a good rule of thumb to aim for member functions to be the
set of functions that require access to private members, but I've never felt
that it's useful to be pedantic about it (particularly in D, where you don't
even get encapsulation if they're in the same module). When I write a struct
or class, it's generally designed with a set of operations that conceptually
go with it, and I don't see whether they need to access to private members
as being all that relevant to that. Functions which aren't really
conceptually part of the class or struct certainly should be separate, but
for me at least, it's about the API and what it's conceptually trying to do,
and what the type is trying to be and represent - what its abstraction is.
And in some cases, separating a function from a type just because it doesn't
happen to use any private members then feels like an artificial separation.

On some level, I think that it comes down to a question of what operations
are part of the abstraction and what operations are just using the
abstraction, if it's part of the abstraction, IMHO, it just makes more sense
for it to be a member function regardless of whether it accesses private
members.

Obviously, that's subjective, and there's then disagreement at least some of
the time on what should and shouldn't be a member function, but I don't
think that it's necessarily the case that having everything that doesn't
need access to private members as free functions leads to the abstraction
that a struct or class presents being very clean.

And once you get into classes and inheritance, breaking things up based on
what needs access to private members definitely falls apart in a number of
circumstances, because then you're very clearly abstracting behaviors (which
can then be overidden) as opposed to simply encapsulating data and operating
on it like some structs do. I just tend to think of types in general that
way, not just those involving interfaces and inheritance.

If you're coming at the type from the standpoint that everything that is
conceptually part of the type is actually part of the type, and everything
else is separate, then on some level, that will follow the idea that
functions that access private members are member functions and those that
don't aren't, but at least some of the time, it won't. And in that case, I'm
generally going to make it a member function.

I think that the problem is when folks just add functions to a type when
they don't need to be member functions to do what they do and really aren't
conceptually part of the type. They're just put on there because it's easy
or because that's what folks are used to having to do in languages like Java
or because it works better with auto-completion (which honestly, I think is
one area where IDEs make things worse; having auto-completion is fine, but
writing code in a certain way because of auto-completion is an anti-pattern
IMHO). Every time that a programmer is adding a function, they really should
be considering whether it really should be a member function or whether it
makes more sense for it to be a free function.

So, I think that the advice that member functions should generally be the
set of functions that need access to private members is good think to about
and something that programmers should keep in mind, but I also don't think
that that's really the best dividing line in general as to what should and
shouldn't be a member function. And thanks to how access levels work in D,
it's even less useful as a goal than it would be in C++, because structs and
classes simply aren't encapsulated in the same way, even if programmers
don't normally write code which breaks the encapsulation of structs and
classes unless they need to for the same reasons that you'd write a friend
function in C++.

- Jonathan M Davis
Oct 26 2017
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Thursday, 26 October 2017 at 23:29:24 UTC, Walter Bright wrote:

 The point is that functions that do not need access to private 
 fields should NOT be part of the class. Most of the discussion 
 here is based on the idea that those functions should still be 
 semantically part of the class, even if not physically. That 
 idea should be revisited. Why should they be semantically part 
 of the class?


Because it's functionality of the class. If it's not available, 
it will be reimplemented and duplicated. C++ doesn't have such 
problem, because in a way all imports are public there so you 
have no chance to separate a function from type.
Oct 27 2017
prev sibling parent codephantom <me noyb.com> writes:
On Thursday, 26 October 2017 at 23:29:24 UTC, Walter Bright wrote:

 You can also do things like:

 --- s.d -------
 struct S { int x; ref int X() { return x; } }

 --- splus.d ----
 public import s;
 int increment(S s) { s.X() += 1; } // note no access to S.x

 --- user.d ----
 import splus;
 void foo(ref S s) { s.increment(); }


I'd like to do this too:
-------------------------
import std.stdio;

void main()
{
     //int foo;
     if (int foo.bar != 0)  // no, sorry, you cannot declare foo 
here.
     {
         throw new Exception("foo.bar != 0");
     }
}

auto bar(int x,)
{
     return -10;
}

-----------------------------------------
Oct 31 2017
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright 
wrote:

 for core D devs.

 "How Non-Member Functions Improve Encapsulation" by Scott Meyers

 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

 Note that I'm as guilty as anyone for not understanding or 
 following these guidelines. I expect we can do much better.


The irony is that D’s private is “public to anyone in this 
module”. With that in mind free function or not you don’t get 
anything.

Splitting it off to another module is clunky and I’d use it only 
for functions that may work for different types (template).
Oct 26 2017
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 25, 2017 at 03:19:23PM -0700, Walter Bright via Digitalmars-d wrote:

 for core D devs.
 
 "How Non-Member Functions Improve Encapsulation" by Scott Meyers
 
 http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
 
 Note that I'm as guilty as anyone for not understanding or following
 these guidelines. I expect we can do much better.


Page 2 of this article is essentially another reason why UFCS in D
totally rawkz.  In D, we can take Scott's advice *without* suffering
from syntactic inconsistency between member and non-member functions:

	// C++:
	class C {
		public:
			int method();
		private: ...
	};

	int anotherMethod(C &c, ...);

	C c;
	c.method();
	anotherMethod(c);	// <-- syntactic inconsistency


	// D:
	class C {
		public int method();
		private: ...
	}
	int anotherMethod(C c, ...);

	C c;
	c.method();
	c.anotherMethod();	// <-- Uniform syntax FTW!

Arguably, this means in D encapsulation is even better than in C++: the
user doesn't even have to care whether a function is a member or not.
The same syntax does the Right Thing(tm).

Furthermore, if the class implementation changes in a drastic way that
makes it possible to make a current member function a non-member, we can
do it in D without needing to touch any client code at all!


T

-- 
Кто везде - тот нигде.
Oct 30 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/30/17 1:40 PM, H. S. Teoh wrote:


 Page 2 of this article is essentially another reason why UFCS in D
 totally rawkz.  In D, we can take Scott's advice *without* suffering
 from syntactic inconsistency between member and non-member functions:


You're missing a key piece here, in that anotherMethod does not ensure 
the encapsulation of C. It can call 'method' just fine.

Yes, it's great that UFCS can help with encapsulation via external 
methods, but it's going to be difficult to prevent access to private 
data, you have to use 2 modules. Not a very clean solution IMO.

-Steve
Oct 30 2017
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, October 30, 2017 14:18:56 Steven Schveighoffer via Digitalmars-d 
wrote:

 On 10/30/17 1:40 PM, H. S. Teoh wrote:

 Page 2 of this article is essentially another reason why UFCS in D
 totally rawkz.  In D, we can take Scott's advice *without* suffering



 from syntactic inconsistency between member and non-member functions:


 You're missing a key piece here, in that anotherMethod does not ensure
 the encapsulation of C. It can call 'method' just fine.

 Yes, it's great that UFCS can help with encapsulation via external
 methods, but it's going to be difficult to prevent access to private
 data, you have to use 2 modules. Not a very clean solution IMO.


Yeah, UFCS helps this whole concept, but the way that private works in D
means that compiler-enforced encapsulation simply doesn't happen at the type
level.

Another thing to think about is that private is private to the module rather
than the class or struct partly on the theory that you should be able to
keep track of everything in the module and maintain it appropriately so that
things like whether the type is fully encapsulated aren't really an issue. I
expect that that logic is mainly the justification for not implementing
friend as opposed to the actual reason, but it does pretty much fly in the
face of the idea that you need to be so worried about encapsulation that you
use free functions to prevent a function from accidentally using a private
member.

Still, UFCS does mean that it's less jarring to make something a free a
function, and it then fits well with the cultural push we have to make
functions generic, in which case, they're generally going to be free
functions. But the gains from making something generic are clear, whereas
the encapsulation gains of using a free function with UFCS are far less
substantial, if they exist at all.

- Jonathan M Davis
Oct 30 2017
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 30, 2017 at 02:05:51PM -0600, Jonathan M Davis via Digitalmars-d
wrote:

 On Monday, October 30, 2017 14:18:56 Steven Schveighoffer via Digitalmars-d 
 wrote:

 On 10/30/17 1:40 PM, H. S. Teoh wrote:

 Page 2 of this article is essentially another reason why UFCS in D
 totally rawkz.  In D, we can take Scott's advice *without*
 suffering



 from syntactic inconsistency between member and non-member
 functions:


 You're missing a key piece here, in that anotherMethod does not
 ensure the encapsulation of C. It can call 'method' just fine.

 Yes, it's great that UFCS can help with encapsulation via external
 methods, but it's going to be difficult to prevent access to private
 data, you have to use 2 modules. Not a very clean solution IMO.


 
 Yeah, UFCS helps this whole concept, but the way that private works in
 D means that compiler-enforced encapsulation simply doesn't happen at
 the type level.
 
 Another thing to think about is that private is private to the module
 rather than the class or struct partly on the theory that you should
 be able to keep track of everything in the module and maintain it
 appropriately so that things like whether the type is fully
 encapsulated aren't really an issue.


Yeah, the whole "private is module-private, not aggregate-private"
throws a monkey wrench into the works.  I can understand the logic
behind module-private vs. aggregate-private, but sometimes you really
*do* want aggregate-private, but D doesn't let you express that except
via splitting things up into submodules, which is a lot of overhead for
minor payback.

So my examples would have to involve submodules in order to really prove
the point.


[...]

 Still, UFCS does mean that it's less jarring to make something a free
 a function, and it then fits well with the cultural push we have to
 make functions generic, in which case, they're generally going to be
 free functions. But the gains from making something generic are clear,
 whereas the encapsulation gains of using a free function with UFCS are
 far less substantial, if they exist at all.


[...]

There's definitely gain here, IMO.  Part of the idea of encapsulation is
the independence of client code from implementation details, and one
such implementation detail is whether or not a function is implemented
as a class member or a free function. Ideally user code shouldn't need
to care about the difference.  In C++, however, user code has no choice,
because you can't write obj.func() when func is not a member.

But in D, UFCS allows obj.func() to work for both member functions and
free functions, so if the client code uses the obj.func() syntax, it
won't have to care about the difference.

One may argue about whether allowing arbitrary extensions to a class /
aggregate via UFCS is necessarily a good thing; but IMO, there are
definite benefits to it.  One classic example is std.range using UFCS to
essentially extend built-in arrays to have a range API, by providing
free functions .empty, .front, .popFront that take array arguments.  Of
course, whether this is a good thing can be argued for or against, but I
see this as just one example of a wider pattern of *adaptability*, which
IMO is a very good thing.

For example, suppose you're using a proprietary library that provides a
class X that behaves pretty closely to a range, but doesn't quite have a
range API.  (Or any other API, really.)  Well, that's not a problem, you
just write free functions that forward to class X's methods to bridge
the API gap, and off you go.  You don't have to work with your upstream
provider, who may not be able to provide a fix until months later, and
you don't have to create all sorts of wrapper types just to adapt one
API to another.

And if done right, if a new library version is released which breaks an
old API, say a method xyz() is deprecated and removed, or renamed, or
whatever, all you have to do is to write a free function named xyz, that
forwards to the new method(s), and you don't have to do a massive
upgrade of your entire codebase.  Another win for encapsulation.

(And yes, ideally the upstream library wouldn't break backward
compatibility, but we all know that in the real world it does happen
every now and then. And when it does, the last thing I want to be
worrying about is renaming 1500+ function calls to use xyz(p,q,r) syntax
instead of p.xyz(q,r) syntax. In C++, I'd have no choice, but in D, UFCS
lets my code become agnostic to this distinction, which is a very good
thing IMO.)

And as Scott already mentions, you can spice up the API you were given
with more convenience functions that do frequently-performed method call
sequences.  Carried one step further, this means if you have two
classes, presumably coming from two different vendors, with similar but
not-quite-the-same APIs, UFCS allows me to extend the two APIs so that
they converge.  Then my code can freely use objects from either library
without needing to care about API differences between them. Now,
*that's* encapsulation!

Basically, the more my code can become independent of API changes, the
better.  According to Scott's definition, that's an increase in
encapsulation, because the number of changes required to update my
codebase in the face of an API change is greatly reduced.  UFCS gives me
some pretty powerful tools in this regard.


T

-- 
Тише едешь, дальше будешь.
Oct 30 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 But in D, UFCS allows obj.func() to work for both member 
 functions and free functions, so if the client code uses the 
 obj.func() syntax, it won't have to care about the difference.


I don't like it.

When I see obj.func(), to me, func() is a member function. Why 
should I spend any time trying to work out whether it's a member 
function or a free function? It doesn't make sense to me.

If it's really a free function, I'd like that to be more 
explicit..

e..g

obj.\func().   (or something like that ..where \ means its a free 
function)
Oct 30 2017
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/30/17 9:44 PM, codephantom wrote:

 On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 But in D, UFCS allows obj.func() to work for both member functions and 
 free functions, so if the client code uses the obj.func() syntax, it 
 won't have to care about the difference.


 
 I don't like it.
 
 When I see obj.func(), to me, func() is a member function. Why should I 
 spend any time trying to work out whether it's a member function or a 
 free function? It doesn't make sense to me.
 
 If it's really a free function, I'd like that to be more explicit..
 
 e..g
 
 obj.\func().   (or something like that ..where \ means its a free function)


I once thought as you do (though not as the syntax you propose). I now 
embrace UFCS fully, it's awesome.

-Steve
Oct 30 2017
next sibling parent reply codephantom <me noyb.com> writes:
On Tuesday, 31 October 2017 at 01:47:39 UTC, Steven Schveighoffer 
wrote:

 I once thought as you do (though not as the syntax you 
 propose). I now embrace UFCS fully, it's awesome.

 -Steve


Yeah. I do like UFCS ... I was convinved after seeing Ali talk 
about it:

https://www.youtube.com/watch?v=vYEKEIpM2zo

What a great ambassador for D he is!

But being able to differentiate whether a line of code is calling 
a method of an object, or a free function... that's the area that 
concerns me.

I'm lazy.. I would like such code to be more explicit....and not 
leave it to me to work out what's going on.
Oct 30 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/30/17 9:59 PM, codephantom wrote:

 On Tuesday, 31 October 2017 at 01:47:39 UTC, Steven Schveighoffer wrote:

 I once thought as you do (though not as the syntax you propose). I now 
 embrace UFCS fully, it's awesome.

 -Steve


 
 Yeah. I do like UFCS ... I was convinved after seeing Ali talk about it:
 
 https://www.youtube.com/watch?v=vYEKEIpM2zo
 
 What a great ambassador for D he is!
 
 But being able to differentiate whether a line of code is calling a 
 method of an object, or a free function... that's the area that concerns 
 me.
 
 I'm lazy.. I would like such code to be more explicit....and not leave 
 it to me to work out what's going on.
 


Except... then you can't use generic code with UFCS.

For example, arrays couldn't be ranges, because you can't just do 
arr.front, you'd have to do arr.\front.

-Steve
Oct 30 2017
next sibling parent codephantom <me noyb.com> writes:
On Tuesday, 31 October 2017 at 02:10:26 UTC, Steven Schveighoffer 
wrote:

 Except... then you can't use generic code with UFCS.

 For example, arrays couldn't be ranges, because you can't just 
 do arr.front, you'd have to do arr.\front.

 -Steve


Mmm... it sounds complex ;-)

to make it worse, I can apparently call func() with the 
parenthesis:

obj.func;

now, is func an attribute of obj?
is it a method of obj?
is it a free function?

these syntactic abstractions are leaky...we need to encapsulate 
intent too ;-)
Oct 30 2017
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Monday, October 30, 2017 22:10:26 Steven Schveighoffer via Digitalmars-d 
wrote:

 On 10/30/17 9:59 PM, codephantom wrote:

 On Tuesday, 31 October 2017 at 01:47:39 UTC, Steven Schveighoffer wrote:

 I once thought as you do (though not as the syntax you propose). I now
 embrace UFCS fully, it's awesome.

 -Steve


 Yeah. I do like UFCS ... I was convinved after seeing Ali talk about it:

 https://www.youtube.com/watch?v=vYEKEIpM2zo

 What a great ambassador for D he is!

 But being able to differentiate whether a line of code is calling a
 method of an object, or a free function... that's the area that concerns
 me.

 I'm lazy.. I would like such code to be more explicit....and not leave
 it to me to work out what's going on.


 Except... then you can't use generic code with UFCS.

 For example, arrays couldn't be ranges, because you can't just do
 arr.front, you'd have to do arr.\front.


Honestly, I think that generic code is the _only_ technical advantage of
UFCS - everything else is just subjective preference about syntax. But the
fact that you can call a function without worrying about whether it's a
member function or a free function is huge for generic code - especially if
you want a type to be able to provide an optimized version of a function
(e.g. implementing its own find if it can implement find more efficiently
than the default linear implementation). Without UFCS, it gets way more
complicated to be able to call a function that might be a member function or
a free function, and in likelihood, the result would be that code would
always use one or the other rather than supporting both.

- Jonathan M Davis
Oct 30 2017
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 31 October 2017 at 01:47:39 UTC, Steven Schveighoffer 
wrote:

 On 10/30/17 9:44 PM, codephantom wrote:

 On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 But in D, UFCS allows obj.func() to work for both member 
 functions and free functions, so if the client code uses the 
 obj.func() syntax, it won't have to care about the difference.


 
 I don't like it.
 
 When I see obj.func(), to me, func() is a member function. Why 
 should I spend any time trying to work out whether it's a 
 member function or a free function? It doesn't make sense to 
 me.
 
 If it's really a free function, I'd like that to be more 
 explicit..
 
 e..g
 
 obj.\func().   (or something like that ..where \ means its a 
 free function)


 I once thought as you do (though not as the syntax you 
 propose). I now embrace UFCS fully, it's awesome.


And under the hood the difference is also minimal. A member 
function is compiled to a free function in the object file. It's 
only the mangled name that makes the difference.
Oct 30 2017
prev sibling next sibling parent Dave Jones <dave jones.com> writes:
On Tuesday, 31 October 2017 at 01:44:58 UTC, codephantom wrote:

 On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 But in D, UFCS allows obj.func() to work for both member 
 functions and free functions, so if the client code uses the 
 obj.func() syntax, it won't have to care about the difference.


 I don't like it.

 When I see obj.func(), to me, func() is a member function. Why 
 should I spend any time trying to work out whether it's a 
 member function or a free function? It doesn't make sense to me.


You dont need to know how its implemented. There's no benefit to 
knowing. It's a waste of time / distraction to even think about 
it.
Oct 31 2017
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 31, 2017 at 01:44:58AM +0000, codephantom via Digitalmars-d wrote:

 On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 
 But in D, UFCS allows obj.func() to work for both member functions
 and free functions, so if the client code uses the obj.func()
 syntax, it won't have to care about the difference.
 


 
 I don't like it.
 
 When I see obj.func(), to me, func() is a member function. Why should
 I spend any time trying to work out whether it's a member function or
 a free function? It doesn't make sense to me.


The point is, you *shouldn't have to care*.  If I use a library L that
provides some type T, and the library provides operation X that I can
perform on type T, all I care about is that variables of type T can have
X performed on it.  Is X a member function? A free function?  Who cares!
That's just an implementation detail. As the user of library L, how T
and X are implemented are none of my business.  X can be a remote
procedure call to a network service for all I care -- my code doesn't
have to know.  All it needs to know is that type T can have operation X
performed on it.

That's the whole point of encapsulation.  You *don't have to know* how
something is implemented.  In fact, it's better that you don't, because
later when you upgrade library L, and X changes from member function to
free function, or vice versa, *your code doesn't have to change at all*.
That's why we care about encapsulation in the first place.  Why should
*I* have to change my code just because the upstream authors of library
L decides that X is better implemented as a free function vs. a member
function, or vice versa?  I don't care, and I shouldn't have to care.
Having the same interface (i.e., UFCS syntax) to call X regardless of
how it's implemented is a big advantage, because it frees me, the
downstream user, from needing to care about fiddly details of library
L's implementation.  Instead of upgrading library L and then having to
spend 10 hours fixing all my function calls to X, I can just upgrade
library L and let the compiler figure out which calls are member
functions and which are free functions. My code doesn't have to change
one bit.  Let the machine do the grunt work, free up the human to do the
higher level stuff.

The one case where the difference matters is when you're trying to debug
something.  In that case, I'd say the onus is really upon the debugger
to tell you what kind of function it was.  Surely the debugger must have
this information; it's just a matter of conveying the information to the
user adequately.  If current tools don't allow you to do this easily,
that's a problem with the tools, not with the concept of encapsulation.


T

-- 
Государство делает вид, что платит нам
зарплату, а мы делаем вид, что работаем.
Oct 31 2017
parent reply codephantom <me noyb.com> writes:
On Tuesday, 31 October 2017 at 15:45:42 UTC, H. S. Teoh wrote:

 The one case where the difference matters is when you're trying 
 to debug something.  In that case, I'd say the onus is really 
 upon the debugger to tell you what kind of function it was.


Yes, this is my main concern I guess, as I use pretty plain 
editors that tell me nothing. I rely on the code to tell me what 
I need to know.

foo.bar();
foo.\bar();  // where \ means a free function

A different syntax for calling free functions would certainly 
make it clearer (as the above demonstrates), but as you argue, it 
would have a negative effect on encapsulation.

I guess with a more enhanced editor I could just mouse over UFCS 
syntax, and it could identify a free function from a member 
function. That would be nice, since there's no other way to know 
without exploring code elsewhere...

I guess the days of use a plain text editor...are slowly coming 
to and end ;-(

..what a shame...as I only just recently 'upgraded' from using vi 
to using micro....

https://github.com/zyedidia/micro
Oct 31 2017
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 01, 2017 at 03:38:32AM +0000, codephantom via Digitalmars-d wrote:

 On Tuesday, 31 October 2017 at 15:45:42 UTC, H. S. Teoh wrote:

 The one case where the difference matters is when you're trying to
 debug something.  In that case, I'd say the onus is really upon the
 debugger to tell you what kind of function it was.


 
 Yes, this is my main concern I guess, as I use pretty plain editors
 that tell me nothing. I rely on the code to tell me what I need to
 know.


[...]

 I guess with a more enhanced editor I could just mouse over UFCS
 syntax, and it could identify a free function from a member function.
 That would be nice, since there's no other way to know without
 exploring code elsewhere...


I'm a vim user, and frankly, I don't find the need for "enhanced"
editors at all. (I don't even use syntax highlighting, but that's
another story. :P)

If there's a function call that could be either a member function or a
UFCS free function, all I need is to have the debugger print a
stacktrace and that ought to clear things up.  It will even resolve
other issues like telling me exactly which overload is being called, if
there are complicated overload sets, and point me to the exact file/line
of the code.  At that point, the difference between UFCS free function
or member function is basically irrelevant.



 I guess the days of use a plain text editor...are slowly coming to and
 end ;-(


[...]

Nope.  Plain text editors still rule.  GUIs are for wimps. :-P


T

-- 
The best way to destroy a cause is to defend it poorly.
Nov 01 2017
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 For example, suppose you're using a proprietary library that 
 provides a class X that behaves pretty closely to a range, but 
 doesn't quite have a range API.  (Or any other API, really.)  
 Well, that's not a problem, you just write free functions that 
 forward to class X's methods to bridge the API gap, and off you 
 go.  You don't have to work with your upstream provider, who 
 may not be able to provide a fix until months later, and you 
 don't have to create all sorts of wrapper types just to adapt 
 one API to another.


Yes, the idea here is great. It will work with range functions 
you define. The problem is, it won't work with Phobos functions 
because they do not see your extensions to that proprietary type. 
They see only the true member functions of it.

Unless you hack phobos and add your extensions to that propietary 
library there, which would be a very ugly solution.

You can of course wrap that proprietary range type but that is a 
lot of manual work and requires maintenance. Alias this solves 
some cases but not all of them.

I am not sure what would be the best way for the language to 
handle this but for sure not the present way. The idiom is 
otherwise so great.
Oct 31 2017
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 31, 2017 at 08:45:11AM +0000, Dukc via Digitalmars-d wrote:

 On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 For example, suppose you're using a proprietary library that
 provides a class X that behaves pretty closely to a range, but
 doesn't quite have a range API.  (Or any other API, really.)  Well,
 that's not a problem, you just write free functions that forward to
 class X's methods to bridge the API gap, and off you go.  You don't
 have to work with your upstream provider, who may not be able to
 provide a fix until months later, and you don't have to create all
 sorts of wrapper types just to adapt one API to another.


 
 Yes, the idea here is great. It will work with range functions you
 define.  The problem is, it won't work with Phobos functions because
 they do not see your extensions to that proprietary type. They see
 only the true member functions of it.
 
 Unless you hack phobos and add your extensions to that propietary
 library there, which would be a very ugly solution.
 
 You can of course wrap that proprietary range type but that is a lot
 of manual work and requires maintenance. Alias this solves some cases
 but not all of them.
 
 I am not sure what would be the best way for the language to handle
 this but for sure not the present way. The idiom is otherwise so
 great.


Haha, I knew somebody would bring this up.  I don't have a good solution
to this either.  The problem is that you can't export the type to Phobos
along with the additional UFCS stuff you tacked on to it.  I think
Phobos itself contains several hacks in order to work around this
problem for basic types, like importing std.array in generic code that
doesn't actually reference any arrays, but the import is necessary so
that arrays retain their range API.  Similar problems arise when you
pass user-defined types to Phobos where some methods are implemented as
UFCS.

The basic problem is that when a generic function in Phobos looks up a
method of type T, the lookup is done *in the scope of the Phobos
module*, not the caller's scope that passed in the T in the first place.
For example:

	/* usertype.d */
	module usertype;
	struct UserType {
		int memberMethod(Args...)(Args args);
	}

	/* ufcs.d */
	module ufcs;
	import usertype;
	int ufcsMethod(Args...)(UserType u, Args args);

	/* main.d */
	module main;
	import usertype, ufcs;
	void main() {
		UserType u;
		int x, y, z;

		// Lookup happens in module main, function main.  Since
		// usertype.UserType is visible here, .memberMethod
		// resolves to usertype.UserType.memberMethod.
		u.memberMethod(x, y, z);

		// Lookup happens in module main, function main.  Since
		// ufcs.ufcsMethod is visible here, .ufcsMethod resolves
		// to ufcs.memberMethod.
		u.ufcsMethod(x, y, z);

		// Calls Phobos function
		u.find(x);
	}

	/* snippet of std.algorithm */
	module std.algorithm;
	...
	HayStack find(HayStack, Needle)(HayStack h, Needle n) {
		...
		// Lookup happens in module std.algorithm. Since we
		// don't have the import of module ufcs here,
		// .ufcsMethod cannot be resolved.
		h.ufcsMethod(n);
		...
	}

I wonder if there's an easy way to extend the language so that you can
specify which scope a function lookup will happen in.  Suppose,
hypothetically, we can specify a lookup to happen in the caller's
context.  Then UFCS would work:

	/* snippet of std.algorithm */
	module std.algorithm;
	...
	HayStack find(HayStack, Needle)(HayStack h, Needle n) {
		...
		// Hypothetical syntax:
		with (HayStack.__callerContext)
			h.ufcsMethod(n);
		// Now lookup happens in the caller's context, i.e.,
		// module main, function main.  Since module ufcs is
		// visible there, this call resolves to ufcs.ufcsMethod.
		...
	}

The problem with this is that allowing the callee to access the context
of the caller opens up a can of worms w.r.t. symbol hijacking and
accessing local variables in the caller, which should be illegal.

Seems like the only workable solution in the current language is to wrap
the type in a custom type.  But like you said, that's high-maintenance,
and decreases encapsulation because when the implementation of UserType
changes, the wrapper type needs to change accordingly.  And the current
implementation of alias this is not without its own set of problems.

There *is* a generic wrapper type in Phobos that uses opDispatch for
member forwarding, but last time I checked, it also comes with its own
set of issues.  So currently, we still don't have a perfect solution for
this, even though we're so tantalizingly close.


T

-- 
Unix is my IDE. -- Justin Whear
Oct 31 2017
prev sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Monday, 30 October 2017 at 23:03:12 UTC, H. S. Teoh wrote:

 Yeah, the whole "private is module-private, not 
 aggregate-private" throws a monkey wrench into the works.  I 
 can understand the logic behind module-private vs. 
 aggregate-private, but sometimes you really *do* want 
 aggregate-private, but D doesn't let you express that except 
 via splitting things up into submodules, which is a lot of 
 overhead for minor payback.
 


Have you ever heard of the difference in how private works in D 
vs. C++ ever causing any problems when calling D code from C++, 
or vice-versa?

I imagine if there is an issue with calling C++ code from D, you 
can do what you say wrt submodules, but I'm not sure it really 
matters or not.
Oct 31 2017