www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mixins don't quite cut it...

reply Hauke Duden <H.NS.Duden gmx.net> writes:
So here I was and though mixins were powerful enough to help me 
circumvent some of D's other shortcomings. More specifically, I thought 
it would be possible to make the missing default values for function 
arguments a little less painful.

It seems that I was wrong :(. Or maybe I just didn't use them in the 
right way (I fully admit that I don't completely understand the import 
mechanism that is used). Any hints would be appreciated.

I tried to use a mixin that implements the "dummy functions" you need if 
you want to have default values for function arguments. This would be 
especially useful for interfaces, since otherwise you'd have to write 
these dummies for each and every implementation of the interface. I also 
wanted to use a mixin to provide a default implementation for some of 
the "real" functions of the interface. But this combination seems to be 
explosive:

Here's the code I tried to compile:

interface IFoo
{
	void foo(int i);
	void foo(int i,int j);
}

template FooDefaults()
{
	void foo(int i)
	{
		this.foo(i,0);
	}	
}

template FooImpl()
{
	void foo(int i,int j)
	{
	}
}


class Foo : IFoo
{
	mixin FooDefaults;
	mixin FooImpl;	
}


Unfortunately this doesn't compile:

mixinbug.d(9): function foo conflicts with FooImpl!().foo at mixinbug.d(17)
mixinbug.d(11): function foo (int i) does not match argument types (int,int)
mixinbug.d(11): Error: expected 1 arguments, not 2


Why do the two mixins conflict? I sure hope that it is not because they 
have the same name, because obviously the signature is completely different.

This takes a lot of usefulness from the mixins for me. :(


Hauke
May 29 2004
parent reply "Walter" <newshound digitalmars.com> writes:
Think of mixins like imports. Functions imported from different modules do
not overload against each other, they conflict. This is what you're seeing
here. You can overload a function from one scope into another using an
alias:

interface IFoo
{
    void foo(int i);
    void foo(int i,int j);
}

template FooDefaults()
{
    void foo(int i)
    {
 this.foo(i,0);
    }
}

template FooImpl()
{
    void foo(int i,int j)
    {
    }
}


class Foo : IFoo
{
    mixin FooDefaults F1;
    alias F1.foo foo;

    mixin FooImpl F2;
    alias F2.foo foo;
}
May 29 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:

 Think of mixins like imports. Functions imported from different modules do
 not overload against each other, they conflict. This is what you're seeing
 here. You can overload a function from one scope into another using an
 alias:

Hmmm. Ok, now I understand why this happens. I remember trying to persuade you to change this shortcoming for modules a while back ;). Unfortunately the alias workaround isn't much use to me since that would mean I'd still have to write one statement per dummy function :(. I don't know what it is with D and me. I like the overall concepts a lot but every time I think I should give it a new chance and try to implement something I end up running against another wall in the language design. And to make it worse, it is always a "small" design decision. For example, I like the idea of modules, but D becomes unusable for big projects because a module has to be in a single file. I also like mixins but you cannot use them to "mix" yourself an implementation for an interface. I like the fact that it has operator overloading, but oh, the operators for a class all have to be in the same module, making it impossible to add support for new "argument types" of stream classes. I like that it has a bool type but unfortunately and in contrast to one of the goals of this type the bool in D is actually slower than an int and it can be implicitly converted to integers. It seems that my way of programming (often library development with interfaces for abstraction from the implementation, plus lots of default function arguments) is just not compatible with D. At least not the D that we see now. You keep making it better, but I doubt that I'll switch before at least some of the remaining warts are removed. Right now C++ is still better for most of the things I do. Hauke
May 29 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
 I also like mixins but you cannot use them to "mix" yourself an
 implementation for an interface. 

Can you explain this more? Is is the overloading? The following example seems to work fine: interface A { void a(); } template B() { void a(){printf("B.a\n");} } class C : A { mixin B; } int main() { C c = new C; c.a(); return 0;}
May 29 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Ben Hinkle wrote:
I also like mixins but you cannot use them to "mix" yourself an
implementation for an interface. 

Can you explain this more? Is is the overloading? The following example seems to work fine: interface A { void a(); } template B() { void a(){printf("B.a\n");} } class C : A { mixin B; } int main() { C c = new C; c.a(); return 0;}

The problem I'm having is that I would like to have one mixin with dummy functions that emulate default values (because these dummies are always the same for all implementations) and another two or more mixins that provide different default implementations for the functions that provide the real functionality. But since the dummy functions have the same name (but a different signature) as the functions in the implementation mixins these two mixins cannot be mixed into the same class. Realworld use: I'd like to provide "building blocks" for interface implementations that allow the implementing class to select alternative partial implementations with different properties and mix them all together to form the full implementation. Here's an example: interface IFoo { void foo(int i); void foo(int i,int j); } template FooDefaults() { void foo(int i) { this.foo(i,0); //always the same for all impls } } template FooFastImpl() { void foo(int i,int j) { //fast implementation with high memory cost } } template FooSmallImpl() { void foo(int i,int j) { //slow implementation that needs little memory } } class MyFoo : IFoo { mixin FooDefaults; //always the same mixin FooFastImpl; //we want the fast alternative } The problem stems from the fact that FooDefaults defines dummies for almost all function names in IFoo. So this makes it impossible to use a mixin to implement the real functions. Of course, this problem wouldn't occur in this particular case if D would support default values for function arguments. It is a good example how the need to "hack" to get default arguments without copying huge chunks of code causes problems in other areas. Hauke
May 29 2004
parent reply David L. Davis <SpottedTiger yahoo.com> writes:
In article <c9b26g$i5u$1 digitaldaemon.com>, Hauke Duden says...
Ben Hinkle wrote:
...

The problem stems from the fact that FooDefaults defines dummies for 
almost all function names in IFoo. So this makes it impossible to use a 
mixin to implement the real functions.

Of course, this problem wouldn't occur in this particular case if D 
would support default values for function arguments. It is a good 
example how the need to "hack" to get default arguments without copying 
huge chunks of code causes problems in other areas.

Hauke

I agree, I too think that "D" should "support default values for function arguments." I use then all the time in Visual Basic 6.0, and I can't image not having them in a new modern programming langauge. Course when I program in "C" I don't have this functionally, but when I recently started taking a closer look at "D", I've been poking around in the "D" html help information looking for this...now I know why I haven't found it yet. :( (I haven't looked at C++ in a long while, but doesn't it have default values for function parameters?)
May 29 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
David L. Davis wrote:
 In article <c9b26g$i5u$1 digitaldaemon.com>, Hauke Duden says...
 
Ben Hinkle wrote:
...

The problem stems from the fact that FooDefaults defines dummies for 
almost all function names in IFoo. So this makes it impossible to use a 
mixin to implement the real functions.

Of course, this problem wouldn't occur in this particular case if D 
would support default values for function arguments. It is a good 
example how the need to "hack" to get default arguments without copying 
huge chunks of code causes problems in other areas.

Hauke

I agree, I too think that "D" should "support default values for function arguments." I use then all the time in Visual Basic 6.0, and I can't image not having them in a new modern programming langauge. Course when I program in "C" I don't have this functionally, but when I recently started taking a closer look at "D", I've been poking around in the "D" html help information looking for this...now I know why I haven't found it yet. :( (I haven't looked at C++ in a long while, but doesn't it have default values for function parameters?)

If you're talking about doing something like this... void foo(int x, int y = 3) { ... } You can emulate it with something like this... void foo(int x, int y) { ... } void foo(int x) { foo(x, 3); } I'd prefer to do it directly, too, but Walter has some concerns. I've collected some previous threads here (in case you want to review the previous discussions): http://www.wikiservice.at/d/wiki.cgi?FeatureRequestList/DefaultArguments -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
May 30 2004
next sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c9d89g$f58$1 digitaldaemon.com>, J C Calvarese says...
I'd prefer to do it directly, too, but Walter has some concerns. I've 
collected some previous threads here (in case you want to review the 
previous discussions):

What I don't understand, is this. If it's "good" for the compiler to allow:
       void f() { f(0); }
       void f(int n) { /*stuff*/ }

and "bad" for the compiler to allow:
       void f(int n=0) { /*stuff*/ }

Then why can't the compiler simply rewrite the latter as the former before trying to figure out the rules? Just consider it more of that syntactic sugar. I also concur with the person on wiki who suggested that all functions with default arguments be implicitly final. (Or even explicitly, if you really want to make a point). Overloading is common, and default arguments are common, but overloading and default arguments at the same time are rare enough that this is unlikely to be much of a problem. Arcane Jill
May 30 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Arcane Jill wrote:
 I also concur with the person on wiki who suggested that all functions with
 default arguments be implicitly final. (Or even explicitly, if you really want
 to make a point). Overloading is common, and default arguments are common, but
 overloading and default arguments at the same time are rare enough that this is
 unlikely to be much of a problem.

I completely disagree! Default arguments are even more needed for interfaces than for normal classes, since without them EVERY implementation has to include all the dummy functions. A better rule would be that all overloads simply have to define the same default arguments. The default shouldn't change depending on the context in which the function is called anyway. Hauke
May 30 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 30 May 2004 20:54:10 +0200, Hauke Duden <H.NS.Duden gmx.net> wrote:
 Arcane Jill wrote:
 I also concur with the person on wiki who suggested that all functions 
 with
 default arguments be implicitly final. (Or even explicitly, if you 
 really want
 to make a point). Overloading is common, and default arguments are 
 common, but
 overloading and default arguments at the same time are rare enough that 
 this is
 unlikely to be much of a problem.

I completely disagree! Default arguments are even more needed for interfaces than for normal classes, since without them EVERY implementation has to include all the dummy functions. A better rule would be that all overloads simply have to define the same default arguments. The default shouldn't change depending on the context in which the function is called anyway.

Why not say: "Overloads must specify a default value for every parameter in the overloaded function(s) that have default value(s)." So if you have foo(int a=0, int b) and foo(int a, int b=6) you must specify defaults for both a and b i.e. foo(int a=1, int b=2) Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 31 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Regan Heath wrote:
 On Sun, 30 May 2004 20:54:10 +0200, Hauke Duden <H.NS.Duden gmx.net> wrote:
 
 Arcane Jill wrote:

 I also concur with the person on wiki who suggested that all 
 functions with
 default arguments be implicitly final. (Or even explicitly, if you 
 really want
 to make a point). Overloading is common, and default arguments are 
 common, but
 overloading and default arguments at the same time are rare enough 
 that this is
 unlikely to be much of a problem.

I completely disagree! Default arguments are even more needed for interfaces than for normal classes, since without them EVERY implementation has to include all the dummy functions. A better rule would be that all overloads simply have to define the same default arguments. The default shouldn't change depending on the context in which the function is called anyway.

Why not say: "Overloads must specify a default value for every parameter in the overloaded function(s) that have default value(s)." So if you have foo(int a=0, int b) and foo(int a, int b=6) you must specify defaults for both a and b i.e. foo(int a=1, int b=2)

The overload must not change the default values, otherwise you get lots of weirdness, like the function call behaving differently depending on the type of the object reference (i.e. a call with a base class reference would have different defaults than the same call with a subclass reference). It is also useless because defaults are not arbitrary values, so they don't change. I'm more and more convinced that the best solution is to have the simple rule: All overloads must specify exactly the same defaults as the original method. That way all cases are handled well, there is no ambiguity, it is easy to read and easy to understand. Hauke
Jun 01 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 01 Jun 2004 11:01:23 +0200, Hauke Duden <H.NS.Duden gmx.net> wrote:
 Regan Heath wrote:
 On Sun, 30 May 2004 20:54:10 +0200, Hauke Duden <H.NS.Duden gmx.net> 
 wrote:

 Arcane Jill wrote:

 I also concur with the person on wiki who suggested that all 
 functions with
 default arguments be implicitly final. (Or even explicitly, if you 
 really want
 to make a point). Overloading is common, and default arguments are 
 common, but
 overloading and default arguments at the same time are rare enough 
 that this is
 unlikely to be much of a problem.

I completely disagree! Default arguments are even more needed for interfaces than for normal classes, since without them EVERY implementation has to include all the dummy functions. A better rule would be that all overloads simply have to define the same default arguments. The default shouldn't change depending on the context in which the function is called anyway.

Why not say: "Overloads must specify a default value for every parameter in the overloaded function(s) that have default value(s)." So if you have foo(int a=0, int b) and foo(int a, int b=6) you must specify defaults for both a and b i.e. foo(int a=1, int b=2)

The overload must not change the default values, otherwise you get lots of weirdness, like the function call behaving differently depending on the type of the object reference (i.e. a call with a base class reference would have different defaults than the same call with a subclass reference). It is also useless because defaults are not arbitrary values, so they don't change.

You're stating/assuming the default never changes, even in derived classes. Why does that have to be the case? What is wrong with have a default initial size in a storage class, deriving a specialised version of that storage class from it and setting a different default initial size?
 I'm more and more convinced that the best solution is to have the simple 
 rule:
 All overloads must specify exactly the same defaults as the original 
 method.

 That way all cases are handled well, there is no ambiguity, it is easy 
 to read and easy to understand.

 Hauke

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 01 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Arcane Jill wrote:
 I also concur with the person on wiki who suggested that all functions with
 default arguments be implicitly final. (Or even explicitly, if you really want
 to make a point). Overloading is common, and default arguments are common, but
 overloading and default arguments at the same time are rare enough that this is
 unlikely to be much of a problem.

I would rather it be illegal to provide defaults on any method that is an override, including interface implementations. (by extension, then, interfaces would be allowed to provide defaults) -- andy
May 30 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Andy Friesen wrote:
 Arcane Jill wrote:
 
 I also concur with the person on wiki who suggested that all functions 
 with
 default arguments be implicitly final. (Or even explicitly, if you 
 really want
 to make a point). Overloading is common, and default arguments are 
 common, but
 overloading and default arguments at the same time are rare enough 
 that this is
 unlikely to be much of a problem.

I would rather it be illegal to provide defaults on any method that is an override, including interface implementations. (by extension, then, interfaces would be allowed to provide defaults)

Just to make sure I understand: you mean the override must not specify defaults because it will implicitly inherit the ones from the original defintion, correct? I would prefer that the defaults have to be explicit, but always the same as the original ones. That way they can be seen without having to look at any base classes. Also, your system has another problem: what if two interfaces define the same function with different defaults? Then there are two "original" definitions, so this needs to be handled specifically. If you require the overloads to have the same defaults then this case is automatically handled, because no overload can have the same defaults as both the methods it overrides. I.e. it is not possible to implement both interfaces in the same object, which is the only solution I can see. It would be the same as if the interfaces defined methods with the same parameter lists but different return values. Hauke
May 30 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Hauke Duden wrote:
 Andy Friesen wrote:
 
 I would rather it be illegal to provide defaults on any method that is 
 an override, including interface implementations. (by extension, then, 
 interfaces would be allowed to provide defaults)

Just to make sure I understand: you mean the override must not specify defaults because it will implicitly inherit the ones from the original defintion, correct?

Exactly.
 I would prefer that the defaults have to be explicit, but always the 
 same as the original ones. That way they can be seen without having to 
 look at any base classes.

My first instinct is to agree that a bit of syntactic salt would be a good thing, but, on second thought, it means duplication, which is Very Bad.
 Also, your system has another problem: what if two interfaces define the 
 same function with different defaults? Then there are two "original" 
 definitions, so this needs to be handled specifically.

In such a case, the two functions are distinct, even if they happen to have the same name. There is no conflict. -- andy
May 30 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Andy Friesen wrote:
  >> I would prefer that the defaults have to be explicit, but always the
 same as the original ones. That way they can be seen without having to 
 look at any base classes.

My first instinct is to agree that a bit of syntactic salt would be a good thing, but, on second thought, it means duplication, which is Very Bad.

No, duplication is good if the "other copy" is in a different class. Otherwise, when you see a method foo(int a,int b) in a class, how do you know how you can call it? Is there a default value for a or b? What is it? To find out you'd have to look in all base classes and see if they contain a function foo(int,int). That is what I consider bad.
 Also, your system has another problem: what if two interfaces define 
 the same function with different defaults? Then there are two 
 "original" definitions, so this needs to be handled specifically.

In such a case, the two functions are distinct, even if they happen to have the same name. There is no conflict.

Urgh!!! So what happens if you have foo(int a=0) and foo(int a=5)? Which default value is chosen when someone calls foo()? And how'd you overload these two distinct functions without duplicating the default values? How do you indicate which one to overload? I don't think this can work. I think the only sensible solution is that different defaults are a conflict and that all overloads must specify the same defaults as the base class function they are overloading. It is easy to read, immediately understandable, typos are caught at compile time and function calling is unambiguous. Hauke
May 30 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Hauke Duden wrote:

 ... when you see a method
 
 foo(int a,int b)
 
 in a class, how do you know how you can call it? Is there a default 
 value for a or b? What is it?
 
 To find out you'd have to look in all base classes and see if they 
 contain a function foo(int,int). That is what I consider bad.

In almost all cases, this would be the direct parent, the uppermost base class, or an interface. Hopefully, it would almost always be an interface or abstract class. (implementation inheritance is scary)
 Also, your system has another problem: what if two interfaces define 
 the same function with different defaults? Then there are two 
 "original" definitions, so this needs to be handled specifically.

In such a case, the two functions are distinct, even if they happen to have the same name. There is no conflict.

Urgh!!! So what happens if you have foo(int a=0) and foo(int a=5)? Which default value is chosen when someone calls foo()?

Waaait a second. I had no idea that two interfaces could 'overlap' in this way. Since foo() is the same method for both interfaces, the defaults should necessarily coincide. If they don't, it's probably a bug anyway. (even if it isn't, it sure looks like one)
 I think the only sensible solution is that different defaults are a 
 conflict and that all overloads must specify the same defaults as the 
 base class function they are overloading. It is easy to read, 
 immediately understandable, typos are caught at compile time and 
 function calling is unambiguous.

It has real potential to be a maintenance nightmare if a default has to change, however. I think I see why Walter wanted to leave these out. :) -- andy
May 30 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Andy Friesen wrote:
 Hauke Duden wrote:
 
 ... when you see a method

 foo(int a,int b)

 in a class, how do you know how you can call it? Is there a default 
 value for a or b? What is it?

 To find out you'd have to look in all base classes and see if they 
 contain a function foo(int,int). That is what I consider bad.

In almost all cases, this would be the direct parent, the uppermost base class, or an interface.

How do you come to that conclusion? Inheritance hierarchies can be deep and new functions can be added at any level. Classes can also implement many interfaces. So you'd potentially have to look at many classes or interfaces!
 Also, your system has another problem: what if two interfaces define 
 the same function with different defaults? Then there are two 
 "original" definitions, so this needs to be handled specifically.

In such a case, the two functions are distinct, even if they happen to have the same name. There is no conflict.

Urgh!!! So what happens if you have foo(int a=0) and foo(int a=5)? Which default value is chosen when someone calls foo()?

Waaait a second. I had no idea that two interfaces could 'overlap' in this way.

Sure. Otherwise you could never implement an interface that inherits from an interface a base class has already implemented.
 Since foo() is the same method for both interfaces, the defaults should 
 necessarily coincide.  If they don't, it's probably a bug anyway. (even 
 if it isn't, it sure looks like one)

I agree.
 I think the only sensible solution is that different defaults are a 
 conflict and that all overloads must specify the same defaults as the 
 base class function they are overloading. It is easy to read, 
 immediately understandable, typos are caught at compile time and 
 function calling is unambiguous.

It has real potential to be a maintenance nightmare if a default has to change, however.

Well, I think if you ever need to change a default then it IS already a maintenance nightmare. Because all the calling code will have been written with the old default you'd have to review every piece of code where the function is called to see if it still applies to the new one. Going through all base classes doesn't add much to that. Anyway, in all my years of programming C++, I don't remember ever changing a default value. The default is not any arbitrary value, it is what you need to pass to the function if you don't really want to USE the parameter. That kind of value doesn't change as long as the function's task doesn't change. Hauke
May 30 2004
parent Andy Friesen <andy ikagames.com> writes:
Hauke Duden wrote:
 Andy Friesen wrote:
 
 In almost all cases, this would be the direct parent, the uppermost 
 base class, or an interface.  

How do you come to that conclusion? Inheritance hierarchies can be deep and new functions can be added at any level. Classes can also implement many interfaces. So you'd potentially have to look at many classes or interfaces!

I meant that having such a heirarchy is a bad sign in and of itself, but I'm not so sure now. I myself tend to avoid implementation inheritance like the plague, leading to relatively flat object heirarchies. It's certainly the most effective way for *me* to think, but I shouldn't be so quick to assume it's the best approach for every problem.
 I think if you ever need to change a default then it IS already a 
 maintenance nightmare. Because all the calling code will have been 
 written with the old default you'd have to review every piece of code 
 where the function is called to see if it still applies to the new one. 
 Going through all base classes doesn't add much to that.

Come to think of it, it's no more or less of a hassle than any other change one might make to an interface. blah. All this thinking is leading me back to the conclusion that overloaded methods solve the problem better, if a tad more verbosely. :) -- andy
May 31 2004
prev sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
*) Ben Hinkle: ... The problem stems from the fact that FooDefaults defines
dummies for almost all function names in IFoo. So this makes it impossible to
use a mixin to implement the real functions. Of course, this problem wouldn't
occur in this particular case if D would support default values for function
arguments. It is a good example how the need to "hack" to get default arguments
without copying huge chunks of code causes problems in other areas.
------------

*) David L. Davis [reply to Ben]: I agree, I too think that "D" should "support
default values for function arguments." I use then all the time in Visual Basic
6.0, and I can't image not having them in a new modern programming langauge.
Course when I program in "C" I don't have this functionally, but when I recently
started taking a closer look at "D", I've been poking around in the "D" html
help information looking for this...now I know why I haven't found it yet. :( (I
haven't looked at C++ in a long while, but doesn't it have default values for
function parameters?)
------------

*) J C Calvarese [reply to David]: 
If you're talking about doing something like this...
void foo(int x, int y = 3) { ... }

You can emulate it with something like this...
void foo(int x, int y) { ... }
void foo(int x) { foo(x, 3); }

I'd prefer to do it directly, too, but Walter has some concerns. I've 
collected some previous threads here (in case you want to review the 
previous discussions):

http://www.wikiservice.at/d/wiki.cgi?FeatureRequestList/DefaultArguments

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/
------------

J C Calvarese: Thanks for the reply. I'll keep a note of the above emulation
approach in mind for current needs, but it does look like "D" will support
"default function arguments" directly in some future build. Below is a potion of
the thread, title: "Re: Mixins don't quite cut it..." dated: "Sun, 30 May 2004
10:45:08 -0700" where it looks like Walter has been listening to the forum about
this issue, and it sounds like to me that he's going to add "default function
arguments" to "D!" :)) If this is truly the case, then this is really "Great
News!" <g>

-----------
<default function arguments portion>

Hauke Duden:"I'm talking about DMD 0.91 here. The problem appears when you try
to have different mixins that provide functions with the same name but different
signatures. Again, the importing algorithm is the culprit. And the reason I
wanted to do this is to provide a mixin with the 'dummy' functions you need to
write to get default values for function arguments. This is all described in
more detail in my another of my posts:
digitalmars.D/2456"

Walter [reply to Hauke]:"Seeing the lengths people go to try to emulate default
function arguments makes it pretty obvious that I need to add it to the
language, I'd underestimated it."

</default function arguments portion>
-------------
May 30 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9arki$8uh$1 digitaldaemon.com...
 Walter wrote:

 Think of mixins like imports. Functions imported from different modules


 not overload against each other, they conflict. This is what you're


 here. You can overload a function from one scope into another using an
 alias:

Hmmm. Ok, now I understand why this happens. I remember trying to persuade you to change this shortcoming for modules a while back ;). Unfortunately the alias workaround isn't much use to me since that would mean I'd still have to write one statement per dummy function :(.

The reason that mixins are in a separate scope is so that, for more complex mixins, declarations in it can be 'overridden' in the mixed in scope.
 I don't know what it is with D and me. I like the overall concepts a lot
 but every time I think I should give it a new chance and try to
 implement something I end up running against another wall in the
 language design. And to make it worse, it is always a "small" design
 decision. For example, I like the idea of modules, but D becomes
 unusable for big projects because a module has to be in a single file.

Why are large files a problem? And why can't sub-parts of a large module be put in other modules?
 I
 also like mixins but you cannot use them to "mix" yourself an
 implementation for an interface.

Actually, you can and it does work. (It didn't work in the original implementation because of a, now fixed, compiler bug.)
 I like the fact that it has operator
 overloading, but oh, the operators for a class all have to be in the
 same module, making it impossible to add support for new "argument
 types" of stream classes.

Here I'll argue that stream I/O should not use operator overloading.
 I like that it has a bool type but
 unfortunately and in contrast to one of the goals of this type the bool
 in D is actually slower than an int

I don't think it is slower.
 and it can be implicitly converted
 to integers.

So it can, too, in C++, so that's not a reason to prefer C++ <g>.
 It seems that my way of programming (often library development with
 interfaces for abstraction from the implementation, plus lots of default
 function arguments) is just not compatible with D.

I'll argue here that I think function overloading is greatly overused, but I know I'm in a minority on that.
 At least not the D that we see now. You keep making it better, but I
 doubt that I'll switch before at least some of the remaining warts are
 removed. Right now C++ is still better for most of the things I do.

 Hauke

May 29 2004
next sibling parent reply hellcatv hotmail.com writes:
Why are large files a problem? And why can't sub-parts of a large module be
put in other modules?

For one thing the dmd.exe linker will crash if too many symbols or functions are defined in the file... or too many template instantiations (or I presume mixin instantions) are created in a file
May 29 2004
parent reply "Walter" <newshound digitalmars.com> writes:
<hellcatv hotmail.com> wrote in message
news:c9bhcc$16m4$1 digitaldaemon.com...
 For one thing the dmd.exe linker will crash if too many symbols or

 defined in the file... or too many template instantiations (or I presume

 instantions) are created in a file

I suspect that something else is going on there...
May 29 2004
parent reply hellcatv hotmail.com writes:
In article <c9bldd$1bs0$1 digitaldaemon.com>, Walter says...
<hellcatv hotmail.com> wrote in message
news:c9bhcc$16m4$1 digitaldaemon.com...
 For one thing the dmd.exe linker will crash if too many symbols or

 defined in the file... or too many template instantiations (or I presume

 instantions) are created in a file

I suspect that something else is going on there...

it's not just templates...and they all work using gdc http://graphics.stanford.edu/~danielrh/vec.d http://graphics.stanford.edu/~danielrh/manyfuncs.d http://graphics.stanford.edu/~danielrh/close.d http://graphics.stanford.edu/~danielrh/sclass.d on most of these setting version=DontCrash will cause the linker to succeed by truncating some functions (they're all pretty well empty functions causing these crashes)
May 29 2004
parent "Walter" <newshound digitalmars.com> writes:
It happens with the linker when there are more than 16,000 fixups in a
single .obj file. Apparently, it's most likely an overflow of a short in the
linker.
May 30 2004
prev sibling next sibling parent DemmeGod <me demmegod.com> writes:
 Why are large files a problem? And why can't sub-parts of a large module
 be put in other modules?

Unless a package access level was added since I last checked, that would expose subparts that one wouldn't necessarily want exposed.
May 30 2004
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
Walter wrote:
 
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 It seems that my way of programming (often library development with
 interfaces for abstraction from the implementation, plus lots of default
 function arguments) is just not compatible with D.

I'll argue here that I think function overloading is greatly overused, but I know I'm in a minority on that.

I share your opinion about overused function overloading, but I also share Haukes feelings of running against walls. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
May 30 2004
parent "Walter" <newshound digitalmars.com> writes:
"Helmut Leitner" <helmut.leitner wikiservice.at> wrote in message
news:40B98DF6.FEBF47C5 wikiservice.at...
 Walter wrote:
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 It seems that my way of programming (often library development with
 interfaces for abstraction from the implementation, plus lots of



 function arguments) is just not compatible with D.



 know I'm in a minority on that.

but I also share Haukes feelings of running against walls.

Which walls are yours?
May 30 2004
prev sibling next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
Think of mixins like imports. Functions imported from different modules
do
not overload against each other, they conflict. This is what you're
seeing
here. You can overload a function from one scope into another using an
alias:

Hmmm. Ok, now I understand why this happens. I remember trying to persuade you to change this shortcoming for modules a while back ;). Unfortunately the alias workaround isn't much use to me since that would mean I'd still have to write one statement per dummy function :(.

The reason that mixins are in a separate scope is so that, for more complex mixins, declarations in it can be 'overridden' in the mixed in scope.

Yes, that is a very important feature too. But that doesn't change the fact limits of the importing algorithm also limit the usefulness of mixins.
I don't know what it is with D and me. I like the overall concepts a lot
but every time I think I should give it a new chance and try to
implement something I end up running against another wall in the
language design. And to make it worse, it is always a "small" design
decision. For example, I like the idea of modules, but D becomes
unusable for big projects because a module has to be in a single file.

Why are large files a problem? And why can't sub-parts of a large module be put in other modules?

There was a big thread about this the other day called "Module with multiple files". The main problem is that when multiple classes need to collaborate with each other, i.e. if they need friend access, then you have to put them into the same file. With some kinds of class libraries that can mean huge files with tens of thousands of lines of code, which is impossible to manage efficiently when you have multiple programmers working on the classes at the same time. A "package" access level would help, as would the ability to split a module into multiple files (for example, the option to use a directory as a module). But the overloading problem also plays into it: if you want to break a module into sub-modules then all overloading functions must be in the same file. This can be counter-intuitive, as it is often more straightforward to put any global functions into the same file as the classes it takes as arguments.
I
also like mixins but you cannot use them to "mix" yourself an
implementation for an interface.

Actually, you can and it does work. (It didn't work in the original implementation because of a, now fixed, compiler bug.)

I'm talking about DMD 0.91 here. The problem appears when you try to have different mixins that provide functions with the same name but different signatures. Again, the importing algorithm is the culprit. And the reason I wanted to do this is to provide a mixin with the "dummy" functions you need to write to get default values for function arguments. This is all described in more detail in my another of my posts: digitalmars.D/2456
I like the fact that it has operator
overloading, but oh, the operators for a class all have to be in the
same module, making it impossible to add support for new "argument
types" of stream classes.

Here I'll argue that stream I/O should not use operator overloading.

It is the same if you use global functions, since they overload in the same way, so this kind of thing: class Stream; void store(Stream s,String x); <other file> void store(Stream s,MyClass c); doesn't work either. Because of this you cannot add support for, for example, storing new types to a stream class without using runtime polymorphy. And that is a problem because D also has structs which cannot implement interfaces, so you cannot add support for "being stored" to any struct whose base class you cannot control.
I like that it has a bool type but
unfortunately and in contrast to one of the goals of this type the bool
in D is actually slower than an int

I don't think it is slower.

You told me yourself. You said you use "int" as the return type for islower and isupper because having ==0, !=0 semantics usually takes two operations less than having ==0,==1 semantics (as you'd have with bool/bit).
and it can be implicitly converted
to integers.

So it can, too, in C++, so that's not a reason to prefer C++ <g>.

Yes, but C++ is my current language. Switching languages means a lot of work, so D has to offer compelling advantages. It fails to do so with the bool type.
It seems that my way of programming (often library development with
interfaces for abstraction from the implementation, plus lots of default
function arguments) is just not compatible with D.

I'll argue here that I think function overloading is greatly overused, but I know I'm in a minority on that.

Then you need to ask yourself whether you create the language just for yourself or also for the "majority". It is your decision of course, but if other people use lots of overloading and you want them to use your language ... I want to be honest here: most of the stuff I mentioned here is by itself not enough for me to "condemn" the language. Otherwise I wouldn't be posting here. But it adds up. One of the most important issues for me is still the lack of default values for function arguments. To give you an example, I recently wrote a String interface plus different implementations as a "tryout project" for D. That string interface has 48 "real" methods and 36 dummy methods to implement default values (almost all methods have one or two default arguments). So for each implementation you have to write almost twice as many methods as really necessary. My attempts to work around this limitation with mixins were the reason why I kept bumping into the mixin and overloading problems. Hauke
May 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9cguf$2hue$1 digitaldaemon.com...
 Why are large files a problem? And why can't sub-parts of a large module


 put in other modules?

multiple files". The main problem is that when multiple classes need to collaborate with each other, i.e. if they need friend access, then you have to put them into the same file. With some kinds of class libraries that can mean huge files with tens of thousands of lines of code, which is impossible to manage efficiently when you have multiple programmers working on the classes at the same time. A "package" access level would help, as would the ability to split a module into multiple files (for example, the option to use a directory as a module).

I'll go review the thread, but at the moment I have a hard time imagining why members should be private when they need to be accessed by tens of thousands of lines of other code. But the package level access sounds like a good feature to add.
 But the overloading problem also plays into it: if you want to break a
 module into sub-modules then all overloading functions must be in the
 same file. This can be counter-intuitive, as it is often more
 straightforward to put any global functions into the same file as the
 classes it takes as arguments.

One can overload functions from different import scopes using the 'alias' capability. I believe this explicit control over function overloading is better than C++ for handling very large programs - in C++ with its global overloading and ADL one can get really lost as to which functions are 'in play' for overloading.
I also like mixins but you cannot use them to "mix" yourself an
implementation for an interface.

Actually, you can and it does work. (It didn't work in the original implementation because of a, now fixed, compiler bug.)

I'm talking about DMD 0.91 here. The problem appears when you try to have different mixins that provide functions with the same name but different signatures. Again, the importing algorithm is the culprit. And the reason I wanted to do this is to provide a mixin with the "dummy" functions you need to write to get default values for function arguments. This is all described in more detail in my another of my posts: digitalmars.D/2456

Seeing the lengths people go to try to emulate default function arguments makes it pretty obvious that I need to add it to the language, I'd underestimated it.
 It is the same if you use global functions, since they overload in the
 same way, so this kind of thing:

 class Stream;
 void store(Stream s,String x);

 <other file>
 void store(Stream s,MyClass c);

 doesn't work either. Because of this you cannot add support for, for
 example, storing new types to a stream class without using runtime
 polymorphy. And that is a problem because D also has structs which
 cannot implement interfaces, so you cannot add support for "being
 stored" to any struct whose base class you cannot control.

There's got to be a better way <g>.
I like that it has a bool type but
unfortunately and in contrast to one of the goals of this type the bool
in D is actually slower than an int


You told me yourself. You said you use "int" as the return type for islower and isupper because having ==0, !=0 semantics usually takes two operations less than having ==0,==1 semantics (as you'd have with

That's to create a bool from an int. This overhead isn't there once it is a bool. I don't know of any conceivable implementation of bool (and that includes C++'s bool) that doesn't have this overhead in converting to a bool.
and it can be implicitly converted
to integers.

So it can, too, in C++, so that's not a reason to prefer C++ <g>.

Yes, but C++ is my current language. Switching languages means a lot of work, so D has to offer compelling advantages. It fails to do so with the bool type.

I have been surprised at the amount of controversy over a bool type (Matthew is solidly in your camp on this, too!). I recall many l-o-n-g threads in newsgroups over the semantics of bool to C years ago.
 I'll argue here that I think function overloading is greatly overused,


 know I'm in a minority on that.

Then you need to ask yourself whether you create the language just for yourself or also for the "majority". It is your decision of course, but if other people use lots of overloading and you want them to use your language ...

A good point. But also consider that I wouldn't have created this newsgroup if I wasn't interested in other peoples' views. D has grown and improved a lot based on feedback from the members here. But the risk D runs in trying to please everyone is becoming a mish-mash of conflicting, overlapping features.
 I want to be honest here: most of the stuff I mentioned here is by
 itself not enough for me to "condemn" the language. Otherwise I wouldn't
 be posting here. But it adds up.

I appreciate you taking the time to post your thoughts on it here.
 One of the most important issues for me is still the lack of default
 values for function arguments. To give you an example, I recently wrote
 a String interface plus different implementations as a "tryout project"
 for D. That string interface has 48 "real" methods and 36 dummy methods
 to implement default values (almost all methods have one or two default
 arguments). So for each implementation you have to write almost twice as
 many methods as really necessary.

 My attempts to work around this limitation with mixins were the reason
 why I kept bumping into the mixin and overloading problems.

 Hauke

May 30 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
There was a big thread about this the other day called "Module with
multiple files". The main problem is that when multiple classes need to
collaborate with each other, i.e. if they need friend access, then you
have to put them into the same file. With some kinds of class libraries
that can mean huge files with tens of thousands of lines of code, which
is impossible to manage efficiently when you have multiple programmers
working on the classes at the same time. A "package" access level would
help, as would the ability to split a module into multiple files (for
example, the option to use a directory as a module).

I'll go review the thread, but at the moment I have a hard time imagining why members should be private when they need to be accessed by tens of thousands of lines of other code. But the package level access sounds like a good feature to add.

The members are not really accessed by all the code, of course. Probably only in a couple of places. But the classes can each have a few thousand lines and if they need to access each other's private members then they all have to be in the same file. But if you really add package access this problem is solved. :)
But the overloading problem also plays into it: if you want to break a
module into sub-modules then all overloading functions must be in the
same file. This can be counter-intuitive, as it is often more
straightforward to put any global functions into the same file as the
classes it takes as arguments.

One can overload functions from different import scopes using the 'alias' capability. I believe this explicit control over function overloading is better than C++ for handling very large programs - in C++ with its global overloading and ADL one can get really lost as to which functions are 'in play' for overloading.

Well, when you use alias you always have to manually "prepare" the aliases for all overloaded functions you want to use. That makes it impossible to use two modules in combination by simply importing them both. Having said that, this really is one of the less important points for me. If the function overloading hadn't played into the mixin stuff I tried to pull off to implement default function arguments I wouldn't have mentioned it. As I said in another post, I usually use lots of interfaces, so runtime polymorphy works well enough for me in most situations.
I also like mixins but you cannot use them to "mix" yourself an
implementation for an interface.

Actually, you can and it does work. (It didn't work in the original implementation because of a, now fixed, compiler bug.)

I'm talking about DMD 0.91 here. The problem appears when you try to have different mixins that provide functions with the same name but different signatures. Again, the importing algorithm is the culprit. And the reason I wanted to do this is to provide a mixin with the "dummy" functions you need to write to get default values for function arguments. This is all described in more detail in my another of my posts: digitalmars.D/2456

Seeing the lengths people go to try to emulate default function arguments makes it pretty obvious that I need to add it to the language, I'd underestimated it.

Yay! If you do that D will immediately climb a lot higher on my language ranking ladder ;).
I like that it has a bool type but
unfortunately and in contrast to one of the goals of this type the bool
in D is actually slower than an int

I don't think it is slower.

You told me yourself. You said you use "int" as the return type for islower and isupper because having ==0, !=0 semantics usually takes two operations less than having ==0,==1 semantics (as you'd have with

bool/bit). That's to create a bool from an int. This overhead isn't there once it is a bool. I don't know of any conceivable implementation of bool (and that includes C++'s bool) that doesn't have this overhead in converting to a bool.

If a bool is simply a 32 bit value where 0 means false and !=0 means true then no conversion is necessary. Of course, there is some additional overhead when comparing two bool variables because they could both be true but have different values. But in my experience bool variables are very rarely compared to each other. Most of the time they are set to true or false or their true-ness is checked. There is no additional overhead for this. In fact, I believe such a bool allows the compiler to do additional optimizations, like the one you did manually with "islower". Only when the bool is explicitly converted to an int should the compiler perform the conversion !=0 => 1. I think such a bool as a distinct type without implicit conversions to and from integers would be the best possible way to do it.
and it can be implicitly converted
to integers.

So it can, too, in C++, so that's not a reason to prefer C++ <g>.

Yes, but C++ is my current language. Switching languages means a lot of work, so D has to offer compelling advantages. It fails to do so with the bool type.

I have been surprised at the amount of controversy over a bool type (Matthew is solidly in your camp on this, too!). I recall many l-o-n-g threads in newsgroups over the semantics of bool to C years ago.

So why are you surprised? :) I never encountered any situation where I needed to use a bool as an integer in pure C++ or JAVA code. The only thing that comes close is when interfacing with C code that expects an int instead of a bool. But that is mostly a problem of C++ because it is source code compatible with C. D has the opportunity to break with this, since it only needs binary compatibility with C.
I'll argue here that I think function overloading is greatly overused,


but I
know I'm in a minority on that.

Then you need to ask yourself whether you create the language just for yourself or also for the "majority". It is your decision of course, but if other people use lots of overloading and you want them to use your language ...

A good point. But also consider that I wouldn't have created this newsgroup if I wasn't interested in other peoples' views. D has grown and improved a lot based on feedback from the members here. But the risk D runs in trying to please everyone is becoming a mish-mash of conflicting, overlapping features.

I know and I am constantly surprised when you release a new DMD version and a lot of NG ideas are in there. I also realize that you need to try work through all the suggestions to see which features are REALLY needed by many people. But sometimes it seems that there are lots of people in the NG who all agree that something should be changed and there is no comment from you anywhere to be seen. Which doesn't mean that you don't listen, of course, because a month later this feature may very well be in the language. Or it may not because you have never had a problem with it yourself (see switch). Just to avoid misunderstandings: I believe every language should be designed by a single individual, since the compromises you get with design groups are often worse than the simple bad decisions a single person can make. I think your model of "eaves-dropping emperor" is really one of the better ones. But sometimes I wish you'd at least give some feedback when you have been convinced of something, so that we can stop and do something more productive :). A page of features that are on your todo list for a future version of DMD would be great. Hauke
May 30 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9d9v1$hdd$1 digitaldaemon.com...
 Walter wrote:
 One can overload functions from different import scopes using the


 capability. I believe this explicit control over function overloading is
 better than C++ for handling very large programs - in C++ with its


 overloading and ADL one can get really lost as to which functions are


 play' for overloading.

aliases for all overloaded functions you want to use. That makes it impossible to use two modules in combination by simply importing them

No, you just need to do one alias per imported name. Not one for each overload of each function. The alias pulls in all the functions of the same name.
 That's to create a bool from an int. This overhead isn't there once it


 bool. I don't know of any conceivable implementation of bool (and that
 includes C++'s bool) that doesn't have this overhead in converting to a
 bool.

true then no conversion is necessary.

Then just use an int. I just don't see what the problem is.
 But in my experience bool variables are very rarely compared to each
 other. Most of the time they are set to true or false or their true-ness
 is checked. There is no additional overhead for this.

And there is none in D.
 In fact, I believe such a bool allows the compiler to do additional
 optimizations, like the one you did manually with "islower". Only when
 the bool is explicitly converted to an int should the compiler perform
 the conversion !=0 => 1.

 I think such a bool as a distinct type without implicit conversions to
 and from integers would be the best possible way to do it.

It just doesn't set well with me that two values of a type can compare 'equal' yet contain entirely different bit patterns.
 I have been surprised at the amount of controversy over a bool type


 is solidly in your camp on this, too!). I recall many l-o-n-g threads in
 newsgroups over the semantics of bool to C years ago.

So why are you surprised? :)

I was surprised then, too. It's just much ado over next-to-nothing. (I argue about this with Matthew, too <g>.) One thing that is clear, though, is that there's no agreement at all.
 I never encountered any situation where I needed to use a bool as an
 integer in pure C++ or JAVA code. The only thing that comes close is
 when interfacing with C code that expects an int instead of a bool. But
 that is mostly a problem of C++ because it is source code compatible
 with C. D has the opportunity to break with this, since it only needs
 binary compatibility with C.

bool has been added to both C and C++, so if there was an obvious semantic meaning for it, such would have been chosen. But there was no consensus on what the 'obvious' semantics should be. People continue to fruitlessly argue about it. I'd rather move on <g>.
 A good point. But also consider that I wouldn't have created this


 if I wasn't interested in other peoples' views. D has grown and improved


 lot based on feedback from the members here. But the risk D runs in


 to please everyone is becoming a mish-mash of conflicting, overlapping
 features.

and a lot of NG ideas are in there. I also realize that you need to try work through all the suggestions to see which features are REALLY needed by many people. But sometimes it seems that there are lots of people in the NG who all agree that something should be changed and there is no comment from you anywhere to be seen. Which doesn't mean that you don't listen, of course, because a month later this feature may very well be in the language. Or it may not because you have never had a problem with it yourself (see switch).

The problem is I'm a thousand or two messages behind in reading the n.g. Even when I do post replies, that frequently inspires a whole ream of new postings. So the more I read and post, the further I get behind. I'm currently trying to wrap up reading the January postings. I'm not complaining, however, since the huge volume of messages is a wonderful sign of the health of the D community!
 Just to avoid misunderstandings: I believe every language should be
 designed by a single individual, since the compromises you get with
 design groups are often worse than the simple bad decisions a single
 person can make.

Design-by-committee suffers from the "vote for my feature and I'll vote for yours" madness. And it still is no guarantee that wretched misfeatures won't get in the language, I submit C++'s 'export' as the canonical example <g>. That said, there is still a time and a place for a standards committee for a language, but that is after it is designed and all major features are in place.
 I think your model of "eaves-dropping emperor" is really one of the
 better ones. But sometimes I wish you'd at least give some feedback when
 you have been convinced of something, so that we can stop and do
 something more productive :). A page of features that are on your todo
 list for a future version of DMD would be great.

I keep thinking I'm done with 1.0 features <g>.
May 30 2004
next sibling parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <knud NetRunner.all-technology.com> writes:
 A good point. But also consider that I wouldn't have created this


 if I wasn't interested in other peoples' views. D has grown and improved


 lot based on feedback from the members here. But the risk D runs in


 to please everyone is becoming a mish-mash of conflicting, overlapping
 features.

and a lot of NG ideas are in there. I also realize that you need to try work through all the suggestions to see which features are REALLY needed by many people. But sometimes it seems that there are lots of people in the NG who all agree that something should be changed and there is no comment from you anywhere to be seen. Which doesn't mean that you don't listen, of course, because a month later this feature may very well be in the language. Or it may not because you have never had a problem with it yourself (see switch).

The problem is I'm a thousand or two messages behind in reading the n.g. Even when I do post replies, that frequently inspires a whole ream of new postings. So the more I read and post, the further I get behind. I'm currently trying to wrap up reading the January postings. I'm not complaining, however, since the huge volume of messages is a wonderful sign of the health of the D community!
 Just to avoid misunderstandings: I believe every language should be
 designed by a single individual, since the compromises you get with
 design groups are often worse than the simple bad decisions a single
 person can make.

Design-by-committee suffers from the "vote for my feature and I'll vote for yours" madness. And it still is no guarantee that wretched misfeatures won't get in the language, I submit C++'s 'export' as the canonical example <g>. That said, there is still a time and a place for a standards committee for a language, but that is after it is designed and all major features are in place.

If not special care at taken the intelligence of a group is often the average of its members. To solve this I have created what I call an eigenpoll. http://all-technology.com/eigenpolls/ If you like I will make one for D suggestions. Knud
May 30 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Knud Sørensen wrote:
 If not special care at taken the intelligence of a group 
 is often the average of its members.

One of my favorite authors (Terry Pratchett) wrote that "the IQ of a mob is the IQ of its dumbest member divided by the number of participants". It is not quite the same for academic working groups, but there is a similar tendency ;). Hauke
May 30 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
If a bool is simply a 32 bit value where 0 means false and !=0 means
true then no conversion is necessary.

Then just use an int. I just don't see what the problem is.

Because int and bool are completely different types. True bools prevent errors, like the often seen newbie problem "while(x=7)". That would not be possible if "while" required a true boolean.
But in my experience bool variables are very rarely compared to each
other. Most of the time they are set to true or false or their true-ness
is checked. There is no additional overhead for this.

And there is none in D.

Well if there is none then why don't you use bool for islower? It clearly returns a boolean value (true or false), yet you use int because using bool/bit would be slower. If there was a real boolean type then the compiler would have the freedom of doing such optimizations implicitly by just considering any nonzero value as true.
 The problem is I'm a thousand or two messages behind in reading the n.g.
 Even when I do post replies, that frequently inspires a whole ream of new
 postings. So the more I read and post, the further I get behind. I'm
 currently trying to wrap up reading the January postings. I'm not
 complaining, however, since the huge volume of messages is a wonderful sign
 of the health of the D community!

Would it help if volunteers posted summaries of dead threads? Presenting all arguments and counter-arguments in a condensed manner? Hauke
May 30 2004
parent "Walter" <newshound digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:c9dm9m$120g$1 digitaldaemon.com...
 The problem is I'm a thousand or two messages behind in reading the n.g.
 Even when I do post replies, that frequently inspires a whole ream of


 postings. So the more I read and post, the further I get behind. I'm
 currently trying to wrap up reading the January postings. I'm not
 complaining, however, since the huge volume of messages is a wonderful


 of the health of the D community!

Would it help if volunteers posted summaries of dead threads? Presenting all arguments and counter-arguments in a condensed manner?

I think you'll find that's more than a full time job <g>.
May 30 2004
prev sibling next sibling parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
This reply will make a lot of people really really happy!
Walter is thinking about package level acces and default
parameters!

:) :) :)

"Walter" <newshound digitalmars.com> wrote in message
news:c9d6pi$d0l$1 digitaldaemon.com...
 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:c9cguf$2hue$1 digitaldaemon.com...
 Why are large files a problem? And why can't sub-parts of a large



 be
 put in other modules?

multiple files". The main problem is that when multiple classes need to collaborate with each other, i.e. if they need friend access, then you have to put them into the same file. With some kinds of class libraries that can mean huge files with tens of thousands of lines of code, which is impossible to manage efficiently when you have multiple programmers working on the classes at the same time. A "package" access level would help, as would the ability to split a module into multiple files (for example, the option to use a directory as a module).

I'll go review the thread, but at the moment I have a hard time imagining why members should be private when they need to be accessed by tens of thousands of lines of other code. But the package level access sounds like

 good feature to add.

 But the overloading problem also plays into it: if you want to break a
 module into sub-modules then all overloading functions must be in the
 same file. This can be counter-intuitive, as it is often more
 straightforward to put any global functions into the same file as the
 classes it takes as arguments.

One can overload functions from different import scopes using the 'alias' capability. I believe this explicit control over function overloading is better than C++ for handling very large programs - in C++ with its global overloading and ADL one can get really lost as to which functions are 'in play' for overloading.
I also like mixins but you cannot use them to "mix" yourself an
implementation for an interface.

Actually, you can and it does work. (It didn't work in the original implementation because of a, now fixed, compiler bug.)

I'm talking about DMD 0.91 here. The problem appears when you try to have different mixins that provide functions with the same name but different signatures. Again, the importing algorithm is the culprit. And the reason I wanted to do this is to provide a mixin with the "dummy" functions you need to write to get default values for function arguments. This is all described in more detail in my another of my posts: digitalmars.D/2456

Seeing the lengths people go to try to emulate default function arguments makes it pretty obvious that I need to add it to the language, I'd underestimated it.
 It is the same if you use global functions, since they overload in the
 same way, so this kind of thing:

 class Stream;
 void store(Stream s,String x);

 <other file>
 void store(Stream s,MyClass c);

 doesn't work either. Because of this you cannot add support for, for
 example, storing new types to a stream class without using runtime
 polymorphy. And that is a problem because D also has structs which
 cannot implement interfaces, so you cannot add support for "being
 stored" to any struct whose base class you cannot control.

There's got to be a better way <g>.
I like that it has a bool type but
unfortunately and in contrast to one of the goals of this type the




in D is actually slower than an int


You told me yourself. You said you use "int" as the return type for islower and isupper because having ==0, !=0 semantics usually takes two operations less than having ==0,==1 semantics (as you'd have with

That's to create a bool from an int. This overhead isn't there once it is

 bool. I don't know of any conceivable implementation of bool (and that
 includes C++'s bool) that doesn't have this overhead in converting to a
 bool.


and it can be implicitly converted
to integers.

So it can, too, in C++, so that's not a reason to prefer C++ <g>.

Yes, but C++ is my current language. Switching languages means a lot of work, so D has to offer compelling advantages. It fails to do so with the bool type.

I have been surprised at the amount of controversy over a bool type

 is solidly in your camp on this, too!). I recall many l-o-n-g threads in
 newsgroups over the semantics of bool to C years ago.


 I'll argue here that I think function overloading is greatly overused,


 know I'm in a minority on that.

Then you need to ask yourself whether you create the language just for yourself or also for the "majority". It is your decision of course, but if other people use lots of overloading and you want them to use your language ...

A good point. But also consider that I wouldn't have created this

 if I wasn't interested in other peoples' views. D has grown and improved a
 lot based on feedback from the members here. But the risk D runs in trying
 to please everyone is becoming a mish-mash of conflicting, overlapping
 features.


 I want to be honest here: most of the stuff I mentioned here is by
 itself not enough for me to "condemn" the language. Otherwise I wouldn't
 be posting here. But it adds up.

I appreciate you taking the time to post your thoughts on it here.
 One of the most important issues for me is still the lack of default
 values for function arguments. To give you an example, I recently wrote
 a String interface plus different implementations as a "tryout project"
 for D. That string interface has 48 "real" methods and 36 dummy methods
 to implement default values (almost all methods have one or two default
 arguments). So for each implementation you have to write almost twice as
 many methods as really necessary.

 My attempts to work around this limitation with mixins were the reason
 why I kept bumping into the mixin and overloading problems.

 Hauke


May 30 2004
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c9d6pi$d0l$1 digitaldaemon.com>, Walter says...
.
Seeing the lengths people go to try to emulate default function arguments
makes it pretty obvious that I need to add it to the language, I'd
underestimated it.

Argument Stanzas Since you're thinking about the optionals, I'll mention a "wild idea" I've been thinking about. Often it would be great to have optional parameters but there are multiple parameters that should be independantly optional. foo(int x, int y, int z = 0, int p, int q, int r = 3); In C++ this is impossible. My suggestion is that argument lists could be broken up into "stanzas" using ";". Maybe each set is grouped by function. foo(int x, int y, int z = 0; int p, int q, int r = 3); Called like this: foo(1, 2, 3; 4, 5, 6) Or: foo(1, 2; 4, 5) Each "stanza" can have however many optional parameters at the end. So if the first stanza corresponds to coordinates, and the second to socket parameters, I can extend either independantly. Conceptually, it's more like this: <-> foo(int x, int y, int z = 0; <-> int p, int q, int r = 3); This could still be done during function argument matching and should be about the same implementation as regular optional parameters, (assuming the C++ idiom of inserting defaults in the calling function's argument list.) As normal arguments are to a list, so stanzas are to several lists. So naturally, if the last stanza contained ONLY optional parameters, it could be omitted, and so on. My only reservation is that syntax may be ambiguous, although I can't see where it breaks. Whaddaya think? Kevin
That's to create a bool from an int. This overhead isn't there once it is a
bool. I don't know of any conceivable implementation of bool (and that
includes C++'s bool) that doesn't have this overhead in converting to a
bool.

There are equivalences in the math; if true means nonzero, you can use "|" for "||". If false means "!= -1", you could use "&" for "&&". Sadly, no middle ground, which suggests to me that there IS no mathematical solution. Maybe use the high bit to indicate true and the low bit for false? I'm kidding. Kevin
Jun 01 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:c9jt8i$pfv$1 digitaldaemon.com...
 My only reservation is that syntax may be ambiguous, although I can't see

 it breaks.  Whaddaya think?

There's no technical problem with it, but I'd want to see more demand for it first <g>.
Jun 02 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c9lb8p$2tm2$2 digitaldaemon.com>, Walter says...
"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:c9jt8i$pfv$1 digitaldaemon.com...
 My only reservation is that syntax may be ambiguous, although I can't see

 it breaks.  Whaddaya think?

There's no technical problem with it, but I'd want to see more demand for it first <g>.

Like I said, just a wild idea, not a feature request. But optional/default arguments would be really nice, and/or a type safe "va_args" replacement. Here's another wild idea: a typesafe "..." mechanism. I'm sure this needs some massaging for performance et al, but the following class is an example of a possible "va" syntax. Briefly, when a function X uses "...", the system looks for "X_opArg()" overloads to handle the "..." parts. Here it is with extended opCall(): class printf2 { void opCall(int x, ...) { printf("%d: ", x); opArg(...); printf("\n"); } void opCall_opArg(char[] x) { printf("%.*s", x); } void opCall_opArg(double x) { printf("%g", x); } void opCall_opArg(uint x) { printf("%d", x); } void print_two(...); void print_two_opCall(); // and so on } int main() { printf_two printf2 = new printf_two; double dd = 0.345; uint uu = 123; printf2("hello ", dd, " ", uu, "\n"); return 0; } I know, printf() is fast, cout slower, so why use seperate calls. In any case, it would be nice to have some sort of mechanism for this KIND of task, and the function call technique allows a kind of "translation to C object model", because the static type system can already overload in this way. An alternative would be to only allow this for "opCall" and use "opArg" without any special function name prefix. If you need more than one extended function, create inner classes, used as data members, to field the calls. Mostly, I think "..." is currently used for standalone functions anyway, so the hypothetical "printf" here would be a global object or implicit function returning a singleton, etc. But I think whatever mechanism would need to permit multiple such interfaces per class. .. Maybe for D v3.0 (cough)? Kevin
Jun 02 2004
prev sibling parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Kevin Bealer wrote:

 Since you're thinking about the optionals, I'll mention a "wild idea" I've
 been thinking about. [...]  My suggestion is that argument lists could be
 broken up into "stanzas" using ";".  Maybe each set is grouped by
 function. 
 
 foo(int x, int y, int z = 0; int p, int q, int r = 3);
 
 Called like this:
 
 foo(1, 2, 3; 4, 5, 6)
 
 Or:
 
 foo(1, 2; 4, 5)

Before thinking about that too deeply, I would rather go for the full solution of named arguments (like in Python). This certainly is a more intrusive language feature which will not be decided overnight, but in the long run, it just is far more powerful, useful and descriptive than such a hard-to-read extension.
Jun 02 2004
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Sat, 29 May 2004 16:58:52 -0700, Walter wrote:

[snip]
 
 Why are large files a problem? 

The problem I have with large files is how to enable a group of developers to independantly and simultaneously modify sections of it without losing something. If only one coder can check-out the file at a time, I have others in the team waiting on that coder to check it in again. If I allow multiple checkouts, then there are issues about merging check ins without making mistakes. This can be quite a time-consuming manual effort. A set of smaller files that together make a single 'module' is a much more practical solution for a team of coders. Right now, I have a large file (33,400 lines) that I would *love* to split up so that I can have a team of coders simultaneously working on various parts. -- Derek 31/May/04 11:53:10 AM
May 30 2004