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

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

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.

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

Which walls are yours?

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:
http://www.digitalmars.com/drn-bin/wwwnews?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

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

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:
> http://www.digitalmars.com/drn-bin/wwwnews?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
> > 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.


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

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/

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:
>>http://www.digitalmars.com/drn-bin/wwwnews?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

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

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
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).
>
> 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:
> > http://www.digitalmars.com/drn-bin/wwwnews?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
> > > 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.
>
>
> > >>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,
> 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 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
> >
> >
> >
>
>