www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Do non-member functions improve encapsulation in D?

reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
In his article "How non-member functions improve encapsulation" 
[1], Scott Meyers makes a good argument for why free functions 
should generally be preferred over class methods in C++.  TL;DR: 
Fewer member functions means fewer functions that break when the 
class implementation changes, and free functions can be spread 
across different header files, allowing client code to only 
#include the ones that are needed.

In D, the situation is somewhat different.  Firstly, private 
symbols are accessible throughout the module within which the 
class/struct is defined, and secondly, UFC allows us to call free 
functions using the same syntax as member functions.  In other 
words, *any* non-virtual function could in principle be written 
as a free function.

The fact that "private" really means "module private" in D means 
that any number of functions can break when a class/struct 
implementation changes.  So if we are to take Meyers' advice, we 
have to define a new module for each class/struct, and move its 
associated free functions to neighbouring modules.  However, this 
would lead to a proliferation of modules that I doubt anyone 
would want.

So, can anyone think of some good guidelines for when to make a 
function a member, when to write it as a free function in the 
same module, and when to move it to a different module?


[1] 
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
Apr 20 2014
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 20 April 2014 at 07:11:41 UTC, Lars T. Kyllingstad 
wrote:

 In his article "How non-member functions improve encapsulation" 
 [1], Scott Meyers makes a good argument for why free functions 
 should generally be preferred over class methods in C++.  
 TL;DR: Fewer member functions means fewer functions that break 
 when the class implementation changes, and free functions can 
 be spread across different header files, allowing client code 
 to only #include the ones that are needed.

 In D, the situation is somewhat different.  Firstly, private 
 symbols are accessible throughout the module within which the 
 class/struct is defined, and secondly, UFC allows us to call 
 free functions using the same syntax as member functions.  In 
 other words, *any* non-virtual function could in principle be 
 written as a free function.

 The fact that "private" really means "module private" in D 
 means that any number of functions can break when a 
 class/struct implementation changes.  So if we are to take 
 Meyers' advice, we have to define a new module for each 
 class/struct, and move its associated free functions to 
 neighbouring modules.  However, this would lead to a 
 proliferation of modules that I doubt anyone would want.

 So, can anyone think of some good guidelines for when to make a 
 function a member, when to write it as a free function in the 
 same module, and when to move it to a different module?


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


One thing to keep in mind, is that with the module system, and 
templates, is that free functions can only be called if the 
module *knows* about your free function.

For example "int[]" is a range thanks to the free 
"front/popFront", but also *because* `std.range` imports 
`std.array`, and as such *knows* about them.

If you tried the same thing yourself, with your user defined 
type, it wouldn't work.

 From there, while I'm inclined to say that "yes, non-member 
functions improve encapsulation", everything that "defines" an 
object *must* be member. Anything non-member is second class, and 
"helper".
Apr 20 2014
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 08:25:47 UTC, monarch_dodra wrote:

 One thing to keep in mind, is that with the module system, and 
 templates, is that free functions can only be called if the 
 module *knows* about your free function.

 For example "int[]" is a range thanks to the free 
 "front/popFront", but also *because* `std.range` imports 
 `std.array`, and as such *knows* about them.

 If you tried the same thing yourself, with your user defined 
 type, it wouldn't work.


Very true.  This reminds me of another difference between D and 
C++, namely the fact that C++ supports ADL/Koenig lookup, while D 
doesn't.  If it did, arrays would no longer be special in this 
way.  I'm not sure whether the benefits of ADL outweigh the 
drawbacks, though.
Apr 20 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Sunday, 20 April 2014 at 07:11:41 UTC, Lars T. Kyllingstad
wrote:

 In his article "How non-member functions improve encapsulation" 
 [1], Scott Meyers makes a good argument for why free functions 
 should generally be preferred over class methods in C++.  
 TL;DR: Fewer member functions means fewer functions that break 
 when the class implementation changes, and free functions can 
 be spread across different header files, allowing client code 
 to only #include the ones that are needed.

 In D, the situation is somewhat different.  Firstly, private 
 symbols are accessible throughout the module within which the 
 class/struct is defined, and secondly, UFC allows us to call 
 free functions using the same syntax as member functions.  In 
 other words, *any* non-virtual function could in principle be 
 written as a free function.

 The fact that "private" really means "module private" in D 
 means that any number of functions can break when a 
 class/struct implementation changes.  So if we are to take 
 Meyers' advice, we have to define a new module for each 
 class/struct, and move its associated free functions to 
 neighbouring modules.  However, this would lead to a 
 proliferation of modules that I doubt anyone would want.

 So, can anyone think of some good guidelines for when to make a 
 function a member, when to write it as a free function in the 
 same module, and when to move it to a different module?


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


My rules that I try to adhere to are:
* Modules do one thing. All members of a module meet said modules
purpose.
I.e. std.traits is a great example of this, but std.algorithm not
quite so..
* Modules can have many free functions (I classify them as
checks) but few classes/structs unless its a defs file in which
case it can have quite a lot of them but few 'public' functions
and a lot of 'checks' functions.
* If it returns a new instance of a type and needs access to
private class/struct property then member.
* If it returns a new instance but doesn't need a types private
property then free.
* If it doesn't return a new instance of a type but may return
another type then member.

Generally speaking as long as you keep to the first (modules
purpose) rule then they stay smallish. Which is to me the most
important part.

Definition of a checks function is that they do one thing. They
get a single piece of information.
Apr 20 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4/20/14, Lars T. Kyllingstad via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 In his article "How non-member functions improve encapsulation"
 [1], Scott Meyers makes a good argument for why free functions
 should generally be preferred over class methods in C++.


TDPL actually references this IIRC.
Apr 20 2014
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 20 April 2014 at 07:11:41 UTC, Lars T. Kyllingstad 
wrote:

 In his article "How non-member functions improve encapsulation" 
 [1], Scott Meyers makes a good argument for why free functions 
 should generally be preferred over class methods in C++.  
 TL;DR: Fewer member functions means fewer functions that break 
 when the class implementation changes, and free functions can 
 be spread across different header files, allowing client code 
 to only #include the ones that are needed.

 In D, the situation is somewhat different.  Firstly, private 
 symbols are accessible throughout the module within which the 
 class/struct is defined, and secondly, UFC allows us to call 
 free functions using the same syntax as member functions.  In 
 other words, *any* non-virtual function could in principle be 
 written as a free function.

 The fact that "private" really means "module private" in D 
 means that any number of functions can break when a 
 class/struct implementation changes.  So if we are to take 
 Meyers' advice, we have to define a new module for each 
 class/struct, and move its associated free functions to 
 neighbouring modules.  However, this would lead to a 
 proliferation of modules that I doubt anyone would want.

 So, can anyone think of some good guidelines for when to make a 
 function a member, when to write it as a free function in the 
 same module, and when to move it to a different module?


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


This is a quote from Walter that sums the reasoning up perfectly:

"A huge reason for them is to head off the temptation to write 
‘kitchen sink’ classes that are filled with every conceivable 
method. The  desired approach is to have the class implement the 
bare minimum of functionality, and add other functionality with 
extension methods (that do not have access to the class’ private 
state)."

Writing classes like this allows for better encapsulation because 
only the required behaviour is contained within the class keeping 
it focused. Other methods that are useful for the class (but 
don't really belong in the class) can be implemented as non 
member function and if written in a generic way be reused 
throughout the program.
Apr 20 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 11:01:27 UTC, Gary Willoughby wrote:

 This is a quote from Walter that sums the reasoning up 
 perfectly:

 "A huge reason for them is to head off the temptation to write


What does "them" refer to here?


 ‘kitchen sink’ classes that are filled with every conceivable 
 method. The  desired approach is to have the class implement 
 the bare minimum of functionality, and add other functionality 
 with extension methods (that do not have access to the class’ 
 private state)."


However, in D, all functions defined in the same module as a 
class will have access to the private state of that class, on an 
equal footing with its member methods.  Therefore, the above 
statment doesn't really help in deciding which to use.


 Writing classes like this allows for better encapsulation 
 because only the required behaviour is contained within the 
 class keeping it focused. [...]


I'm also pretty sure Walter has repeatedly stated that the module 
is the unit of encapsulation in D, not the class.
Apr 20 2014
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad 
wrote:

 On Sunday, 20 April 2014 at 11:01:27 UTC, Gary Willoughby wrote:

 ‘kitchen sink’ classes that are filled with every conceivable 
 method. The  desired approach is to have the class implement 
 the bare minimum of functionality, and add other functionality 
 with extension methods (that do not have access to the class’ 
 private state)."


 However, in D, all functions defined in the same module as a 
 class will have access to the private state of that class, on 
 an equal footing with its member methods.  Therefore, the above 
 statment doesn't really help in deciding which to use.


 Writing classes like this allows for better encapsulation 
 because only the required behaviour is contained within the 
 class keeping it focused. [...]


 I'm also pretty sure Walter has repeatedly stated that the 
 module is the unit of encapsulation in D, not the class.


Wouldn't this be "worked around" by packages?

You place your class in a non-public subpackage package. Then you 
implement the non-member functions in the module proper.

MyModule
   |
   +--MyPackage
   |    |
   |    +-MyClass
   |
   +--MyNonMemberFunctions


Not sure this is "worth it" though.
Apr 20 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad 
wrote:

 Writing classes like this allows for better encapsulation 
 because only the required behaviour is contained within the 
 class keeping it focused. [...]


 I'm also pretty sure Walter has repeatedly stated that the 
 module is the unit of encapsulation in D, not the class.


That may be true but doesn't detract anything from the quote and 
doesn't mean that classes shouldn't be well designed with good 
encapsulation in mind.
Apr 20 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad 
wrote:

 However, in D, all functions defined in the same module as a 
 class will have access to the private state of that class, on 
 an equal footing with its member methods.  Therefore, the above 
 statment doesn't really help in deciding which to use.


Yeah it does. If the function can be used generically across many 
different parts of the program then it would be much better 
implemented as a non-member function, even if it's defined in the 
same module as an associated class.

Functions which are focused to only deal with data associated 
with a particular class then these would be better suited to be 
implemented as a method of that class.

I'm sure there are edge cases but i'm pretty sure this is the 
general idea.

For example: I worked on a project which included a class that 
internally used a method to perform some math for internal data. 
This method was not related to the class in any way, it just 
performed some calculation on data within that class. This is the 
sort of method that would be better served pulling out of that 
class and moving into a library to be reused elsewhere if needed. 
Thus the class becomes more focused on what its actually supposed 
to do while becoming more maintainable.
Apr 20 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 13:01:53 UTC, Gary Willoughby wrote:

 On Sunday, 20 April 2014 at 11:12:42 UTC, Lars T. Kyllingstad 
 wrote:

 However, in D, all functions defined in the same module as a 
 class will have access to the private state of that class, on 
 an equal footing with its member methods.  Therefore, the 
 above statment doesn't really help in deciding which to use.


 Yeah it does. If the function can be used generically across 
 many different parts of the program then it would be much 
 better implemented as a non-member function, even if it's 
 defined in the same module as an associated class.


I agree.  If a function is generally useful outside the context 
of a class, it should not be defined in the class.



 Functions which are focused to only deal with data associated 
 with a particular class then these would be better suited to be 
 implemented as a method of that class.


This is the tricky part, an it is where I have a hard time 
deciding which to use.  For example:

     struct File {
         private int fileno;
         void read(ubyte[] buf) {
             core.sys.posix.unistd.read(fileno, buf.ptr, 
buf.length);
         }
     }

Why, or when, is the above preferable to the following?

     struct File {
         private int fileno;
     }
     void read(File f, ubyte[] buf)
         core.sys.posix.unistd.read(f.fileno, buf.ptr, buf.length);
     }

I still haven't heard any fact-based, logical arguments that 
advise me on which style to use, and so far it seems to be just 
that -- a matter of style.

There are a few clear-cut cases, such as when a function should 
be virtual, or when it is part of a predefined interface (e.g. 
input range), but in the general case one seems just as 
"encapsulated" as the other.
Apr 21 2014
next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Monday, 21 April 2014 at 08:33:21 UTC, Lars T. Kyllingstad 
wrote:

 This is the tricky part, an it is where I have a hard time 
 deciding which to use.  For example:

     struct File {
         private int fileno;
         void read(ubyte[] buf) {
             core.sys.posix.unistd.read(fileno, buf.ptr, 
 buf.length);
         }
     }

 Why, or when, is the above preferable to the following?

     struct File {
         private int fileno;
     }
     void read(File f, ubyte[] buf)
         core.sys.posix.unistd.read(f.fileno, buf.ptr, 
 buf.length);
     }

 I still haven't heard any fact-based, logical arguments that 
 advise me on which style to use, and so far it seems to be just 
 that -- a matter of style.


In this case i would say go with the method and not a non-member 
function. There are two reasons for this. First the method uses 
private state which is itself a good indicator. Second 'read' is 
an action of 'File'. This is encapsulation in action because you 
are defining logical actions to be performed on the state of a 
class. It's a well formed unit with associated behaviours.

It is confusing to think 'if this was a non-member function in 
the same module i can also access use the private state'. Yes 
that's true but just because you *can* access it, it doesn't mean 
you should! In fact you should have a very well defined reason 
for doing so.

Classes should nearly always be nouns and methods nearly always 
be verbs. Nearly always because there are always exceptions. For 
example i like to name methods which return bool's starting with 
'is'. e.g. isOpen, isRunning, etc. The rule is follow 
encapsulation[1] as much as possible when designing classes.

I found accessing private state in a module is useful when 
*initialising* said state when constructing objects. In this case 
the module can act like a very helpful factory. In a recent 
project i have a rigid class design of an application and it's 
child windows. Other windows should be able to be opened and 
their id's generated automatically and internally. These id's are 
only available as read-only properties. One window in particular 
i needed to create with a specific non-generated id. I couldn't 
include this data in the constructor as i don't want anyone to 
control the id's but *i* needed to this one time. This case 
fitted well into the D module design and allowed me to create a 
window, override its private id and move on knowing that could 
not be tampered with by anything else. This design turned out to 
be very clean and without any baggage of a unnecessary setter 
methods or constructor parameter.

I used to be of the ilk that thought all programming could be 
done using only classes and designing everything in a very strict 
OOP way. D has broken that way of thinking in me purely because 
of things like UFCS and a module's private access to members. Now 
i understand that you can actually achieve a cleaner design by 
moving towards these things instead of having everything as a 
class. First and foremost you must try and achieve a good OOP 
design, this is essential. Then use UFCS and module private 
access features to keep things clean and simple.

Keep things logical, simple and straightforward.

[1]: 
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
Apr 21 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 21 April 2014 at 08:33:21 UTC, Lars T. Kyllingstad 
wrote:

 On Sunday, 20 April 2014 at 13:01:53 UTC, Gary Willoughby wrote:

 Yeah it does. If the function can be used generically across 
 many different parts of the program then it would be much 
 better implemented as a non-member function, even if it's 
 defined in the same module as an associated class.


 I agree.  If a function is generally useful outside the context 
 of a class, it should not be defined in the class.


I think this view is too simple. Even if a function is generally 
useful you risk ending up with maintenance problems later on when 
you need to optimize your code. So if in doubt, make it local.

Unless you write libraries the primary goal with encapsulation is 
not reuse, but being able to evolve, modify, refactor, optimize. 
So having a local wrapper on top of a generic function or just 
make it local until you need it somewhere else is quite 
acceptable IMO. (But whether it is inside the class or not is 
mostly syntactical?)

I've one time too many done too early refactoring under the 
assumption that it would lead to better, resusable code. It 
seldom does. It often leads to a wasted design effort, less 
intuitive function names and more fragmented code that is harder 
to understand later on.

Ola.
Apr 21 2014
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 13:03:50 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 21 April 2014 at 08:33:21 UTC, Lars T. Kyllingstad 
 wrote:

 On Sunday, 20 April 2014 at 13:01:53 UTC, Gary Willoughby 
 wrote:

 Yeah it does. If the function can be used generically across 
 many different parts of the program then it would be much 
 better implemented as a non-member function, even if it's 
 defined in the same module as an associated class.


 I agree.  If a function is generally useful outside the 
 context of a class, it should not be defined in the class.


 I think this view is too simple. Even if a function is 
 generally useful you risk ending up with maintenance problems 
 later on when you need to optimize your code. So if in doubt, 
 make it local.


I agree, but I think that's more a question of *when* a function 
is considered "generally useful".  To me, that is when I have an 
actual use case for it beyond the one for which it was originally 
designed, and not just because I think it might come in handy 
some time in the future.  "If in doubt, make it private" is 
always a good guideline.
Apr 21 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:

 The fact that "private" really means "module private" in D means that
 any number of functions can break when a class/struct implementation
 changes.


No, only those in that module. There's no change. -- Andrei
Apr 20 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 20:36:58 UTC, Andrei Alexandrescu 
wrote:

 On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:

 The fact that "private" really means "module private" in D 
 means that
 any number of functions can break when a class/struct 
 implementation
 changes.


 No, only those in that module. There's no change. -- Andrei


Ok, so "any number" was poorly phrased.  What I meant was "a 
large number", because in my experience, modules tend to be quite 
large.  Specifically, they are rarely limited to containing just 
a single class.  They often contain multiple classes, along with 
most related functionality.  In principle, changing the 
implementation of one class can break the implementation of 
another class!  Now, you may argue that kitchen sink modules are 
poor programming style, but it seems to be a common style, with 
Phobos being a very prominent example. :)

I often wish "private" meant class private in D.  I know, the 
usual argument against this is that someone who writes a module 
usually has full control of that module, but again, Phobos is an 
example of the contrary.  Each module has at least a dozen 
authors, even if they aren't all listed in the documentation.

I also know it's never going to happen due to the amount of code 
breakage it would cause.  But maybe we could extend the syntax a 
bit?  E.g. "private(class)" or "class private"?
Apr 21 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 1:49 AM, Lars T. Kyllingstad wrote:

 On Sunday, 20 April 2014 at 20:36:58 UTC, Andrei Alexandrescu wrote:

 On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:

 The fact that "private" really means "module private" in D means that
 any number of functions can break when a class/struct implementation
 changes.


 No, only those in that module. There's no change. -- Andrei


 Ok, so "any number" was poorly phrased.  What I meant was "a large
 number", because in my experience, modules tend to be quite large.


The point here is boundedness, i.e. whether stuff that's affected is 
within your control or not. The module you're working on is trivially 
"yours". Changes visible outside the module are "unbounded" because they 
affect present and future client code.


 I often wish "private" meant class private in D.


I think we're in good shape here.


Andrei
Apr 21 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 21 Apr 2014 11:02:14 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 4/21/14, 1:49 AM, Lars T. Kyllingstad wrote:

 On Sunday, 20 April 2014 at 20:36:58 UTC, Andrei Alexandrescu wrote:

 On 4/20/14, 12:11 AM, Lars T. Kyllingstad wrote:

 The fact that "private" really means "module private" in D means that
 any number of functions can break when a class/struct implementation
 changes.


 No, only those in that module. There's no change. -- Andrei


 Ok, so "any number" was poorly phrased.  What I meant was "a large
 number", because in my experience, modules tend to be quite large.


 The point here is boundedness, i.e. whether stuff that's affected is  
 within your control or not. The module you're working on is trivially  
 "yours". Changes visible outside the module are "unbounded" because they  
 affect present and future client code.


 I often wish "private" meant class private in D.


 I think we're in good shape here.


Sure, but Lars' point that it completely precludes the encapsulation  
mechanism that Scott is advocating, is true. You would have to put the  
functions outside the core module to give them the same isolation as  
non-friend C++ global functions.

Note, I'm with you that the current mechanism is the "right way." It just  
completely prevents that technique of encapsulation :)

-Steve
Apr 21 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 8:08 AM, Steven Schveighoffer wrote:

 Sure, but Lars' point that it completely precludes the encapsulation
 mechanism that Scott is advocating, is true. You would have to put the
 functions outside the core module to give them the same isolation as
 non-friend C++ global functions.

 Note, I'm with you that the current mechanism is the "right way." It
 just completely prevents that technique of encapsulation :)

 -Steve


Got it, thanks. -- Andrei
Apr 21 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 21/04/14 10:49, Lars T. Kyllingstad wrote:


 Ok, so "any number" was poorly phrased.  What I meant was "a large
 number", because in my experience, modules tend to be quite large.
 Specifically, they are rarely limited to containing just a single
 class.  They often contain multiple classes, along with most related
 functionality.  In principle, changing the implementation of one class
 can break the implementation of another class!  Now, you may argue that
 kitchen sink modules are poor programming style, but it seems to be a
 common style, with Phobos being a very prominent example. :)


Phobos is a very bad example of code organizing. I'm almost exclusively 
organizing with one class per module and a deeper hierarchy of packages. 
Not saying that is the ideal solution.

-- 
/Jacob Carlborg
Apr 21 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 22 April 2014 at 06:39:47 UTC, Jacob Carlborg wrote:

 On 21/04/14 10:49, Lars T. Kyllingstad wrote:


 Ok, so "any number" was poorly phrased.  What I meant was "a 
 large
 number", because in my experience, modules tend to be quite 
 large.
 Specifically, they are rarely limited to containing just a 
 single
 class.  They often contain multiple classes, along with most 
 related
 functionality.  In principle, changing the implementation of 
 one class
 can break the implementation of another class!  Now, you may 
 argue that
 kitchen sink modules are poor programming style, but it seems 
 to be a
 common style, with Phobos being a very prominent example. :)


 Phobos is a very bad example of code organizing. I'm almost 
 exclusively organizing with one class per module and a deeper 
 hierarchy of packages. Not saying that is the ideal solution.


I like it much more than class-based privacy for the simple 
reason that I hate classes :) What is really missing here is 
proper `package` protection that is actually usable (can select 
package name it applies to). When it is implemented, you can 
emulate same encapsulation layout by simply replacing classes 
with modules and modules with packages.
Apr 24 2014
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 22 April 2014 at 06:39:47 UTC, Jacob Carlborg wrote:

 I'm almost exclusively organizing with one class per module and 
 a deeper hierarchy of packages. Not saying that is the ideal 
 solution.


That's what i've started to do in a recent project and then use 
the special 'package.d' file to provide a package. Sometimes you 
may have a couple of related classes or enums in each file too 
but only if they need to be friendly with the main class. This 
way is much more clear and neat.
Apr 24 2014
prev sibling parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 21/04/2014 09:49, Lars T. Kyllingstad wrote:

 I often wish "private" meant class private in D.  I know, the usual
 argument against this is that someone who writes a module usually has
 full control of that module, but again, Phobos is an example of the
 contrary.  Each module has at least a dozen authors, even if they aren't
 all listed in the documentation.


I think this is a good argument. True private aids developers when 
refactoring. Also synchronized classes always have true private members, 
so it would be better if D could express it instead of changing the 
meaning of 'private' for them.


 I also know it's never going to happen due to the amount of code
 breakage it would cause.  But maybe we could extend the syntax a bit?
 E.g. "private(class)" or "class private"?


Perhaps the following would work:

* Add 'module' as synonym for 'private'
* Add ' private' for true private access
* Deprecate 'private' after some years

I doubt this would be popular due to churn, but I would support it.
Apr 24 2014
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 20 Apr 2014 03:11:39 -0400, Lars T. Kyllingstad  
<public kyllingen.net> wrote:


 So, can anyone think of some good guidelines for when to make a function  
 a member, when to write it as a free function in the same module, and  
 when to move it to a different module?


First, you rightly destroy the main reason for making a module-level  
function vs. a method for D -- module-level functions have access to the  
private data. Therefore, the motivation to make a module-level function is  
significantly diminished. In my opinion, I would say that you should  
always first try making them methods, but under certain cases, you should  
make them functions.

Reasons off the top of my head not to make them module functions:

1. You can import individual symbols from modules. i.e.:

import mymodule: MyType;

If a large portion of your API is module-level functions, this means you  
have to either import the whole module, or the individual methods you plan  
to use.

2. You can get delegates to methods. You cannot get delegates to module  
functions, even if they are UFCS compatible.

3. There is zero chance of a conflict with another type's similarly named  
method.

4. It enforces the "method call" syntax. I.e. you cannot use foo(obj)  
call. This may be important for readability.

5. You can only use operator overloads via methods. D is different in this  
respect from C++.

6. The documentation will be grouped with the object itself. This becomes  
even more critical with the new doc layout which has one page per type.

Reasons to make them module functions:

1. You have more than one object in the same file which implements the  
method identically via duck typing.

2. You want to change how the 'this' type is passed -- in other words, you  
want to pass a struct by value or by pointer instead of by ref.


module-level API to be selectively enabled!

4. Of course, if you are actually implementing in a different module,  
Scott Meyers' reasoning applies there.

-Steve
Apr 21 2014
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 12:45:12 UTC, Steven Schveighoffer 
wrote:

 [...]

 Reasons off the top of my head not to make them module 
 functions:

 1. You can import individual symbols from modules. i.e.:

 import mymodule: MyType;

 If a large portion of your API is module-level functions, this 
 means you have to either import the whole module, or the 
 individual methods you plan to use.


Based on this, combined with your points 6 and 3 further down -- 
the second number 3, that is :) -- we can make the following 
guideline:

Methods which are central to the class' usage, and which are 
therefore likely to be used often, should be member functions, 
while auxiliary functions and convenience functions should be 
non-members.

The same thing was stated earlier in this thread, in different 
words, and I guess it is the rule most of us use already.  
However, this is the first non-subjective rationale I've seen for 
it so far.  Awesome!


 2. You can get delegates to methods. You cannot get delegates 
 to module functions, even if they are UFCS compatible.


This is an excellent point.  I would never have thought of that.


 3. There is zero chance of a conflict with another type's 
 similarly named method.


How?  If you have the following functions:

     void foo(A a);
     void foo(B b);

and you write

     foo(new B);

there is also zero chance of conflict -- even if B happens to be 
a subclass of A, since the most specialised function is always 
called.


 4. It enforces the "method call" syntax. I.e. you cannot use 
 foo(obj) call. This may be important for readability.


Some would argue that giving users the choice between typing 
foo(obj) and obj.foo() is a Good Thing, because it doesn't impose 
your preferences on them.  I'm not going to do that, though. ;)


 5. You can only use operator overloads via methods. D is 
 different in this respect from C++.


True. Operator overloads fall in the same category as virtuals 
and interface functions, i.e., the ones that *cannot* be 
non-members.


 [...]

 Reasons to make them module functions:

 1. You have more than one object in the same file which 
 implements the method identically via duck typing.

 2. You want to change how the 'this' type is passed -- in other 
 words, you want to pass a struct by value or by pointer instead 
 of by ref.


 module-level API to be selectively enabled!

 4. Of course, if you are actually implementing in a different 
 module, Scott Meyers' reasoning applies there.


All very good points.  This is exactly what I was looking for, 
thanks!
Apr 21 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 21 Apr 2014 09:46:18 -0400, Lars T. Kyllingstad  
<public kyllingen.net> wrote:


 On Monday, 21 April 2014 at 12:45:12 UTC, Steven Schveighoffer wrote:

 3. There is zero chance of a conflict with another type's similarly  
 named method.


 How?  If you have the following functions:

      void foo(A a);
      void foo(B b);

 and you write

      foo(new B);

 there is also zero chance of conflict -- even if B happens to be a  
 subclass of A, since the most specialised function is always called.


Demonstration:

module m1;
import std.stdio;

class C {}

void foo(C c)
{
    writeln("C.foo");
}

void bar(C c)
{
    writeln("C.bar");
}

module m2;
import m1;
import std.stdio;

void foo(T)(T t)
{
   writeln("m2.foo");
}

void bar(T)(T t, int x)
{
   writeln("m2.bar");
}

void main()
{
    auto c = new C;
    c.foo(); // "m2.foo";
    //c.bar(); // error if uncommented!
}

Basically, I've inadvertently overridden C.foo, without intending to. With  
bar, I've somehow hidden the inherent functionality of C!


 4. It enforces the "method call" syntax. I.e. you cannot use foo(obj)  
 call. This may be important for readability.


 Some would argue that giving users the choice between typing foo(obj)  
 and obj.foo() is a Good Thing, because it doesn't impose your  
 preferences on them.  I'm not going to do that, though. ;)


You may recall that I am a big proponent of explicit properties because I  
think the ways of calling functions have strong implications to the  
reader, regardless of the functions. This is the same thing. I look at  
foo(x) much differently than x.foo().

It's the same (though not quite as important) as choosing a good name for  
a function.

-Steve
Apr 21 2014
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 14:10:08 UTC, Steven Schveighoffer 
wrote:

 [...]

 module m1;
 import std.stdio;

 class C {}

 void foo(C c)
 {
    writeln("C.foo");
 }

 void bar(C c)
 {
    writeln("C.bar");
 }

 module m2;
 import m1;
 import std.stdio;

 void foo(T)(T t)
 {
   writeln("m2.foo");
 }

 void bar(T)(T t, int x)
 {
   writeln("m2.bar");
 }

 void main()
 {
    auto c = new C;
    c.foo(); // "m2.foo";
    //c.bar(); // error if uncommented!
 }

 Basically, I've inadvertently overridden C.foo, without 
 intending to. With bar, I've somehow hidden the inherent 
 functionality of C!


Wow, I didn't know that.  I thought the most specialised function 
would always be selected, regardless of which module it's defined 
in.  What you've demonstrated feels wrong, somehow.


 4. It enforces the "method call" syntax. I.e. you cannot use 
 foo(obj) call. This may be important for readability.


 Some would argue that giving users the choice between typing 
 foo(obj) and obj.foo() is a Good Thing, because it doesn't 
 impose your preferences on them.  I'm not going to do that, 
 though. ;)


 You may recall that I am a big proponent of explicit properties 
 because I think the ways of calling functions have strong 
 implications to the reader, regardless of the functions. This 
 is the same thing. I look at foo(x) much differently than 
 x.foo().


And you may recall that I was on the same side as you in the 
properties debate, though less vocal about it.  (In fact, I think 
we didn't go far enough with properties -- we should also forbid 
taking their address.  But that's another discussion.)  The point 
is, I lean towards the same view as you when it comes to UFCS, 
and only brought up the opposing view for the sake of the 
discussion.

I tend to use UFCS only for a few select cases (array range 
functions, range chaining, etc.), and to otherwise use the 
"normal" function call syntax.  If someone sees this in my code:

   obj.foo();

I want them to know where to look for further information about 
foo(), namely in the class documentation/code.
Apr 21 2014
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 14:38:53 UTC, Lars T. Kyllingstad 
wrote:

 What you've demonstrated feels wrong, somehow.


As in "it shouldn't be that way", not as in "I think you're wrong 
about this". :)
Apr 21 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 21 April 2014 at 14:10:08 UTC, Steven Schveighoffer 
wrote:

 You may recall that I am a big proponent of explicit properties 
 because I think the ways of calling functions have strong 
 implications to the reader, regardless of the functions. This 
 is the same thing. I look at foo(x) much differently than 
 x.foo().


I agree. What was the reasoning by conflating the two?

I only see disadvantages:
- harder to read
- reduced namespace
- possibility of breaking application code when adding members to 
libraries?
Apr 21 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 21 Apr 2014 09:46:18 -0400, Lars T. Kyllingstad  
<public kyllingen.net> wrote:


 On Monday, 21 April 2014 at 12:45:12 UTC, Steven Schveighoffer wrote:



 3. There is zero chance of a conflict with another type's similarly  
 named method.


 How?  If you have the following functions:

      void foo(A a);
      void foo(B b);

 and you write

      foo(new B);

 there is also zero chance of conflict -- even if B happens to be a  
 subclass of A, since the most specialised function is always called.


I definitely restricted myself too much when I said "another type." Yes,  
there is a very low possibility of A and B conflicting. But as I showed in  
the other post, there is the possibility of confusing the compiler when  
calling a UFCS method.

Essentially, the core issue is that a type provides the strongest tie to  
its method overload set. The module's overload set has looser ties, so  
they can be accidentally (or intentionally) overridden. It was a common  
con against UFCS before it was introduced.

-Steve
Apr 21 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4/21/14, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Reasons off the top of my head not to make them module functions


Here's another one, the bug report is about enums but it showcases an
issue with module-scoped functions taking struct parameters (in short:
function hijacking protection makes defining module-scoped functions
problematic):

https://issues.dlang.org/show_bug.cgi?id=10846
Apr 21 2014
prev sibling parent reply Artur Skawina via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 04/21/14 14:45, Steven Schveighoffer via Digitalmars-d wrote:

 Reasons off the top of my head not to make them module functions:


[...]

Functions, unlike methods, do not work with rvalues.

Ie

   struct S {
      long[999999] data;
      auto f() { return data[0]; }
   }

   auto g(ref S _this) { with (_this) return data[1]; }

   void main() {
      auto a = S().f();
      auto b = S().g();
   }

artur
Apr 21 2014
parent "Meta" <jared771 gmail.com> writes:
On Monday, 21 April 2014 at 16:35:23 UTC, Artur Skawina via 
Digitalmars-d wrote:

 On 04/21/14 14:45, Steven Schveighoffer via Digitalmars-d wrote:

 Reasons off the top of my head not to make them module 
 functions:


 [...]

 Functions, unlike methods, do not work with rvalues.

 Ie

    struct S {
       long[999999] data;
       auto f() { return data[0]; }
    }

    auto g(ref S _this) { with (_this) return data[1]; }

    void main() {
       auto a = S().f();
       auto b = S().g();
    }

 artur


Shouldn't this be possible if you want to make g a template 
function and use auto ref? Regardless, it doesn't. Probably a 
compiler bug:

   struct S {
      long[999999] data;
      auto f() { return data[0]; }
   }

   //No good
   //auto g(T: S)(auto ref T _this) { with (_this) return data[1]; 
}

   //Doesn't work either
   //auto g()(auto ref S _this) { with (_this) return data[1]; }

   void main() {
      auto a = S().f();
      auto b = S().g();
   }
Apr 21 2014