On 06/11/2012 21:12, Chris Cain wrote:
... I looked over what you said, and I'm more curious as to what
you might be using modules for. It seems to me like you're using
modules similar to a singleton. Would this be correct? Or am I
missing something?
No, you are correct.
I was annoyed with a l
On Tuesday, 6 November 2012 at 15:34:41 UTC, Faux Amis wrote:
I would have loved an answer to this:
Is there any reason to encapsulate this kind of code in a
struct?
---
module a;
private int _a;
int a(){
return _a;
}
void a(int aIn){
_a = aIn;
}
void useA(){
}
---
module main;
static
On 06/11/2012 16:34, Faux Amis wrote:
What I am trying to get answered here is whether there is something
special about a struct or a class which makes it a 'correct' data
encapsulator where a module does not.
Besides the obvious instantiation of course ;)
On 06/11/2012 07:46, Chris Cain wrote:
On Monday, 5 November 2012 at 08:37:49 UTC, Faux Amis wrote:
Ok, good to see that you are replying to incorrectly scoped variables,
but this is not the point I am trying to make. I know you should
always keep the scope as small as possible.
Eh? I'm confus
On Monday, 5 November 2012 at 08:37:49 UTC, Faux Amis wrote:
Ok, good to see that you are replying to incorrectly scoped
variables, but this is not the point I am trying to make. I
know you should always keep the scope as small as possible.
Eh? I'm confused. The second half of my post certainl
On 05/11/2012 01:45, Chris Cain wrote:
On Sunday, 4 November 2012 at 23:51:15 UTC, Faux Amis wrote:
In your last paragraph you are getting to my point in my other post:
I think there is nothing wrong with a module scope private var as in D
a module is the first encapsulation and adding a wrapper
Chris Cain:
Generally it's better to minimize the scope of variables.
Quoted for truth.
:-)
I was mostly quoting from this blog post, that shows the point is
not just scope:
http://blog.knatten.org/2011/11/11/disempower-every-variable/
It's a simple couple of rules, useful in all languag
On Sunday, 4 November 2012 at 23:51:15 UTC, Faux Amis wrote:
In your last paragraph you are getting to my point in my other
post:
I think there is nothing wrong with a module scope private var
as in D a module is the first encapsulation and adding a
wrapper only adds noise.
These are equivale
On 05/11/2012 00:58, bearophile wrote:
Faux Amis:
I think there is nothing wrong with a module scope private var as in D
a module is the first encapsulation and adding a wrapper only adds noise.
Generally it's better to minimize the scope of variables. So if you wrap
a variable inside a struc
Faux Amis:
I think there is nothing wrong with a module scope private var
as in D a module is the first encapsulation and adding a
wrapper only adds noise.
Generally it's better to minimize the scope of variables. So if
you wrap a variable inside a struct you have often reduced its
scope, u
On 04/11/2012 17:05, Chris Cain wrote:
On Sunday, 4 November 2012 at 14:59:24 UTC, Faux Amis wrote:
I failed to mention that I am mostly talking about private module
scope variables. I don't see how private module scoped vars make for
less testable, readable or more bug prone code.
It's not li
On Sunday, 4 November 2012 at 14:59:24 UTC, Faux Amis wrote:
I failed to mention that I am mostly talking about private
module scope variables. I don't see how private module scoped
vars make for less testable, readable or more bug prone code.
It's not like I feel that you should never use the
On 03/11/2012 21:29, bearophile wrote:
Faux Amis:
Care to elaborate on that?
They share most of the problems of global variables. While not evil,
it's better to avoid module-level mutables. This makes the code more
testable, simpler to understand, less bug prone, and makes functions
more usab
On 03/11/2012 21:29, bearophile wrote:
Faux Amis:
Care to elaborate on that?
They share most of the problems of global variables. While not evil,
it's better to avoid module-level mutables. This makes the code more
testable, simpler to understand, less bug prone, and makes functions
more usab
On Saturday, 3 November 2012 at 20:29:14 UTC, bearophile wrote:
Faux Amis:
Care to elaborate on that?
They share most of the problems of global variables. While not
evil, it's better to avoid module-level mutables. This makes
the code more testable, simpler to understand, less bug prone,
a
Faux Amis:
Care to elaborate on that?
They share most of the problems of global variables. While not
evil, it's better to avoid module-level mutables. This makes the
code more testable, simpler to understand, less bug prone, and
makes functions more usable for other purposes. In D there the
On 02/11/2012 20:19, bearophile wrote:
Faux Amis:
When talking about global variables are we talking about module scope
variables?
Right, in D with "global scope" I meant "module scope".
As I see the module as the most primary data encapsulation in D, I
often use module scope variables (in
Faux Amis:
When talking about global variables are we talking about module
scope variables?
Right, in D with "global scope" I meant "module scope".
As I see the module as the most primary data encapsulation in
D, I often use module scope variables (in combo with static
import).
In my opi
On 02/11/2012 14:13, bearophile wrote:
Adam D. Ruppe:
D normally lets locals shadow globals silently - if you had
int g;
void main() {
int g;
}
that's ok normally so it isn't specific to with. This is a good thing
because it means adding a variable elsewhere won't annoyingly break
your fu
Adam D. Ruppe:
D normally lets locals shadow globals silently - if you had
int g;
void main() {
int g;
}
that's ok normally so it isn't specific to with. This is a good
thing because it means adding a variable elsewhere won't
annoyingly break your functions.
You could argue that doing
On 11/2/12 8:03 AM, Regan Heath wrote:
After reading this:
http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/
I thought, does D have the same "problem", and according to:
http://dlang.org/statement.html#WithStatement
No, it doesn't. D detects local variable shadowing and prod
On Friday, 2 November 2012 at 12:04:28 UTC, Regan Heath wrote:
Should I raise a bug for this?
This one is ok I think because D normally lets locals shadow
globals silently - if you had
int g;
void main() {
int g;
}
that's ok normally so it isn't specific to with. This is a good
thing b
After reading this:
http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/
I thought, does D have the same "problem", and according to:
http://dlang.org/statement.html#WithStatement
No, it doesn't. D detects local variable shadowing and produces an
error. But, then I thought d
23 matches
Mail list logo
