View mode: basic / threaded / horizontal-split · Log in · Help
March 30, 2012
Re: UFCS for D
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.
March 30, 2012
Re: UFCS for D
"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"? ;)
March 30, 2012
Re: UFCS for D
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
March 30, 2012
Re: UFCS for D
"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.
March 30, 2012
Re: UFCS for D
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
March 30, 2012
Re: UFCS for D
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
March 30, 2012
Re: UFCS for D
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.
March 30, 2012
Re: UFCS for D
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 (!)
March 30, 2012
Re: UFCS for D
"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.
March 30, 2012
Re: UFCS for D
"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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home