On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
> <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>

Or, for moar compatibility, have enemy functions.

class Klingon { private Starship commanding; }
void nonFriend(enemy Klingon kor) {
    kor.commanding = lol; // error, commanding is private and kor is an enemy
}


Or, to avoid having a new keyword, call it interface
instead of enemy.

Though, then you could just pass an interface instead of
a class too. Take most general possible type.



But, separate modules are kinda cool anyway. I often put
stuff together in one module just for ease of distribution,
but eh modules are cool.

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:nidsvjszuhicjthlpaxm@forum.dlang.org...
> On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
>> <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>
>
> Or, for moar compatibility, have enemy functions.
>
> class Klingon { private Starship commanding; }
> void nonFriend(enemy Klingon kor) {
>     kor.commanding = lol; // error, commanding is private and kor is an
> enemy
> }
>

You forgot:

version(KhitomerAccords) {} else {
    [...]
}

'Course that still doesn't take into account that short period in the middle of DS9, but meh, good enough.

And then there's this line, which I'd consider mandatory for any Trek-related code:

version(JJAbrams)
    static assert(false, "Fuck this shit, this ain't even Star Trek
anyway");

>
> Or, to avoid having a new keyword, call it interface instead of enemy.
>

Don't you mean "static"? ;)

On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
> "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()?

Yes.  My assertion is that you have either the module defining the template import the module that defines the UFCS function (which in this case, std.range imports std.array), or have the module that defines the type import it.  Since range operations are not intrinsic to slices, and are a phobos-defined thing, including them in object.di I don't think is appropriate.  You may think differently.

In the case of .empty, I still contend that as long as we don't have a general definition of .empty being "the true way to check for zero length/elements/whatever," it doesn't belong as an intrinsic for arrays.  std.array defines empty so slices can be used in range functions, which would inevitably import std.range/std.array.  I think you are using .empty() in a generalized non-range fashion, and that is fine.  But we haven't defined .empty in that way, only in terms of ranges.  I know this may seem nit-picky to you, but I think it is important that we *don't* put arbitrary pieces of phobos into druntime because it seems convenient.  There should be a good compelling reason.

> 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.

I understand.  I'm trying to play the role of advocating for existing code.  Not because I think it's better, but because I think we should have a high bar to cross in order to make deep changes like this.  Adding things to object.di should not be a trivial matter.

I also happen to think if(array) and if(!array) should be directly tied to length instead of pointer (this was a big design mistake IMHO).  This would put us in the awkward situation of aliasing a very builtin feature of arrays as a property, seemingly for no reason in hindsight.

>> 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>

I don't think it was a mistake, it makes perfect sense to me.  On the other hand, I fully understand why Meyers' prescription is useful for humongous code bases.  However, I don't see this causing much trouble for code I write.

For instance, you have two classes you may have put into the same module because they are categorically related (not necessarily friends in C++ terms).  It's highly unlikely that you "accidentally" access private information across the classes.  So how much time is "wasted" checking the other class for external references?  Probably none.

-Steve

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:kgwyziwlndczqtafbvrf@forum.dlang.org...
> On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
>>
>> 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>
>
> I don't think it was a mistake, it makes perfect sense to me.  On the other hand, I fully understand why Meyers' prescription is useful for humongous code bases.  However, I don't see this causing much trouble for code I write.
>
> For instance, you have two classes you may have put into the same module because they are categorically related (not necessarily friends in C++ terms).  It's highly unlikely that you "accidentally" access private information across the classes.  So how much time is "wasted" checking the other class for external references?  Probably none.
>

Large portions of D's access specifiers were completely unenforced for a long time and it never caused me much trouble. Doesn't mean they didn't still need to enforced.

On Thursday, 29 March 2012 at 00:21:38 UTC, Andrei Alexandrescu wrote:
> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>
> Andrei

The primitives/utility distinction is an idea I've thought about a lot. UFCS is justifiable not only as a syntactic convenience but as a solution to an important design principle.

Great work guys!

NMS

On 2012-03-30 04:05, Nick Sabalausky wrote:
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>>
>> 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.

Have you seen this:

http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

They compare and old Macintosh from the 80's against a fairly new PC.

-- 
/Jacob Carlborg

On 3/29/2012 6:57 PM, Nick Sabalausky wrote:
> 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.

It doesn't improve intra-module encapsulation, you're right. The point of UFCS, however, is so that *other* modules can extend a class's methods without breaking encapsulation.

In D, the module is the fundamental unit of encapsulation, not the class. The reason is the whole reason that friends exist - sometimes, more than one component (i.e. class) is needed to manipulate private state.

On 3/29/2012 7:05 PM, Nick Sabalausky wrote:
> 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.

I'm in complete agreement with you.

It's like when I bought a new dvd burner, and had to upgrade Nero Burning to deal with it. The old Nero was 6Mb, the new one was 90Mb (!)

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jl3kkf$j4b$1@digitalmars.com...
> On 3/29/2012 6:57 PM, Nick Sabalausky wrote:
>> 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.
>
> It doesn't improve intra-module encapsulation, you're right. The point of UFCS, however, is so that *other* modules can extend a class's methods without breaking encapsulation.
>
> In D, the module is the fundamental unit of encapsulation, not the class. The reason is the whole reason that friends exist - sometimes, more than one component (i.e. class) is needed to manipulate private state.

(Disclaimer: I don't really excpect this to actually get changed at this point, just discussing.)

I definitely agree with this:

"sometimes, more than one component (i.e. class) is needed to manipulate private state"

However, that need could also be served by a "module" access specifier (similar to "package"). Personally, I think that would have been a better approach. (And it would still be much, much better than "friend".)

While there are definitely times I need to access private state across separate components within a module, I find such cases are fairly uncommon, so I question the wisdom of making it the default behavior.

"Jacob Carlborg" <doob@me.com> wrote in message news:jl3kar$ie4$1@digitalmars.com...
> On 2012-03-30 04:05, Nick Sabalausky wrote:
>> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
>>>
>>> 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.
>
> Have you seen this:
>
> http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
>
> They compare and old Macintosh from the 80's against a fairly new PC.
>

Yea, I've seen that. It's a very good article, though. Although I've been saying this since before that article, and even before multi-cores. Contrary to the title, I wasn't at all surprised which won ;)

Of course, I don't expect software to be as super-fine-tuned as it was on, say, the Apple 2 or Atari 2600. There *is* definitely some value in loosing a certain amount of performance to abstractions, up to a point. But we've blown way, way, WAAAY beyond that point.

It's sickening how much gratuitous waste there is in a lot of "modern" software, and really for not much benefit, as D proves.