March 29, 2012
On 3/29/2012 4:34 PM, Steven Schveighoffer wrote:
> One
> misleading suggestion from the article however, it's not very easy to create
> non-friend non-member functions using UFCS, considering that every function in a
> given module is a friend. In order to do this, you would need a helper module
> for each module that wants to define such non-friend functions. Given the above
> proof, the helper module would also have to be imported by the main module.

I think there's a misunderstanding. The class should contain, as member functions, anything that needs to access private state. UFCS functions declared in other modules should not need access to private state (if they do, it's an error in the design of the class) and so should have no problem being non-friends.

March 30, 2012
On Thu, 29 Mar 2012 19:46:24 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/29/2012 4:34 PM, Steven Schveighoffer wrote:
>> One
>> misleading suggestion from the article however, it's not very easy to create
>> non-friend non-member functions using UFCS, considering that every function in a
>> given module is a friend. In order to do this, you would need a helper module
>> for each module that wants to define such non-friend functions. Given the above
>> proof, the helper module would also have to be imported by the main module.
>
> I think there's a misunderstanding. The class should contain, as member functions, anything that needs to access private state. UFCS functions declared in other modules should not need access to private state (if they do, it's an error in the design of the class) and so should have no problem being non-friends.

I don't think it's a misunderstanding on my part.  If you read Scott's article (as I did a week or so ago when I realized this limitation), he makes this point:

class A
{
   private:
     int x;
   public:
     int getX() { return x; }
     int getXSquared() { return getX() * getX(); }
}

Is more encapsulated with getXSquared moved *outside* the class like this:

int getXSquared(A &a) { return a.getX() * a.getX(); }

and use namespaces to make sure there is no symbol conflict.

The reason being, if you change anything in class A, you do not have to worry about the implementation of getXSquared, because it simply has no access to the private implementation.  You only have to worry about internal methods, and friend functions.

The intention is, getXSquared is a fundamental part of A's interface, so it actually is defined in the same location as A.  That is, it's not an afterthought defined elsewhere, it's part of A's API that should always be with A.

In order to accomplish this in D, getXSquared must go into another module.  There is no mechanism to say "don't give this function access to A's private data".  While I think Scott's arguments are a little strict in light of how D doesn't define explicit friendship, he has a good point.  The D compiler doesn't help you achieve this goal *at all*.

In fact, in order to achieve UFCS with this, you'd have to define the getXSquared method in a helper module, and the module defining A must include the helper, which must include the original module.  This creates a module cycle, so that means you can only have static ctor/dtors in one or the other.  This makes things even more awkward.

-Steve
March 30, 2012
On Wed, 28 Mar 2012 20:21:41 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
> Andrei

Is anyone else's computer complaining about drdobbs having an invalid certificate?  I read the article, and then I wanted to reference it again, and I got the error.  Now I'm hesitant to accept the certificate because it seems to come from a completely different site...

-Steve
March 30, 2012
On 3/29/2012 5:09 PM, Steven Schveighoffer wrote:
> The reason being, if you change anything in class A, you do not have to worry
> about the implementation of getXSquared, because it simply has no access to the
> private implementation. You only have to worry about internal methods, and
> friend functions.

Ok, I see what you're talking about. It has nothing to do with UFCS, it is D's design decision to not have explicit friends, but to make everything in a module implicitly a friend.

I think it's far superior to the explicit friend thing in C++.

I've never seen much cause for hiding things within the same module. It's not like you're allowed to edit one part of the file and not touch another part.
March 30, 2012
On 3/29/2012 5:10 PM, Steven Schveighoffer wrote:
> Is anyone else's computer complaining about drdobbs having an invalid
> certificate? I read the article, and then I wanted to reference it again, and I
> got the error. Now I'm hesitant to accept the certificate because it seems to
> come from a completely different site...


I've never seen anything like that from drdobb's site.
March 30, 2012
On Thu, 29 Mar 2012 20:27:46 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/29/2012 5:09 PM, Steven Schveighoffer wrote:
>> The reason being, if you change anything in class A, you do not have to worry
>> about the implementation of getXSquared, because it simply has no access to the
>> private implementation. You only have to worry about internal methods, and
>> friend functions.
>
> Ok, I see what you're talking about. It has nothing to do with UFCS, it is D's design decision to not have explicit friends, but to make everything in a module implicitly a friend.
>
> I think it's far superior to the explicit friend thing in C++.
>
> I've never seen much cause for hiding things within the same module. It's not like you're allowed to edit one part of the file and not touch another part.

That is precisely what Scott Meyers recommends in the article you referenced :)  He *relies* on the fact that you can edit one part and not worry about examining other parts (using his philosophy, it reduces the amount of code you have to look at when changing private implementation).

FWIW, I agree with you, I think the C++ friend mechanism is awkward for what it does, and I also don't take such hard-line views for code I write (i.e. I don't mind putting code that doesn't access private members as a member function).

-Steve
March 30, 2012
On Thu, 29 Mar 2012 20:28:31 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/29/2012 5:10 PM, Steven Schveighoffer wrote:
>> Is anyone else's computer complaining about drdobbs having an invalid
>> certificate? I read the article, and then I wanted to reference it again, and I
>> got the error. Now I'm hesitant to accept the certificate because it seems to
>> come from a completely different site...
>
>
> I've never seen anything like that from drdobb's site.

Seems to be working again.   huh...

-Steve
March 30, 2012
"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jl2um7$2eq5$1@digitalmars.com...
> On 3/29/2012 5:09 PM, Steven Schveighoffer wrote:
>> The reason being, if you change anything in class A, you do not have to
>> worry
>> about the implementation of getXSquared, because it simply has no access
>> to the
>> private implementation. You only have to worry about internal methods,
>> and
>> friend functions.
>
> Ok, I see what you're talking about. It has nothing to do with UFCS, it is D's design decision to not have explicit friends, but to make everything in a module implicitly a friend.
>
> I think it's far superior to the explicit friend thing in C++.
>
> I've never seen much cause for hiding things within the same module. It's not like you're allowed to edit one part of the file and not touch another part.

That's the *whole point* of moving it outside the class. (Well, that and a smaller vtable.)

In D, if you change this:

-----------------
// foo.d
class Foo
{
    [...core stuff...]
    void extraFunctionality() {...}
}
-----------------

To this:

-----------------
// foo.d
class Foo
{
    [...core stuff...]
}
void extraFunctionality(Foo f) {...}
-----------------

How the heck does that improve encapsualtion? With D's implicit friends, it *doesn't*, it's just shifting things around. There is NO encapsualtion benefit there. Like Steven said, to *get* the encapsualtion, you have to create a whole new module to stick "extraFunctionality" into.


March 30, 2012
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.wbyg2ywyeav7ka@localhost.localdomain...
>
> For builtin types (such as arrays or numbers), there wouldn't be a module that the type was defined.  However, object.di is imported by everything, so extensions could be put in there.
>

Wait, What? Weren't you strongly *opposed* to this last week when I suggested it for empty()?

I'm not trying to be an ass about it. Just not sure if you changed your mind, or I'm missing something, or what.

> One  misleading suggestion from the article however, it's not very easy to create non-friend non-member functions using UFCS, considering that every function in a given module is a friend.  In order to do this, you would need a helper module for each module that wants to define such non-friend functions.  Given the above proof, the helper module would also have to be imported by the main module.
>

Yea, that occurred to me, too. <wishful musing>I've been starting to think more and more that the "everything in a module is a friend" was a mistake, and that we should have instead just had a "module" access specifier like we have "package".</wishful musing>


March 30, 2012
"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jl2p1f$252f$1@digitalmars.com...
> On 3/29/2012 3:00 PM, Nick Sabalausky wrote:
>> Yea, reddit *is* extremely slow whenever there's a reasonable number of
>> comments. And *that's* with JS *off* (and using it that way prevents you
>> from doing *anything* there other than read existing comments, which of
>> course is retarded). And then with JS on, reddit is *insanely* slow.
>> Seriously takes fucking forever. Easily one of the slowest sites I've
>> ever
>> come across. Total piece of shit implementation they have there (and a
>> perfect example of what's wrong with "cloud" and "web 2.0"). It's almost
>> as
>> if the GitHub guys wrote it.
>
>
> True, but I upgraded recently to 64 bit Win 7, with a 6 core processor and SSD drive. Reddit seems a lot zippier :-)

I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably.

Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy.