davepermen wrote:
> but the by far most straightforward and logical way. you don't need delegates as
> well, you can do that with a library-implementation. see boost::function.

There are lots of reasons not to use boost.  It's big and monolithic and doesn't nicely fit into other build systems.  Blech.  boost::function has an inordinately convoluted implementation as well. (which includes some impressively obfuscated preprocessor hackery, and just plain brute forced template declarations for dealing with up to 50 arguments)

> the trick is, with operator overloading as free functions we get much more
> flexibility than only for streams. but there its most obvious. it will be as
> fast as directly setting up the specific code for your specific output stream
> format manually. (the chain of write(stream,T) calls), wich is the fastest way.
> in every other situation, we have to rely on compiler optimisations to _KNOW_
> its as fast.
> 
> if you don't see that, you don't see encapsulation as something important, then?
> because operators don't belong to types, they should never be in their
> interface.

I'd like to see proof that one more virtual call per nonPDT element being written is going to be unaccetably slow before agreeing that it's the only way.  Premature optimization and all that.

Fast is good, but one of the main goals of D is to keep Walter from having to turn his head inside out making the compiler work right. Simple compilers also tend to be fast compilers.  I'm willing to give a few inches on this subject.

As for encapsulation, I do believe that nonmember functions are more encapsulated than member functions, since they are forced to rely on the public interface, and are therefore immune to implementation fluxuations.  Operator overloads are a small enough minority that I don't see this as being a particularly important issue.  There are far more methods that are not overloading an operator than are.

 -- andy

Hauke Duden wrote:
> Yes, I understand that. But I still don't see how this issue is different from having "normal" overloaded global functions.

Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.

> If I have two modules, foo and bar, each with a different version of function f, and I call f in another module, isn't that the exact same problem, as if f was an opAdd overload and the call an expression of the kind (a+b)?

The problem is, it doesn't work.

> I really don't see how global operators are different from global functions!

They are not. That's the reason cross-module overloads don't work. They don't work for normal functions. And for operators, it is simply bloody forbidden to use module scope, because it would not make the problem better, just worse!

-eye

>davepermen wrote:
>> but the by far most straightforward and logical way. you don't need delegates as well, you can do that with a library-implementation. see boost::function.
>
>There are lots of reasons not to use boost.  It's big and monolithic and doesn't nicely fit into other build systems.  Blech.  boost::function has an inordinately convoluted implementation as well. (which includes some impressively obfuscated preprocessor hackery, and just plain brute forced template declarations for dealing with up to 50 arguments)

this was sarcasm, dude! the hackery boost has to do to implement rather good features into c++ is impressive (boost itself is an amazing piece of code! nothing against that). but boost::function can not in any form replace a simple delegate as in D

>Fast is good, but one of the main goals of D is to keep Walter from having to turn his head inside out making the compiler work right. Simple compilers also tend to be fast compilers.  I'm willing to give a few inches on this subject.
fully agreeing with the compiler thing. but knowing there is a fast, and
theoretically very simple way, to accomplish an in general very fast and proper
solution by default, makes me believe its worth fighting for it.
i see the issues, but it doesn't remove the fact, that the way c++ allows to
write operators give us a great way to make it work without virtual functions.

>As for encapsulation, I do believe that nonmember functions are more encapsulated than member functions, since they are forced to rely on the public interface, and are therefore immune to implementation fluxuations.
exactly

>perator overloads are a small enough minority that I don't see this as being a particularly important issue.  There are far more methods that are not overloading an operator than are.
as they are just syntactic sugar, its, imho, entierly WRONG that they ever can access inner parts of an object..

but if its really not possible for walter to find a way he likes it, then its okay.. i still don't see any reason for it. operators and functions are in my eyes, 100% interchangeable. if you can't call a function without specifiyng the package, then you simply can't use such an operator, too.. wouldn't hurt ME at all. as they are just sugar, as i said, yet.

Ilya Minkov wrote:
> Hauke Duden wrote:
> 
>> Yes, I understand that. But I still don't see how this issue is different from having "normal" overloaded global functions.
> 
> 
> Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.

I wasn't aware of that - thanks for explaining. So the problem IS the same with global functions, and it is not solved there either, just circumvented.

That doesn't make it any better, though :(.

Hauke

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bti1ij$1sv$1@digitaldaemon.com...
> Ilya Minkov wrote:
> > Hauke Duden wrote:
> >
> >> Yes, I understand that. But I still don't see how this issue is different from having "normal" overloaded global functions.
> >
> >
> > Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.
>
> I wasn't aware of that - thanks for explaining. So the problem IS the same with global functions, and it is not solved there either, just circumvented.
>
> That doesn't make it any better, though :(.

Agreed.

<snip>

> if you don't see that, you don't see encapsulation as something important,
then?
> because operators don't belong to types, they should never be in their interface.

Well put!

"Ilya Minkov" <minkov@cs.tum.edu> wrote in message news:bthrlf$2p6n$2@digitaldaemon.com...
> Hauke Duden wrote:
> > Yes, I understand that. But I still don't see how this issue is different from having "normal" overloaded global functions.
>
> Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.
>
> > If I have two modules, foo and bar, each with a different version of function f, and I call f in another module, isn't that the exact same problem, as if f was an opAdd overload and the call an expression of the kind (a+b)?
>
> The problem is, it doesn't work.

Even if you import foo and bar?? I thought that was the whole point of
import - to bring symbols into the current scope.
Is anyone really suggesting that this mechanism should work *without*
requiring import statements?

> > I really don't see how global operators are different from global functions!
>
> They are not. That's the reason cross-module overloads don't work. They don't work for normal functions. And for operators, it is simply bloody forbidden to use module scope, because it would not make the problem better, just worse!

Again, that is what "import" is for.

"davepermen" <davepermen_member@pathlink.com> wrote in message news:bthndh$2jdb$1@digitaldaemon.com...
> i do understand that. but you simply can't overload your prefered operator
for
> ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.
> free overloadable functions give the ability to add overloads to your
stream
> without any rewriting of stream or type.
>
> THAT is why i want free operators. they are the way operators behave, and
they
> are the only way to make streams fast extendable and type save. and FAST. everyone cries that they have to be faster than the c++ streams. believe
me they
> can be hell fast. and i can for sure overload all sort of types for my
stdout
> class and then write stdout << a << b << c; but this is nost scalable.
>
> a library ALWAYS has to provide features a user can use for ANY situation.
that
> means he has to have a nice plugin-interface. overloadable free operators
are a
> GREAT plugin-interface for streams.

I understand your point. But there's got to be a better way than ADL.

operators have to be in the module you use them (sort of private operators), or in one of the modules of one of the used types. just as overloadable functions, more or less..

on the other hand.. the

print(..) { /+ defines this is chainable +/ } // only two dots, like in [x..y]
print(int x) { printf("%i",x); }
print(char[] x) { printf("%.*s",x); }
print(vec3 x) { printf("(%f,%f,%f)",x.x,x.y,x.z); }

etc

wich concatenates

print("Hello World, my Name is ",davepermen," I'm ",19," and i life at
",position);

wich will then map to
print(char[]); // print("Hello World, my Name is ");
print(char[]); // print(davepermen);
print(char[]); // print(" I'm ");
print(int);    // print(19);
print(char[]); // print(" and i life at ");
print(vec3);   // print(position);

and if this is too implicit, possibly we have to call the function more like this:

print..("Hello World, my Name is ",davepermen," I'm ",19," and i life at ",position); // note the two dots..

or even

print("Hello World, my Name is "..davepermen.." I'm "..19.." and i life at "..position); // hm, a real stream-chain operator

how to mix that with oo? dunno.. :|

anyways.. lot to think about.. how to make the language flexible extendable without issues for the compiler?

one word, walter: shit

:D at least you see my points as well.. now lets find some way to work this out. and then, syntax-sugar it as much as possible:D

In article <btlq6k$2obr$1@digitaldaemon.com>, Walter says...
>
>
>"davepermen" <davepermen_member@pathlink.com> wrote in message news:bthndh$2jdb$1@digitaldaemon.com...
>> i do understand that. but you simply can't overload your prefered operator
>for
>> ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.
>> free overloadable functions give the ability to add overloads to your
>stream
>> without any rewriting of stream or type.
>>
>> THAT is why i want free operators. they are the way operators behave, and
>they
>> are the only way to make streams fast extendable and type save. and FAST. everyone cries that they have to be faster than the c++ streams. believe
>me they
>> can be hell fast. and i can for sure overload all sort of types for my
>stdout
>> class and then write stdout << a << b << c; but this is nost scalable.
>>
>> a library ALWAYS has to provide features a user can use for ANY situation.
>that
>> means he has to have a nice plugin-interface. overloadable free operators
>are a
>> GREAT plugin-interface for streams.
>
>I understand your point. But there's got to be a better way than ADL.
>
>

Ben Hinkle wrote:
> Even if you import foo and bar?? I thought that was the whole point of
> import - to bring symbols into the current scope.
> Is anyone really suggesting that this mechanism should work *without*
> requiring import statements?

Import doesn't bring a module into your scope. It only adds it to module search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module.

We had been already arguing with Walter about that. And that this approach is, well, at least somewhat "surprising".

If you make overloads of one function in one module, and some in another, and import both in yours, only one set of overloads should work. The other should be acessible through the module name point notation only.

>>They are not. That's the reason cross-module overloads don't work. They
>>don't work for normal functions. And for operators, it is simply bloody
>>forbidden to use module scope, because it would not make the problem
>>better, just worse!

> Again, that is what "import" is for.

Again, you don't seem to listen, nor to read!

-eye.