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
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
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
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
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
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
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,
On Sun, 20 Apr 2014 03:11:39 -0400, Lars T. Kyllingstad
pub...@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
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
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
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
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:
On Mon, 21 Apr 2014 09:46:18 -0400, Lars T. Kyllingstad
pub...@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
On Mon, 21 Apr 2014 09:46:18 -0400, Lars T. Kyllingstad
pub...@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:
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,
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. :)
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
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
On Mon, 21 Apr 2014 11:02:14 -0400, Andrei Alexandrescu
seewebsiteforem...@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
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.
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[99] data;
auto f() { return data[0]; }
}
auto g(ref S
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 {
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
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
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
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,
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
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
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
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,
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
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
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
33 matches
Mail list logo
