On Tue, 16 Apr 2013 18:51:06 +0100, Tofu Ninja emmo...@purdue.edu wrote:
On Tuesday, 16 April 2013 at 15:23:56 UTC, Regan Heath wrote:
I would question always question fully intended on a case by case
basis:
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
I
On Wed, 17 Apr 2013 12:02:25 +0100, Regan Heath re...@netmail.co.nz
wrote:
So, ultimately encapsulation (one aspect of good design) should lead to
code which is better in every measurable way, including running faster.
It may not have been 100% clear what I was implying here. Because
On Wednesday, 17 April 2013 at 11:02:24 UTC, Regan Heath wrote:
True, but this is what I'd call a short term view of
encapsulation and code quality.
Thinking about encapsulation in the short term is important
because it forces you to properly design things for the long
term. If you don't
On Wed, 17 Apr 2013 12:17:03 +0100, Tofu Ninja emmo...@purdue.edu wrote:
On Wednesday, 17 April 2013 at 11:02:24 UTC, Regan Heath wrote:
True, but this is what I'd call a short term view of encapsulation and
code quality.
Thinking about encapsulation in the short term is important because
On Tuesday, 16 April 2013 at 05:37:48 UTC, Tofu Ninja wrote:
I could not think of what to call this because I don't know if
it has a name to call it by.
Basicly what I was wondering is if their was a way in D to make
a class function pass the object being called on by reference.
might be
On Tuesday, 16 April 2013 at 14:33:21 UTC, John Colvin wrote:
A member function cannot modify it's own 'this' pointer.
However, a free function can do it happily, which when combined
with UFCS gives you the same syntax and behaviour:
class A {
//..
}
void replace(ref A a)
{
On Tuesday, 16 April 2013 at 14:33:21 UTC, John Colvin wrote:
A member function cannot modify it's own 'this' pointer.
However, a free function can do it happily, which when combined
with UFCS gives you the same syntax and behaviour:
class A {
//..
}
void replace(ref A a)
{
On Tuesday, 16 April 2013 at 14:57:11 UTC, Tofu Ninja wrote:
On Tuesday, 16 April 2013 at 14:33:21 UTC, John Colvin wrote:
A member function cannot modify it's own 'this' pointer.
However, a free function can do it happily, which when
combined with UFCS gives you the same syntax and
On Tue, 16 Apr 2013 15:57:09 +0100, Tofu Ninja emmo...@purdue.edu wrote:
On Tuesday, 16 April 2013 at 14:33:21 UTC, John Colvin wrote:
A member function cannot modify it's own 'this' pointer.
However, a free function can do it happily, which when combined with
UFCS gives you the same syntax
On 04/16/2013 07:57 AM, Tofu Ninja wrote:
seems like bad design to
have a function that is fully intended to be a class function but not
actually be able to declare it within the class block.
It would be bad design if a class variable decided to refer to another
object without the owner of
On Tuesday, 16 April 2013 at 15:27:10 UTC, Ali Çehreli wrote:
On 04/16/2013 07:57 AM, Tofu Ninja wrote:
It would be bad design if a class variable decided to refer to
another object without the owner of that variable knowing about
it.
I don't know, It seems like the caller of the function
On Tuesday, 16 April 2013 at 15:23:56 UTC, Regan Heath wrote:
I would question always question fully intended on a case by
case basis:
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197
I agree that grouping functions together that should be used
together, or on the
On 04/16/2013 08:44 AM, Tofu Ninja wrote:
On Tuesday, 16 April 2013 at 15:27:10 UTC, Ali Çehreli wrote:
On 04/16/2013 07:57 AM, Tofu Ninja wrote:
It would be bad design if a class variable decided to refer to another
object without the owner of that variable knowing about it.
I don't
On Tuesday, 16 April 2013 at 21:14:16 UTC, Ali Çehreli wrote:
On 04/16/2013 08:44 AM, Tofu Ninja wrote:
When that happens, would you expect a and b also become handles
to the new object? It could I guess, but it sounds impractical
in a system language. The runtime does not maintain a record of
14 matches
Mail list logo
