On Wed, Nov 01, 2017 at 03:38:32AM +, 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
> >
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
On Tue, Oct 31, 2017 at 08:45:11AM +, 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
On Tue, Oct 31, 2017 at 01:44:58AM +, 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,
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
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
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
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
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
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
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
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
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:
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
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
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
> > >
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
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
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
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
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
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
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
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
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);
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,
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
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
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
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
> >
> >
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
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
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.
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
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
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
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.
37 matches
Mail list logo
