On Fri, Mar 09, 2012 at 07:32:55PM -0500, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 01:22:49 David Nadlinger wrote:
> > On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis wrote:
> > > UFCS will give people more freedom and may help templates in some cases, […]
[...]
> So, it'll probably help _some_, but I think that there's a good chance that you're right and that it won't be as useful as some people are expecting. But for better or worse, it looks like we're getting it.
[...]

We already have it. Latest DMD in git understands stuff like 2.5.sqrt(),
and supports pseudo-members.


T

-- 
A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived. -- Michael B. Allen

On 03/10/2012 01:22 AM, David Nadlinger wrote:
> On Saturday, 10 March 2012 at 00:16:14 UTC, Jonathan M Davis wrote:
>> UFCS will give people more freedom and may help templates in
>> some cases, […]
>
> Note aside: I think people tend to overestimate the amount of generic
> code that becomes easier to write

If you're writing it yourself there are no restrictions on what symbols can be made visible.

/extend

This OTOH is a valid point.

> with UFCS, as D, in contrast to
> C++, doesn't have ADL.
>

This is a good thing. D symbol lookup is already the most complicated I've seen (for the compiler). DMD does not get it right. It is possible to write programs whose semantics depend on the order the modules are passed on the command line.

On Sat, Mar 10, 2012 at 01:43:35AM +0100, Timon Gehr wrote:
> On 03/10/2012 01:10 AM, H. S. Teoh wrote:
> >On Fri, Mar 09, 2012 at 06:50:50PM -0500, bearophile wrote:
> >>Jonathan M Davis:
> >>
> >>>I don't know what the current state of UFCS is.
> >>
> >>I have found a possible problem in it, and probably there are some missing parts, but it's working well.
> >
> >I found that x.foo doesn't work, it needs to be x.foo(). But we're deprecating omission of parentheses of non-@property functions anyway, and an external function can hardly be a @property of anything, so I don't think this needs to be fixed.
> >
> 
> UFCS for @properties seems to work according to the unit tests. However, this makes @property ambiguous. foo = 2 will be the same as 2.foo.

But 2.foo can never be interpreted as obj.foo = 2. I can't imagine any way to write 2.something and have it come out as obj.foo(2).

The only remote possibility is inside a class/struct method, but in that case doesn't class/struct scope take precedence anyway? And presumably, you wouldn't be using pseudo-members if you're the one writing the class.  Otherwise, if the programmer is deliberately trying to break the system, well, he shouldn't be surprised if things break. :-)


T

-- 
Тише едешь, дальше будешь.

On Fri, 09 Mar 2012 19:32:06 -0500, David Nadlinger <see@klickverbot.at> wrote:

> On Friday, 9 March 2012 at 23:39:25 UTC, Steven Schveighoffer wrote:
>> I want to stress again the difference between C++'s namespaces, and D's module import mechanism.  In C++, you *deliberately* pull a namespace into your scope (and usually only in the implementation file, which doesn't affect any other implementation files), whereas in D, a standard "import std.datetime" *automatically* pulls its namespace into your scope, and any public imports it has made.
>
> To be honest, I don't quite see the big difference here. Just as you can only #include a »namespaced« file without using a using directive, you can »static import« a module in D. You seem to be arguing that we shouldn't encourage use of these features (cf. the std.log discussion), but I can't quite follow you there.

The big difference is, the most straightforward and most exemplified import syntax is:

import modulename;

So to argue this is not the default syntax, or not the most desirable/used syntax is just plain invalid.

In contrast, C++'s import syntax is:

#include "modulename.h"

which does not import any namespaces into your scope.

> Why would _not_ using static and selective imports be desirable? Don't we generally discourage people from write »using namespace std« in C++ or »import *« in Python as well? (I'm aware that the D module system is different, but the general idea is the same)

I don't think we should make the default the most conflicting or difficult to use method.  For example, to say:

"always import log using:

import log = std.log"

Is not as good as just not having to say that (i.e. import std.log like you would any other module).  I remember Tango had a couple of modules like that, and I thought it was pretty confusing.

That doesn't mean you can't utilize those facilities (and I *don't* discourage them).  I just don't think it should be a barrier to usage.

-Steve

On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:
> At first I didn't like it a lot because it's cheap syntax sugar that adds no new power and gives programmers more freedom to write different-looking versions of the the same code (and this is often bad).

What I like about is the encapsulation benefits. You
don't have to know if the function is a method or an
external function, it just works.

External, non-friend (so separate module in D) functions
are often preferable to methods because they don't have
access to the class' private members, so they cannot rely
on those implementation details.

Extending objects with new functions in this way also
means you don't break binary compatibility with the
existing code, since it isn't modified at all!


Of course, you could always do this with the old
syntax too, but then the syntax preference means
you are biased toward one implementation or the
other - it doesn't mesh as well and you may be
tempted to make things methods for the syntax,
despite the cost in compatibility.

UFCS rox.

On Sat, Mar 10, 2012 at 02:05:38AM +0100, Adam D. Ruppe wrote: [...]
> What I like about is the encapsulation benefits. You
> don't have to know if the function is a method or an
> external function, it just works.
> 
> External, non-friend (so separate module in D) functions are often preferable to methods because they don't have access to the class' private members, so they cannot rely on those implementation details.
> 
> Extending objects with new functions in this way also
> means you don't break binary compatibility with the
> existing code, since it isn't modified at all!
> 
> 
> Of course, you could always do this with the old
> syntax too, but then the syntax preference means
> you are biased toward one implementation or the
> other - it doesn't mesh as well and you may be
> tempted to make things methods for the syntax,
> despite the cost in compatibility.
> 
> UFCS rox.

+1. Thanks for bringing this up; this is a very significant benefit.  It makes it possible for you to adapt a class which you can't change (e.g., shipped as a binary-only library) to work with, say, templates that expect certain class members that aren't there but can be implemented using what is available.  UFCS makes this possible without lots of bandaging, mummy-wrapping, or special-casing that adds lots of bloat to template code.

UFCS also makes it possible to implement operator overloading to make diverse types work nicely with each other (esp. if you're importing multiple numerical libraries that don't know of each other's existence).


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond

On 3/9/12 4:59 PM, Steven Schveighoffer wrote:
> I don't think we should make the default the most conflicting or
> difficult to use method. For example, to say:
>
> "always import log using:
>
> import log = std.log"
>
> Is not as good as just not having to say that (i.e. import std.log like
> you would any other module). I remember Tango had a couple of modules
> like that, and I thought it was pretty confusing.
>
> That doesn't mean you can't utilize those facilities (and I *don't*
> discourage them). I just don't think it should be a barrier to usage.

Yah, I'm a bit "ehm" about the sudden recommendation to use named import, too. However, I've been "ehm" about similar things in the past and came to figure that some things are just useful idioms in the forming (e.g. returning locally-defined structs).

I find "import log = std.log" better and using the language more naturally than the alternative - a struct/class in conjunction with the "stuttering" convention std.log.log.


Andrei

On 3/9/12 5:05 PM, Adam D. Ruppe wrote:
> On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:
>> At first I didn't like it a lot because it's cheap syntax sugar that
>> adds no new power and gives programmers more freedom to write
>> different-looking versions of the the same code (and this is often bad).
>
> What I like about is the encapsulation benefits. You
> don't have to know if the function is a method or an
> external function, it just works.
>
> External, non-friend (so separate module in D) functions
> are often preferable to methods because they don't have
> access to the class' private members, so they cannot rely
> on those implementation details.
>
> Extending objects with new functions in this way also
> means you don't break binary compatibility with the
> existing code, since it isn't modified at all!
>
>
> Of course, you could always do this with the old
> syntax too, but then the syntax preference means
> you are biased toward one implementation or the
> other - it doesn't mesh as well and you may be
> tempted to make things methods for the syntax,
> despite the cost in compatibility.
>
> UFCS rox.

Insert obligatory link: http://drdobbs.com/184401197

Very insightful article.


Andrei

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.375.1331338580.4860.digitalmars-d@puremagic.com...
>
> Which is one of the reasons that I really don't like the idea. Sometimes
> it's
> nice with strings, but it creates inconsistencies, and stuff like 5.max(7)
> just
> seems insane. UFCS will give people more freedom and may help templates in
> some cases, but I think that it's a major step back for readibility in
> general.
>

This is why C# requires that you declare a function to be UFCS in order to actualy use it with UFCS syntax (although they don't call it UFCS). I used to be pretty strongly in favor of that, but I've since gotten used to D's lax-ness about it.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jjengv$agm$1@digitalmars.com...
>
> Insert obligatory link: http://drdobbs.com/184401197
>
> Very insightful article.
>

Jesus christ what the FUCK is wrong with Dr Dobbs? The article shows up *just fine* - *at first*, and then once all the excess junk around the edges finishes loading, the stupid fucking thing redirects me (WITH NO BACK BUTTON!) to this useless shit: http://m.drdobbs.com/

What the fuck is wrong with web developers? You'd think at a ***PROGRAMMING*** MAGAZINE they could fucking get basic shit straight without scrwing up things that a NOVICE wouldn't even KNOW how to fuck up! Goddamn.

It sounds like a great article, judging by the first paragraph, but I have to read it a couple sentences at a time. How the hell do "professions" botch things up *that* badly?