Re: UFCS for D
On Thursday, 29 March 2012 at 00:21:38 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/ Andrei The primitives/utility distinction is an idea I've thought about a lot. UFCS is justifiable not only as a syntactic convenience but as a solution to an important design principle. Great work guys! NMS
Re: UFCS for D
On 2012-03-30 04:05, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message True, but I upgraded recently to 64 bit Win 7, with a 6 core processor and SSD drive. Reddit seems a lot zippier :-) I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably. Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy. Have you seen this: http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins They compare and old Macintosh from the 80's against a fairly new PC. -- /Jacob Carlborg
Re: UFCS for D
On 3/29/2012 6:57 PM, Nick Sabalausky wrote: How the heck does that improve encapsualtion? With D's implicit friends, it *doesn't*, it's just shifting things around. There is NO encapsualtion benefit there. Like Steven said, to *get* the encapsualtion, you have to create a whole new module to stick extraFunctionality into. It doesn't improve intra-module encapsulation, you're right. The point of UFCS, however, is so that *other* modules can extend a class's methods without breaking encapsulation. In D, the module is the fundamental unit of encapsulation, not the class. The reason is the whole reason that friends exist - sometimes, more than one component (i.e. class) is needed to manipulate private state.
Re: UFCS for D
On 3/29/2012 7:05 PM, Nick Sabalausky wrote: I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably. Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy. I'm in complete agreement with you. It's like when I bought a new dvd burner, and had to upgrade Nero Burning to deal with it. The old Nero was 6Mb, the new one was 90Mb (!)
Re: UFCS for D
Walter Bright newshou...@digitalmars.com wrote in message news:jl3kkf$j4b$1...@digitalmars.com... On 3/29/2012 6:57 PM, Nick Sabalausky wrote: How the heck does that improve encapsualtion? With D's implicit friends, it *doesn't*, it's just shifting things around. There is NO encapsualtion benefit there. Like Steven said, to *get* the encapsualtion, you have to create a whole new module to stick extraFunctionality into. It doesn't improve intra-module encapsulation, you're right. The point of UFCS, however, is so that *other* modules can extend a class's methods without breaking encapsulation. In D, the module is the fundamental unit of encapsulation, not the class. The reason is the whole reason that friends exist - sometimes, more than one component (i.e. class) is needed to manipulate private state. (Disclaimer: I don't really excpect this to actually get changed at this point, just discussing.) I definitely agree with this: sometimes, more than one component (i.e. class) is needed to manipulate private state However, that need could also be served by a module access specifier (similar to package). Personally, I think that would have been a better approach. (And it would still be much, much better than friend.) While there are definitely times I need to access private state across separate components within a module, I find such cases are fairly uncommon, so I question the wisdom of making it the default behavior.
Re: UFCS for D
Jacob Carlborg d...@me.com wrote in message news:jl3kar$ie4$1...@digitalmars.com... On 2012-03-30 04:05, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message True, but I upgraded recently to 64 bit Win 7, with a 6 core processor and SSD drive. Reddit seems a lot zippier :-) I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably. Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy. Have you seen this: http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins They compare and old Macintosh from the 80's against a fairly new PC. Yea, I've seen that. It's a very good article, though. Although I've been saying this since before that article, and even before multi-cores. Contrary to the title, I wasn't at all surprised which won ;) Of course, I don't expect software to be as super-fine-tuned as it was on, say, the Apple 2 or Atari 2600. There *is* definitely some value in loosing a certain amount of performance to abstractions, up to a point. But we've blown way, way, WAAAY beyond that point. It's sickening how much gratuitous waste there is in a lot of modern software, and really for not much benefit, as D proves.
Re: UFCS for D
Nick Sabalausky a@a.a wrote in message
news:jl3n59$qf7$1...@digitalmars.com...
Jacob Carlborg d...@me.com wrote in message
news:jl3kar$ie4$1...@digitalmars.com...
On 2012-03-30 04:05, Nick Sabalausky wrote:
Walter Brightnewshou...@digitalmars.com wrote in message
True, but I upgraded recently to 64 bit Win 7, with a 6 core processor
and
SSD drive. Reddit seems a lot zippier :-)
I don't understand why people think it's ok for basic, basic shit that
would
have ran fine on a Pentium 1 (and less) to now require what quite
literally
is a super-fucking-computer-on-the-desktop just to run acceptably.
Seriously, what the fuck's the point of buying all this insanely
powerful
hardware if software just turns the damn thing right back into a fucking
single-core P1? That's just insane. People are seriously fucking
bat-shit
crazy.
Have you seen this:
http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
They compare and old Macintosh from the 80's against a fairly new PC.
Yea, I've seen that. It's a very good article, though. Although I've been
saying this since before that article, and even before multi-cores.
Contrary to the title, I wasn't at all surprised which won ;)
Of course, I don't expect software to be as super-fine-tuned as it was on,
say, the Apple 2 or Atari 2600. There *is* definitely some value in
loosing a certain amount of performance to abstractions, up to a point.
But we've blown way, way, WAAAY beyond that point.
It's sickening how much gratuitous waste there is in a lot of modern
software, and really for not much benefit, as D proves.
Actually, one thing that really gets me is shutdown times: RAM is
*volitile*. How much processing can really be needed when the RAM's just
gonna get wiped anyway? You ask the user if they want to save, you flush the
output queues for anything non-volitile, and you cut the power. Sheesh!
Desktops are the worst offenders, and paricularly WinXP. But then even on my
brother's PS3, you can literally count the seconds before it actually turns
off. It's just a set-top gaming console, is that really necessary? (They can
spare me their It does everything! - like I give a crap about any of those
gimmicks.) On my old (super-low-power) NES, you could hit the power button,
and within one second you were at the title screen. Hit one button and
you're immediately playing (and I mean *playing*, not watching exposition
or learning how to turn left). And then power button again, and the
system's off. Try doing any of that on a PS3. It's amazing that the faster
and more powerful the systems become, the longer and longer it takes them to
start/stop tasks. ('Course, the Apple 2 is a notable exception: that thing
seemed to take forever to boot. It did shut down pretty damn quick though.)
Some of that stuff isn't even a technical matter at all, but deliberate
design: Who the hell decided we need twenty company logos (fully animated,
one at a time), then 10+ minutes of exposition and building atmosphere,
followed by half an hour of (typically patronizing) tutorials before
actually getting to the real gameplay? Zelda Skyward Sword is the worst
offender, it literally takes *hours* to get past all the initial exposition,
tutorials and shit into the real core of the game (I honestly started
wondering if there even *was* a game - Did I pick up a Harry Potter movie
by mistake?). The original Zelda, you could get from power off to the meat
of the gameplay in literally seconds. Game devs won't let you do that now:
They've gotta show off their cinematography so they can get hired by Pixar,
where they *really* wanted to be all along. (Meh, Dreamworks was always
better anyway ;) )
Sheesh, (and now I'm *really* getting sidetracked here ;) ), even
*Hollywood* hates exposition (you can tell by how the actors/directors
always rush through those lines as fast as they can). But go figure: with
all the Hollywood brown-nosing the game devs do, and imitating them even in
ways that make no sense for an interactive medium, that hatred for
exposition and rambling on, and on, and on, is the *one* thing in Hollywood
that game devs aren't tripping over themselves trying to ape.
Re: UFCS for D
On 03/30/2012 01:45 AM, bearophile wrote: Timon Gehr: I think the article does not mention that it also works for primitive types. But there is a small problem with primitive properties: http://d.puremagic.com/issues/show_bug.cgi?id=7773 Bye, bearophile Yes, I have never understood why built-in types are excluded from expressions other than '.' expressions during parsing. After all, semantic analysis must deal with them because they can occur through aliases. It seems inconsistent and causes strange behaviour that is hard to remember. (The fact that primitive types cannot be passed as alias parameters smells in a similar way.)
Re: UFCS for D
On 3/30/2012 12:18 AM, Nick Sabalausky wrote: While there are definitely times I need to access private state across separate components within a module, I find such cases are fairly uncommon, so I question the wisdom of making it the default behavior. If your module has grown so large that you need such encapsulation, meaning that the cognitive load of understanding the module has exceeded one's grasp, then I submit that the module needs to be broken up into multiple modules. There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address.
Re: UFCS for D
Walter Bright newshou...@digitalmars.com wrote in message news:jl3l0c$jn2$1...@digitalmars.com... On 3/29/2012 7:05 PM, Nick Sabalausky wrote: I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably. Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy. I'm in complete agreement with you. It's like when I bought a new dvd burner, and had to upgrade Nero Burning to deal with it. The old Nero was 6Mb, the new one was 90Mb (!) Yea, needing to upgrade Nero bugged me too. And even ignoring filesize, each new version of Nero kept getting worse anyway (the original was actually pretty good, but they quickly put a stop to that). I just use ImgBurn/DVD Decryptor/DVD Shrink for ripping/burning ISOs and InfraRecorder for everything else. They're s much better than *any* commercial package I've seen in at least ten years. They do the job, do it well, and all with *no* bullshit/bloat/skins or any other such crap.
Re: UFCS for D
or just use http://cdburnerxp.se/ Am 30.03.2012 10:30, schrieb Nick Sabalausky: Walter Brightnewshou...@digitalmars.com wrote in message news:jl3l0c$jn2$1...@digitalmars.com... On 3/29/2012 7:05 PM, Nick Sabalausky wrote: I don't understand why people think it's ok for basic, basic shit that would have ran fine on a Pentium 1 (and less) to now require what quite literally is a super-fucking-computer-on-the-desktop just to run acceptably. Seriously, what the fuck's the point of buying all this insanely powerful hardware if software just turns the damn thing right back into a fucking single-core P1? That's just insane. People are seriously fucking bat-shit crazy. I'm in complete agreement with you. It's like when I bought a new dvd burner, and had to upgrade Nero Burning to deal with it. The old Nero was 6Mb, the new one was 90Mb (!) Yea, needing to upgrade Nero bugged me too. And even ignoring filesize, each new version of Nero kept getting worse anyway (the original was actually pretty good, but they quickly put a stop to that). I just use ImgBurn/DVD Decryptor/DVD Shrink for ripping/burning ISOs and InfraRecorder for everything else. They're s much better than *any* commercial package I've seen in at least ten years. They do the job, do it well, and all with *no* bullshit/bloat/skins or any other such crap.
Re: UFCS for D
On 3/30/12, Walter Bright newshou...@digitalmars.com wrote: There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Ignoring that there are still a few import bugs, you can split functionality into multiple modules and use one module per package that publicly imports all modules in that package: module std.datetime; public import std.date.time, std.date.clock, std.date.watch; That's what people are already doing with various D libraries. Then, unittests could be moved into a central place. I think that could cut down the linecount quite a bit. If linecount is still a problem after that, then either the modules have to be further split or it might be an indication that Phobos is getting too large. Why would the language be at fault here?
Re: UFCS for D
Walter Bright newshou...@digitalmars.com wrote in message news:jl3qds$10ga$1...@digitalmars.com... On 3/30/2012 12:18 AM, Nick Sabalausky wrote: While there are definitely times I need to access private state across separate components within a module, I find such cases are fairly uncommon, so I question the wisdom of making it the default behavior. If your module has grown so large that you need such encapsulation, meaning that the cognitive load of understanding the module has exceeded one's grasp, then I submit that the module needs to be broken up into multiple modules. It's not about cognitive load exceeding the brain's capacity (well, I'm sure it can be in some cases), it's about just simply keeping separate things separate without ending up in Java's world of millions of tiny files for each trivial thing. You should be able to look at a couple unrelated chunks of code in a module (ie they handle completely separate details of the implementation of the module's single conceptual task) and *know* there's no interplay going on simply by virtue of the code not specifically suggesting otherwise via permissive access specifiers. And if those separate sub-tasks are small, stucking them each in separate files is a Java-like burden. So if you don't want to go that route, then when you look at them as things are now, well, there might be interplay and there might not be. There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. I thought that was a deliberate Phobos style convention. I'm certain I remember you and/or Andrei talking here about a year or two ago about how you didn't want Phobos modules broken up into separate implemetation modules. In fact, I definitely remember now, back early last year when Andrei first brought up the idea of having generalized parser in Phobos, I mentioned my Goldie project and there was a small discussion about the possibility of using that as the std.parser or whatever. I specifically remember you saying that, were Goldie to go into Phobos, you'd want it all merged into one module. Ultimately, I backed off on the whole idea as I felt Goldie likely wouldn't be an appropriate fit for Phobos, and that was one of the reasons. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module foo and module foo.bar. The reasons they gave for wanting this are right along the lines of what you're talking about here. Eventually they got the message that it wasn't gonna happen and they gave up asking for it. Or is there a separate problem you're refering to?
Re: UFCS for D
On 03/30/2012 02:15 AM, Nick Sabalausky wrote: Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module foo and module foo.bar. This is afaik similar to ADA child packages. Quote : Ada allows one to extend the functionality of a unit (package) with so-called children (child packages). With certain exceptions, all the functionality of the parent is available to a child. This means that all public and private declarations of the parent package are visible to all child packages.
Re: UFCS for D
On 3/30/2012 2:15 AM, Nick Sabalausky wrote: Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module foo and module foo.bar. The reasons they gave for wanting this are right along the lines of what you're talking about here. Eventually they got the message that it wasn't gonna happen and they gave up asking for it. Or is there a separate problem you're refering to? No, that's it. What brings it to the fore is, as I said, the kitchen-sink module that is becoming prevalent.
Re: UFCS for D
On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote: Yea, that occurred to me, too. wishful musingI've been starting to think more and more that the everything in a module is a friend was a mistake, and that we should have instead just had a module access specifier like we have package./wishful musing Given Phobos' organization (or lack thereof) where files are at the order of 10k lines or more this should raise concern.
Re: UFCS for D
On Fri, 30 Mar 2012 02:42:03 -0400, Walter Bright newshou...@digitalmars.com wrote: On 3/29/2012 6:57 PM, Nick Sabalausky wrote: How the heck does that improve encapsualtion? With D's implicit friends, it *doesn't*, it's just shifting things around. There is NO encapsualtion benefit there. Like Steven said, to *get* the encapsualtion, you have to create a whole new module to stick extraFunctionality into. It doesn't improve intra-module encapsulation, you're right. The point of UFCS, however, is so that *other* modules can extend a class's methods without breaking encapsulation. This is misleading, the class being extended or the code that uses the extensions must import the extension methods or it doesn't work. The OP to this sub-thread brought up your example in the article -- adding range functions to a class. Yes, you can do it, but it won't work with std.algorithm. There's no need to test this, because it fundamentally cannot work that way (see my counter-case). -Steve
Re: UFCS for D
On Friday, 30 March 2012 at 10:22:18 UTC, Walter Bright wrote: On 3/30/2012 2:15 AM, Nick Sabalausky wrote: Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module foo and module foo.bar. The reasons they gave for wanting this are right along the lines of what you're talking about here. Eventually they got the message that it wasn't gonna happen and they gave up asking for it. Or is there a separate problem you're refering to? No, that's it. What brings it to the fore is, as I said, the kitchen-sink module that is becoming prevalent. I'm confused. I thought that The kitchen-sink approach was a deliberate design decision. I also don't see how the language is at fault here - some libraries opted for a all.d module that public imports the other modules which cleanly solves the problem. This can be trivially solved by a convention of adding a _.d or all.d or whatever agreed upon module at the package level. Sure, the above mentioned enhancement will remove the need for this extra tiny step. But this is merely eliminating a minor inconvenience, not some huge flaw of the language that prevents good design and proper organization.
Re: UFCS for D
On Fri, 30 Mar 2012 04:21:12 -0400, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jl3n59$qf7$1...@digitalmars.com... Yea, I've seen that. It's a very good article, though. Although I've been saying this since before that article, and even before multi-cores. Contrary to the title, I wasn't at all surprised which won ;) Of course, I don't expect software to be as super-fine-tuned as it was on, say, the Apple 2 or Atari 2600. There *is* definitely some value in loosing a certain amount of performance to abstractions, up to a point. But we've blown way, way, WAAAY beyond that point. It's sickening how much gratuitous waste there is in a lot of modern software, and really for not much benefit, as D proves. 100% agree. There has been a huge trend in software to disregard performance because the hardware will take care of it. Interestingly enough though, performance still turns heads :) That is, when faced with two applications that do the same thing, but one is twice as fast, most people will choose (and probably pay more for) the faster one. Actually, one thing that really gets me is shutdown times: RAM is *volitile*. How much processing can really be needed when the RAM's just gonna get wiped anyway? You ask the user if they want to save, you flush the output queues for anything non-volitile, and you cut the power. Sheesh! One of the things I was extremely impressed with on my new macbook is that it usually shuts down in under 2 seconds. Desktops are the worst offenders, and paricularly WinXP. Windows 7 is vastly better at both startup and shutdown than WinXP. I think part of the problem is that shutdown on these systems defers to the user applications. Sometimes I shutdown, and come back the next day to find it was still asking me some questions. G. Now I have to answer the questions, let it power off, then power back on again. The apps should save enough state so they can resume the next day without issue (this is how the mac seems to work, and I love it). But then even on my brother's PS3, you can literally count the seconds before it actually turns off. It's just a set-top gaming console, is that really necessary? (They can spare me their It does everything! - like I give a crap about any of those gimmicks.) On my old (super-low-power) NES, you could hit the power button, and within one second you were at the title screen. You must have had a different version of NES. The process to start mine up was not nearly as fast. It went something like this: 1. Insert cartridge, push down cartridge, power on. (I cite this as one step because it became automatic to do this in 2 seconds) 2. Screen with horribly large pixellated game appears. 3. Power off, pull out cartridge. 4. Blow in bottom of cartridge, even though the pins are clean and free of dust (did this actually ever do anything?) 5. Re-insert cartridge, this time more firmly, push down deliberately to make sure game locks into place 6. Power on, normal screen comes up, push start button. 7. Play for about 2 minutes, game hangs with single audio tone. 8. Bang hand on top of NES to show it you mean business. Sometimes it will whimper back to playing mode. 9. After second hang, attempt to press reset button about 15 times. Peanut-sized pixels return. 10. Power off, remove catridge, repeat blowing procedure from step 4, but with slower more deliberate breath. Try a blowing pattern, like quick bursty blows in various locations. Insert cartidge even MORE firmly. Jiggle cartridge a bit to make sure the NES is aware there is a valid game for it to consume. 11. Lower cartridge, power on. Play game for another 5 minutes. 12. After next hang, turn power off, and watch cartoons. I exaggerate a bit :) But sometimes I swear it was like this. I don't miss those days, though I don't get to play many video games these days. I'm waiting for my kids to get old enough to play them so I can mooch off of their video game time :) Some of that stuff isn't even a technical matter at all, but deliberate design: Who the hell decided we need twenty company logos (fully animated, one at a time), then 10+ minutes of exposition and building atmosphere, followed by half an hour of (typically patronizing) tutorials before actually getting to the real gameplay? Zelda Skyward Sword is the worst offender, it literally takes *hours* to get past all the initial exposition, tutorials and shit into the real core of the game (I honestly started wondering if there even *was* a game - Did I pick up a Harry Potter movie by mistake?). The original Zelda, you could get from power off to the meat of the gameplay in literally seconds. Game devs won't let you do that now: They've gotta show off their cinematography so they can get hired by Pixar, where they *really* wanted to be all along. (Meh, Dreamworks was always better anyway ;) )
Re: UFCS for D
Walter Bright wrote: On 3/29/2012 5:09 PM, Steven Schveighoffer wrote: The reason being, if you change anything in class A, you do not have to worry about the implementation of getXSquared, because it simply has no access to the private implementation. You only have to worry about internal methods, and friend functions. Ok, I see what you're talking about. It has nothing to do with UFCS, it is D's design decision to not have explicit friends, but to make everything in a module implicitly a friend. I think it's far superior to the explicit friend thing in C++. Just curious. Did you take it from Delphi? :-)
Re: UFCS for D
On 2012-03-30 10:20, Walter Bright wrote: There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. I don't know for HOW LONG I've been saying this. The modules in Phobos are way too large. I always thought this was a design decision, that you wanted a flat hierarchy of modules in Phobos. But I don't think it's a problem with the language. I've been splitting up my code in several sub packages and modules for as long as I've been using D. Just move the code to new modules. It can take some time to figure out how to best organize the modules but when that's finished there should be any problems. -- /Jacob Carlborg
Re: UFCS for D
Le 30/03/2012 11:40, bls a écrit : On 03/30/2012 02:15 AM, Nick Sabalausky wrote: Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module foo and module foo.bar. This is afaik similar to ADA child packages. Quote : Ada allows one to extend the functionality of a unit (package) with so-called children (child packages). With certain exceptions, all the functionality of the parent is available to a child. This means that all public and private declarations of the parent package are visible to all child packages. This sound interesting. And why not use public import for that ? It wouldn't break any existing code, because it enlarge the field of possibles.
Re: UFCS for D
Le 30/03/2012 12:57, foobar a écrit : On Friday, 30 March 2012 at 10:22:18 UTC, Walter Bright wrote: On 3/30/2012 2:15 AM, Nick Sabalausky wrote: Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Eh? Other people have voiced concerns over that since waaay back in even pre-D1 times. In particular, many people have argued for allowing modules with the same name as a package. Ie: you could have both module foo and module foo.bar. The reasons they gave for wanting this are right along the lines of what you're talking about here. Eventually they got the message that it wasn't gonna happen and they gave up asking for it. Or is there a separate problem you're refering to? No, that's it. What brings it to the fore is, as I said, the kitchen-sink module that is becoming prevalent. I'm confused. I thought that The kitchen-sink approach was a deliberate design decision. I also don't see how the language is at fault here - some libraries opted for a all.d module that public imports the other modules which cleanly solves the problem. This can be trivially solved by a convention of adding a _.d or all.d or whatever agreed upon module at the package level. Sure, the above mentioned enhancement will remove the need for this extra tiny step. But this is merely eliminating a minor inconvenience, not some huge flaw of the language that prevents good design and proper organization. all.d this the de facto standard here. I think it should become an official guideline.
Re: UFCS for D
Le 30/03/2012 01:34, Steven Schveighoffer a écrit :
On Wed, 28 Mar 2012 21:53:57 -0400, Jesse Phillips
jessekphillip...@gmail.com wrote:
I won't be going out of my way to check this, but there is a mention
of adding the range primatives. This works, but it doesn't make the
class a range for any other module, so std.algorithms won't recogonise
it as a range.
At first thought, I believed this should be fixable -- if not working
already. Consider that std.algorithm doesn't include *your* module, yet
you can pass types defined in your module into std.algorithm and it
works just fine.
But I realized after typing about 2 messages in response to this (and
deleting them), you are right, there is a fundamental problem here.
Because the template instantiation is based solely on the type. It does
*not* include the type and whatever other modules you may have included
that could define extension methods. I don't think it's an
implementation issue, I think it's a design issue -- there simply is no
way to do this.
A counter case:
module1.d:
int foo(T)(T t)
{
return t.bar();
}
module2.d:
struct S { int x;}
module3.d:
import module1, module2;
int bar(S s) { return s.x * 2;}
void baz1()
{
S s(2);
assert(foo(s) == 4);
}
module4.d:
import module1, module 2;
int bar(S s) { return s.x * 3;}
void baz2()
{
S s(2);
assert(foo(s) == 6);
}
// and to drive the point further:
module5.d:
import module3, module4;
void main()
{
baz1();
baz2();
}
In order for the asserts to *both* pass, there has to be two different
instantiations of foo!S, one for module3, and one for module4.
So two possible sane rules:
1. A template instantiation can *only* use UFCS from functions defined
in or imported from the module in which the template is defined. (i.e.
the way it works now I think)
or
2. A template instantiation can *only* use UFCS from functions defined
in or imported from the module in which the template is defined, *and*
from functions as defined or imported by the module that defines the
type on which UFCS is being used. In other words, from my example above,
only functions defined in or imported from module1.d and module2.d.
Therefore, the bar extension defined in module3 and module4 cannot be
called from module1.
For builtin types (such as arrays or numbers), there wouldn't be a
module that the type was defined. However, object.di is imported by
everything, so extensions could be put in there.
This kind of puts a damper on certain expectations for how UFCS could be
used. But I don't see any other way (other than adding the current
module into the instantiation somehow -- imagine the template bloat...).
Even with this limitation, UFCS still allows a lot of cool things. One
misleading suggestion from the article however, it's not very easy to
create non-friend non-member functions using UFCS, considering that
every function in a given module is a friend. In order to do this, you
would need a helper module for each module that wants to define such
non-friend functions. Given the above proof, the helper module would
also have to be imported by the main module.
-Steve
I would expect this not to work, because bar isn't defined in module1
and template are supposed to use declaration scope, not instantiation
scope (unless it is mixin template).
Re: UFCS for D
On 2012-03-30 10:36, Andrej Mitrovic wrote: On 3/30/12, Walter Brightnewshou...@digitalmars.com wrote: There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Ignoring that there are still a few import bugs, you can split functionality into multiple modules and use one module per package that publicly imports all modules in that package: module std.datetime; public import std.date.time, std.date.clock, std.date.watch; I agree. That's what people are already doing with various D libraries. Then, unittests could be moved into a central place. Yeah, that's working just fine. I think that could cut down the linecount quite a bit. If linecount is still a problem after that, then either the modules have to be further split or it might be an indication that Phobos is getting too large. If any abstraction (or what to call it) becomes too large then you just create another one. If method becomes too large - split it up in several methods If a class gets too many methods - split the class in several classes If a module gets too many classes - split the module in several modules If package gets too many modules - split it up in in several (sub) packages If a library gets too many packages - split it up in several libraries -- /Jacob Carlborg
Re: UFCS for D
Le 30/03/2012 04:13, Adam D. Ruppe a écrit :
On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
wishful musingI've been starting to think
more and more that the everything in a module is a friend was a
mistake,and that we should have instead just had a module
access specifier like we have package./wishful musing
Or, for moar compatibility, have enemy functions.
class Klingon { private Starship commanding; }
void nonFriend(enemy Klingon kor) {
kor.commanding = lol; // error, commanding is private and kor is an enemy
}
Or, to avoid having a new keyword, call it interface
instead of enemy.
Though, then you could just pass an interface instead of
a class too. Take most general possible type.
But, separate modules are kinda cool anyway. I often put
stuff together in one module just for ease of distribution,
but eh modules are cool.
For the ease of distribution, you can use a module with public import in it.
Re: UFCS for D
On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix deadal...@gmail.com wrote: I would expect this not to work, because bar isn't defined in module1 and template are supposed to use declaration scope, not instantiation scope (unless it is mixin template). Right, I think it's the way it works now. But consider that the template instantiation *does* pull in some stuff from the instantiation scope (i.e. the template's module may not import the type being used to instantiate). I think it would be OK for the compiler to consider UFCS functions from the type's defining module as well, since you cannot instantiate the template for that particular type without having imported that module (i.e. it's guaranteed to instantiate the same no matter what module does it first). -Steve
Re: UFCS for D
On 2012-03-30 11:15, Nick Sabalausky wrote: I thought that was a deliberate Phobos style convention. I'm certain I remember you and/or Andrei talking here about a year or two ago about how you didn't want Phobos modules broken up into separate implemetation modules. I recognize that as well. -- /Jacob Carlborg
Re: UFCS for D
Le 30/03/2012 14:13, Steven Schveighoffer a écrit : On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix deadal...@gmail.com wrote: I would expect this not to work, because bar isn't defined in module1 and template are supposed to use declaration scope, not instantiation scope (unless it is mixin template). Right, I think it's the way it works now. But consider that the template instantiation *does* pull in some stuff from the instantiation scope (i.e. the template's module may not import the type being used to instantiate). I think it would be OK for the compiler to consider UFCS functions from the type's defining module as well, since you cannot instantiate the template for that particular type without having imported that module (i.e. it's guaranteed to instantiate the same no matter what module does it first). -Steve It does pull information from it's own scope and what is passed as parameter. So it would still fail for the UFCS case. I don't see a clean solution for that, because of ambiguities. That something that is not new and not specific to UFCS. Immagine you want to define your own to!xxx() for your type xxx. (It is dumb case because you have toString, but an interesting exercise because for your own stuff, not something that is specified in the language - like toString - the same could happen with no easy solution.
Re: UFCS for D
On 03/30/2012 05:06 AM, deadalnix wrote:
Le 30/03/2012 11:40, bls a écrit :
On 03/30/2012 02:15 AM, Nick Sabalausky wrote:
Eh? Other people have voiced concerns over that since waaay back in even
pre-D1 times. In particular, many people have argued for allowing
modules
with the same name as a package. Ie: you could have both module foo
and
module foo.bar.
This is afaik similar to ADA child packages.
Quote :
Ada allows one to extend the functionality of a unit (package) with
so-called children (child packages). With certain exceptions, all the
functionality of the parent is available to a child. This means that all
public and private declarations of the parent package are visible to all
child packages.
This sound interesting. And why not use public import for that ? It
wouldn't break any existing code, because it enlarge the field of
possibles.
Asking Nick or me ?
Anyway, you can't really compare the D module- and ADA package concept.
A D-ified ADA package could like like :
module Shelf {
module Disks {
}
module Books {
}
}
I am not an active ADA user but instead of having a single file you
could use the D-ified Ada way...
module Shelf;
module Shelf.Disks;
module Shelf.Books;
instead. And I think this what Nick is talking about.
Having the same scoping rules.
http://en.wikibooks.org/wiki/Ada_Programming/Packages
Re: UFCS for D
On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix deadal...@gmail.com wrote: Le 30/03/2012 14:13, Steven Schveighoffer a écrit : On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix deadal...@gmail.com wrote: I would expect this not to work, because bar isn't defined in module1 and template are supposed to use declaration scope, not instantiation scope (unless it is mixin template). Right, I think it's the way it works now. But consider that the template instantiation *does* pull in some stuff from the instantiation scope (i.e. the template's module may not import the type being used to instantiate). I think it would be OK for the compiler to consider UFCS functions from the type's defining module as well, since you cannot instantiate the template for that particular type without having imported that module (i.e. it's guaranteed to instantiate the same no matter what module does it first). -Steve It does pull information from it's own scope and what is passed as parameter. So it would still fail for the UFCS case. I don't see a clean solution for that, because of ambiguities. That something that is not new and not specific to UFCS. Why would there be ambiguities? Unlike C include files, D modules are consistently compiled, unaffected by importing other modules. In order to instantiate a template templ!Foo, either the module that defines templ, or the module who is instantiating *must* import the module that defines Foo. Knowing this, the compiler should be able to deduce that it can consistently compile tmpl!Foo even if it pulls in UFCS functions from Foo's module or modules that Foo's module imports. Immagine you want to define your own to!xxx() for your type xxx. (It is dumb case because you have toString, but an interesting exercise because for your own stuff, not something that is specified in the language - like toString - the same could happen with no easy solution. I don't think this disproves anything. It should be possible without ambiguity given the rules I stated. -Steve
Re: UFCS for D
On Friday, 30 March 2012 at 11:21:02 UTC, Steven Schveighoffer wrote: 4. Blow in bottom of cartridge, even though the pins are clean and free of dust (did this actually ever do anything?) My hypothesis is it was actually the moisture that made a better connection. I'd like to test this now... I should break out the old nes and some canned air and distilled water. But, back in the day, I used to find great success by actually running the game under a small stream of tap water. It'd almost always work right after that. I prefer the cartridges, flaws and all, to CDs. They are so easy to dirty up, scracth, or get outright broken (my brother was an angry gamer!) And they load so slowly, especially the newer games.
Re: UFCS for D
On 2012-03-30 14:07, deadalnix wrote: all.d this the de facto standard here. I think it should become an official guideline. Why can't we get import foo.*;, then we don't have to relay on guidelines. -- /Jacob Carlborg
Re: UFCS for D
On Friday, 30 March 2012 at 12:10:32 UTC, deadalnix wrote: For the ease of distribution, you can use a module with public import in it. There's still a few things I don't like though, about downloading and compiling several modules. When it is just one, you can download the single file and add it to your dmd command line. With several modules, that's more effort, either in downloading many things or in maintaining a zip+lib of them too. A lot different than my preference of grab my cgi.d and play!
Re: UFCS for D
On 3/30/12 3:20 AM, Walter Bright wrote: There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Walter and I agreed on a design and I got tasked with writing a DIP. I don't have any time for it, but I had to do it so here it is: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Thanks, Andrei
Re: UFCS for D
Le 30/03/2012 16:24, Andrei Alexandrescu a écrit : On 3/30/12 3:20 AM, Walter Bright wrote: There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Walter and I agreed on a design and I got tasked with writing a DIP. I don't have any time for it, but I had to do it so here it is: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Thanks, Andrei Hi, It is an interesting proposal. You should start a thread about that so comment will not get lost in this one.
Re: UFCS for D
On 2012-03-30 16:17, Adam D. Ruppe wrote: On Friday, 30 March 2012 at 12:10:32 UTC, deadalnix wrote: For the ease of distribution, you can use a module with public import in it. There's still a few things I don't like though, about downloading and compiling several modules. When it is just one, you can download the single file and add it to your dmd command line. With several modules, that's more effort, either in downloading many things or in maintaining a zip+lib of them too. A lot different than my preference of grab my cgi.d and play! That's way I'm working on a package manager. -- /Jacob Carlborg
Re: UFCS for D
On 3/30/12 9:32 AM, deadalnix wrote: Le 30/03/2012 16:24, Andrei Alexandrescu a écrit : On 3/30/12 3:20 AM, Walter Bright wrote: There has been a trend in Phobos of having some truly gigantic modules. I believe this is indicative of a problem in the language. Andrei and I have talked about it, and we think it is because of difficulties in breaking a module up into submodules of a package. We think it's something we need to address. Walter and I agreed on a design and I got tasked with writing a DIP. I don't have any time for it, but I had to do it so here it is: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Thanks, Andrei Hi, It is an interesting proposal. You should start a thread about that so comment will not get lost in this one. Started a thread in the main forum. Andrei
Re: UFCS for D
On Fri, 30 Mar 2012 10:39:09 -0400, Jacob Carlborg d...@me.com wrote: On 2012-03-30 14:52, Steven Schveighoffer wrote: Why would there be ambiguities? Unlike C include files, D modules are consistently compiled, unaffected by importing other modules. What about static-if and string mixins? This C code is what I'm talking about: file1.h: #define BLAH file2.h: #ifdef BLAH int foo(); #else char * foo(); #endif main.c: #include file1.h #include file2.h Note how including file1.h affects how file2.h is processed, with no control given to file2.h. But in D this cannot happen, a module is consistently processed, no matter how it's imported or in what order. Therefore you can be confident that no matter how it was imported, it has access to the same exact compiled code. Neither static-if or string mixins cannot affect a file that does not import them (directly or indirectly). -Steve
Re: UFCS for D
On Fri, 30 Mar 2012 10:48:04 -0400, deadalnix deadal...@gmail.com wrote: Le 30/03/2012 14:52, Steven Schveighoffer a écrit : On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix deadal...@gmail.com wrote: Immagine you want to define your own to!xxx() for your type xxx. (It is dumb case because you have toString, but an interesting exercise because for your own stuff, not something that is specified in the language - like toString - the same could happen with no easy solution. I don't think this disproves anything. It should be possible without ambiguity given the rules I stated. -Steve You are messing up everything. First, this have NOTHING to do with UFCS. Yes it does. The special rule only applies when using UFCS functions. Second, current D import system have no ambiguity. But you propose to change that system. That would introduce ambiguity. Stating it doesn't prove it. I claim no ambiguity, simply because I cannot see what the ambiguous case would be. It's very easy to disprove me, show one example. Even if you don't believe me, which is fine, it is safe to assume so unless you can prove otherwise. I'm not disputing the current module system is unambiguous. I assert that my additions do not make it unambiguous. Trying to prove that it's unambiguous would be really really hard, and require probably years of research. I don't really want to prove it. But disproving it can be done with one case. If you believe it's ambiguous, you must have a case in mind, no? -Steve
Re: UFCS for D
On 3/29/2012 4:34 PM, Steven Schveighoffer wrote: But I realized after typing about 2 messages in response to this (and deleting them), you are right, there is a fundamental problem here. Because the template instantiation is based solely on the type. It does *not* include the type and whatever other modules you may have included that could define extension methods. I don't think it's an implementation issue, I think it's a design issue -- there simply is no way to do this. Yes, you're right. The template is instantiated in the context of the template definition, not the template instantiation. Hence, unless the extension methods are in scope of the template definition, they will not be found. I hadn't thought of this issue. So two possible sane rules: 1. A template instantiation can *only* use UFCS from functions defined in or imported from the module in which the template is defined. (i.e. the way it works now I think) Yes, that is the way it works now. or 2. A template instantiation can *only* use UFCS from functions defined in or imported from the module in which the template is defined, *and* from functions as defined or imported by the module that defines the type on which UFCS is being used. I would argue that: 3. An extension method for an argument of type template parameter T will be looked up only in the instantiation scope.
Re: UFCS for D
Jacob Carlborg d...@me.com wrote in message news:jl4d2e$24i1$1...@digitalmars.com... On 2012-03-30 14:07, deadalnix wrote: all.d this the de facto standard here. I think it should become an official guideline. Why can't we get import foo.*;, then we don't have to relay on guidelines. The problem with that is it indescriminately imports modules that are either just helper modules or just intended to *occasionally* be imported instead of always imported. I like the D way of requiring the lib author to use deliberate and explicit public imports for this sort of thing. That way the lib author is deciding what gets imported, not the ignorant compiler.
Re: UFCS for D
On 3/30/2012 12:11 PM, Steven Schveighoffer wrote: On Fri, 30 Mar 2012 14:27:43 -0400, Walter Bright newshou...@digitalmars.com wrote: I would argue that: 3. An extension method for an argument of type template parameter T will be looked up only in the instantiation scope. I don't think you looked at my counter case in detail. Your idea leads to two different instantiations of tmpl!Foo having two different implementations, depending on which extension methods you include. In fact, in one place, the instantiation might succeed, but in another, the instantiation might fail. Yes, you're right. I missed that nuance. I don't really know how to fix it. Given that the compiler simply trims out identically defined symbols, assuming they are the same, this could have disastrous consequences. You could end up with code being different based on the link order, or possibly arbitrary decisions made by the linker! My argument is that the one thing in common is that the module that defines the type has to have been included. I think you would agree that the one truth we must maintain is that X!Y must be implemented exactly the same no matter what module instantiates it. I realize that the compiler likely doesn't keep enough information to know what functions would fall under the rules I specified, so this is probably a difficult change to effect. But it could be an incremental change later. -Steve
Re: UFCS for D
Steven Schveighoffer schvei...@yahoo.com wrote in message news:op.wbzdtbo0eav7ka@localhost.localdomain... On Fri, 30 Mar 2012 04:21:12 -0400, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jl3n59$qf7$1...@digitalmars.com... Of course, I don't expect software to be as super-fine-tuned as it was on, say, the Apple 2 or Atari 2600. There *is* definitely some value in loosing a certain amount of performance to abstractions, up to a point. But we've blown way, way, WAAAY beyond that point. It's sickening how much gratuitous waste there is in a lot of modern software, and really for not much benefit, as D proves. 100% agree. There has been a huge trend in software to disregard performance because the hardware will take care of it. Interestingly enough though, performance still turns heads :) That is, when faced with two applications that do the same thing, but one is twice as fast, most people will choose (and probably pay more for) the faster one. Yup. And there's *also* still the issues of: - Saving your user money on hardware. - **Battery-Fucking-Life** - Noise. All that extra processing produces more heat, thus requiring more cooling and, often times, more fan noise. - Environmentalism. All that useless processing causes the hardware to suck up more electricity, and that means power plants burning more dino-fuel and producing more nuclear waste. - Environmentalism again: Less need for hardware upgrades means less hardware in landfills. Desktops are the worst offenders, and paricularly WinXP. Windows 7 is vastly better at both startup and shutdown than WinXP. Yea, like I said, particularly WinXP ;) On my old (super-low-power) NES, you could hit the power button, and within one second you were at the title screen. You must have had a different version of NES. The process to start mine up was not nearly as fast. It went something like this: 1. Insert cartridge, push down cartridge, power on. (I cite this as one step because it became automatic to do this in 2 seconds) 2. Screen with horribly large pixellated game appears. 3. Power off, pull out cartridge. 4. Blow in bottom of cartridge, even though the pins are clean and free of dust (did this actually ever do anything?) 5. Re-insert cartridge, this time more firmly, push down deliberately to make sure game locks into place 6. Power on, normal screen comes up, push start button. 7. Play for about 2 minutes, game hangs with single audio tone. 8. Bang hand on top of NES to show it you mean business. Sometimes it will whimper back to playing mode. 9. After second hang, attempt to press reset button about 15 times. Peanut-sized pixels return. 10. Power off, remove catridge, repeat blowing procedure from step 4, but with slower more deliberate breath. Try a blowing pattern, like quick bursty blows in various locations. Insert cartidge even MORE firmly. Jiggle cartridge a bit to make sure the NES is aware there is a valid game for it to consume. 11. Lower cartridge, power on. Play game for another 5 minutes. 12. After next hang, turn power off, and watch cartoons. Heh, good point :) It didn't happen with brand new systems/carts though, it took awhile for them to corrode and for the pins to warp. But yea, I'd actually forgotten about that. Some of that stuff isn't even a technical matter at all, but deliberate design: Who the hell decided we need twenty company logos (fully animated, one at a time), then 10+ minutes of exposition and building atmosphere, followed by half an hour of (typically patronizing) tutorials before actually getting to the real gameplay? Zelda Skyward Sword is the worst offender, it literally takes *hours* to get past all the initial exposition, tutorials and shit into the real core of the game (I honestly started wondering if there even *was* a game - Did I pick up a Harry Potter movie by mistake?). The original Zelda, you could get from power off to the meat of the gameplay in literally seconds. Game devs won't let you do that now: They've gotta show off their cinematography so they can get hired by Pixar, where they *really* wanted to be all along. (Meh, Dreamworks was always better anyway ;) ) When I bought the new Wii motion plus (that gives better sensitivity) with Wii Sports Resort, the first time you play, it makes you watch 8 minutes of instructional video on how to use your Wii motion plus. I thought at the time Wow, that was a bit long, but I guess I only have to do it once. Then I went to my sister-in-law's house, and wanted to show her the game. This was *her* Wii's first time playing the game, so again, I had to watch the damn video (no way to skip). It happened a third time on my parents' Wii, and I was thinking Man, this was a *bad* design decision. Uh-huh. I've actually played a lot of Wii Sports Resort. I honestly can't believe how much I ended up liking
Re: UFCS for D
Adam D. Ruppe destructiona...@gmail.com wrote in message news:udpabjwyzxlollbiz...@forum.dlang.org... On Friday, 30 March 2012 at 11:21:02 UTC, Steven Schveighoffer wrote: 4. Blow in bottom of cartridge, even though the pins are clean and free of dust (did this actually ever do anything?) My hypothesis is it was actually the moisture that made a better connection. Probably. Problem is, it also corrodes the connectors. So the more you do it, the worse it gets. Best thing to do is rubbing alcohol on a q-tip. Or rubbing alcohol on a soft cloth wrapped around a few old credit cards or a thin piece of wood. I prefer the cartridges, flaws and all, to CDs. They are so easy to dirty up, scracth, or get outright broken (my brother was an angry gamer!) And they load so slowly, especially the newer games. Totally agree on all counts. I *liked* that the N64 used carts (although some were ridiculously pricey). And right from day one, you knew that the PSP's use of discs was a colossally stupid thing to do on a *portable*.
OT: video games (was Re: UFCS for D)
On Friday, 30 March 2012 at 21:03:21 UTC, Nick Sabalausky wrote: Problem is, it also corrodes the connectors. Yea. But oh well, it can't be too bad... my old games all still work! Though, nowadays I tend to prefer the emulators. I have a playstation controller on usb, which works for all the old games naturally (there's a clear progression from nes - super nintendo - playstation, each is a superset of the next. It works well for Sega too.) No hardware hassles, doesn't take space under the tv. I used to have a real mess of crap in my bedroom, the cords were hideous. Now most of that is on the computer. The computer can also crank up the speed, which makes some of those old games so much more playable! I can't believe I used to sit there 10 hours a day and just grind or use the slow moving characters. (though now I can't do a video game for more than one hour a week, between work, etc., and my eyes just get horribly tired with the motion. But with emulator's speed acceleration, that one hour can go a pretty long way!) I *liked* that the N64 used carts I have only one game for the N64: Perfect Dark. Bought the game when I saw it at one of the stores and picked up the system like a month later. Great game, still my favorite of the FPS genre.
Re: UFCS for D
Walter Bright wrote: On 3/30/2012 4:24 AM, Piotr Szturmaj wrote: Walter Bright wrote: I think it's far superior to the explicit friend thing in C++. Just curious. Did you take it from Delphi? :-) No. I've never looked at Delphi in detail. But in any case, for any language feature, there's always another language that had done it before, or something like it, or something that if you stand on one leg and touch your nose it resembles it, or whatever. It's also true that good ideas tend to be reinvented over and over. Yes, I agree. There have been many module systems before Delphi, too. I even have dim memories of reading about modules in the 1980 Ada spec :-) Actually, I meant allowing access to private fields within the same module. It really helped me to avoid writing boilerplate code for these fields. And I'm thinking about lots of correlated classes. I asked because Delphi and D are the only ones I know that make friend classes implicit :-)
Re: video games (was Re: UFCS for D)
Adam D. Ruppe destructiona...@gmail.com wrote in message news:ftnddrqdfbrtxiiwe...@forum.dlang.org... On Friday, 30 March 2012 at 21:03:21 UTC, Nick Sabalausky wrote: Problem is, it also corrodes the connectors. Yea. But oh well, it can't be too bad... my old games all still work! Though, nowadays I tend to prefer the emulators. Oh *definitely*. BTW, Wii homebrew is *fantastic* for that. It literally turns the Wii into a (very good) set-top multi-emulator device. And many of the Wii-hosted homebrew emulators are *very* good now. *FAR* better than the half-assed Virtual Console stuff. I have a playstation controller on usb, which works for all the old games naturally (there's a clear progression from nes - super nintendo - playstation, each is a superset of the next. It works well for Sega too.) Yea. This gets into one thing I *love* about China's unwillingless to play by the US rules: Thanks to Hong Kong, I have an inexpensive device that lets me use a PS2 controller on PC *AND* GameCube *AND* XBox1 (And on Wii, for the few games that are actually intelligent nough to allow GC controllers as an alternative to the piece of crap Classic Controller). I love this thing. But that would *never* happen under US-style IP law. Playing by US rules, you're not allowed to have the *basic consumer choice* of using whatever the fuck controller you want with whatever the fuck system you want. China *allows* such consumer choice. Yup: China being *more* free than the corporate-owned US. Go figure. No hardware hassles, doesn't take space under the tv. I used to have a real mess of crap in my bedroom, the cords were hideous. Now most of that is on the computer. Eeewww, I hate playing games on a PC: - Too many other processes to screw up the experience. - I spent sooo many hours every day *working* at the computer desk, I *don't* want to be be glued to it for my entertainment, too. - Even if I didn't use a PC for work, for my entertainment, I'd still much rather use a nice comfortable living room couch/TV/environment than a computer desk anyway. - Plus the non-indie commercial games come with rootkits and the requirement of buying new hardware twice a year. No thanks. The computer can also crank up the speed, which makes some of those old games so much more playable! I can't believe I used to sit there 10 hours a day and just grind or use the slow moving characters. Some of the Wii-hosted homebrew emulators will do that too :) I doubt I would have ever gotten all the way through Chrono Trigger if it weren't for that feature. I *liked* that the N64 used carts I have only one game for the N64: Perfect Dark. Bought the game when I saw it at one of the stores and picked up the system like a month later. Great game, still my favorite of the FPS genre. Yea, this is a pretty good one. Another one of my favs in Conker's Bad Fur Day. You play a cute little furry squirrel, and then you do things like get drunk so you can kill flame-based enemies by staggering around and pissing on them :) Fantastically wrong and great gameplay. It's a Rare game from back when Rare was actually still good. Actually paid $80 for that fucking game, but never regretted it.
Re: video games (was Re: UFCS for D)
Eeewww, I hate playing games on a PC: - Too many other processes to screw up the experience. Maybe if you were basing your experiences off of Windows 95. - I spent sooo many hours every day *working* at the computer desk, I *don't* want to be be glued to it for my entertainment, too. - Even if I didn't use a PC for work, for my entertainment, I'd still much rather use a nice comfortable living room couch/TV/environment than a computer desk anyway Fair enough. You can hook PCs up to a TV though, of course. . - Plus the non-indie commercial games come with rootkits and the requirement Lose the hyperbole. :P of buying new hardware twice a year. No thanks. Oh please. The hardware requirements have basically been static because of the age of the current consoles.
Re: UFCS for D
On 3/30/2012 12:36 PM, Walter Bright wrote: On 3/30/2012 12:11 PM, Steven Schveighoffer wrote: On Fri, 30 Mar 2012 14:27:43 -0400, Walter Bright newshou...@digitalmars.com wrote: I would argue that: 3. An extension method for an argument of type template parameter T will be looked up only in the instantiation scope. I don't think you looked at my counter case in detail. Your idea leads to two different instantiations of tmpl!Foo having two different implementations, depending on which extension methods you include. In fact, in one place, the instantiation might succeed, but in another, the instantiation might fail. Yes, you're right. I missed that nuance. I don't really know how to fix it. Ah, I know how to fix it. Mark such instantiations as local ones, so they are mangled with the module name of where they were instantiated from.
Re: video games (was Re: UFCS for D)
On Friday, 30 March 2012 at 22:43:00 UTC, Nick Sabalausky wrote: Oh *definitely*. BTW, Wii homebrew is *fantastic* for that. I don't have one of those thingys though. But that would *never* happen under US-style IP law. You know what's funny: I used to use an Atari ac adapter for my Sega. (still do, when I actually use the thing) The Internet tells me that Sega controllers work in Ataris too! Accidental compatibility there! - I spent sooo many hours every day *working* at the computer desk This is one reason why I actually like staying at the computer: I can keep an eye on my email in the corner. I often tell people I have to get back to the computer so I can pretend to work for a while. They laugh - I work via the internet, so I don't have to *pretend*, since there's no one there to see it. Of course, often I actually do work and just don't want to admit it. But, sometimes I actually do pretend. The way I do that is by keeping the email window open and answering requests, bugs, etc. as a kind of low priority process. When they interrupt me, I'll handle it, then get back to what I was otherwise doing. Thus, pretending to work. It looks like I'm on top of things, in reality, I'm goofing off on the video game, a side project, the television, or the newsgroup or whatever. Parking my butt in the computer chair means I can do all that, and I keep the game in a corner window on the screen, so I can see everything else going on too. - Even if I didn't use a PC for work, for my entertainment, I'd still much rather use a nice comfortable living room couch/TV/environment My computer chair is probably the nicest furniture I own... In my house's big room, I have a floor bed: a couple blankets and pillows on the floor, next to my big tv. (my big tv being a 20 year old 19 set! I'll use it till it dies. Then duct tape it back together and get a few more years out of it.) Anyway, the floor bed is brilliant, but I like my chair too. Besides it's just that I always feel like I *should* be working, or at least available in case something comes up, and if I'm sitting at the computer, at least I can pretend to be... - Plus the non-indie commercial games come with rootkits and the requirement of buying new hardware twice a year. No thanks. Eh, I just stick to the old stuff. The newest computer game I've played is either Starcraft or Worms. BTW, Worms 2, now there's a great game. I hear they are doing a new 2d Worms game, written in D. I look forward to it. (totally on topic now :P) I doubt I would have ever gotten all the way through Chrono Trigger if it weren't for that feature. huh, Chrono Trigger moves pretty quickly. I don't mind it at regular speed at all. Unless you were playing the AWFUL playstation version. The super nintendo one was pretty well paced. The events moved along quickly, the characters moved at a good speed, and most importantly, NO LOAD TIME. A friend of mine years ago liked my super nintendo version and saw a playstation port come out. He bought it. And I couldn't even look at it. It took literally *minutes* to load the initial game, and several full seconds to do stuff in the game! In the original one, you bump into a monster, and instantly, swords come out, the music changes, and you can hold in the button to get it over with. In the playstation one, you move... it pauses to load. You finally bump into the monster. It STOPS THE WORLD, seeks the disc, finally the music changes, wait a bit longer, and FINALLY the swords come out. Don't use the magic though, it will have to load some more. Fucking unbearable. You'd think they would cache this or something. Nope. Go to the next screen, bump a monster... and WAIT AGAIN. What the /hell/. I know the playstation wasn't exactly the beefiest hardware ever made, but come on. Ironically, they also bundled final fantasy 4 in that same sale, and this one was bearable. (I actually bought this disc from him.) It took great aeons to initially load, but once you got started, it played normally. You could even take the CD out for the most part and still play it, proving they loaded the whole game into memory up front. Actually, it was pretty good. How could they do a good job on one game, but so horribly drop the ball on a similar game that came in the /same box/? Ridiculous. Since I'm talking about final fantasy, I played their playstation games to, #7, 8, and 9. I've played 7 and 8 more than once, but haven't gotten myself to try 9 again (despite it sitting next to me for years now. Seriously, I can reach it right now!) I didn't love 9 the first time I played it, but I went into it with a bad attitude too - my dad paid the full $40 for it instead of waiting a year for it to drop to $20. That annoyed the crap out of me. Now I'm more angry that I was so rude about it than anything else; he tried to get a fancy expensive christmas present, and my response was not nice at all. Aaaanyway, two objective
Re: video games (was Re: UFCS for D)
Bernard Helyer b.hel...@gmail.com wrote in message news:jiioyfihtaqhpjafg...@forum.dlang.org... Eeewww, I hate playing games on a PC: - Too many other processes to screw up the experience. Maybe if you were basing your experiences off of Windows 95. Actually, it was pretty good back then, I'm thinking more the past 10 years. There's too much background crap that's always running now, not to mention programs completely hoarding as many resoruces and CPU power as the possibly can. Back with 95/98, there were what, three basic processes that were always running? I used to even have them memorized. Now it's probably around 10x times that, plus god-knows how many services, and half of it's all written in a the hell with efficiency style. - I spent sooo many hours every day *working* at the computer desk, I *don't* want to be be glued to it for my entertainment, too. - Even if I didn't use a PC for work, for my entertainment, I'd still much rather use a nice comfortable living room couch/TV/environment than a computer desk anyway Fair enough. You can hook PCs up to a TV though, of course. Yea, and I can replace my car's steering wheel with a one of those big wooden things things they used to use on boats ;) My point being, yes, it's technically doable, but to make it work *well* is too much of a DIY project. (Plus it's not really doable for me since the shithole I've got here has knob-and-tube wiring pretty much everywhere but my computer desk, so nothing three-prong will work in the living room, so it'd have to be a laptop). Something like a softmodded Wii, OTOH, is cheap, quick, easy, and has great results. (*Really* looking forward to the Raspberry Pi, though.) . - Plus the non-indie commercial games come with rootkits and the requirement Lose the hyperbole. :P There's no hyperbole there. PC gaming DRMs have been *known* to be implemented as rootkits. That's plain fact. That's one of the reasons people pirate PC games they've already legitimately bought - because it doesn't have DRM, and therefore doesn't go screwing around with their kernel. of buying new hardware twice a year. No thanks. Oh please. The hardware requirements have basically been static because of the age of the current consoles. Even if that's true, it's too little, too late. Once bitten, twice shy.
Re: How to use D for cross platform development?
On 2012-03-29 21:03, Bennie Copeland wrote: Thanks for your help. My primary use case is to provide a native look and feel GUI on the Mac. So, to the extent of creating the interface using Cocoa and tying it back to the core code written in D. In that case you would, hopefully, only need a new functions declared as extern (C) in the D code which the Objective-C code calls. Make the separation as clear as possible and make the interaction between the languages minimal. -- /Jacob Carlborg
Re: How to use D for cross platform development?
On 2012-03-29 21:45, Gour wrote: On Thu, 29 Mar 2012 21:03:05 +0200 Bennie Copelandmugen.kano...@gmail.com wrote: Thanks for your help. My primary use case is to provide a native look and feel GUI on the Mac. So, to the extent of creating the interface using Cocoa and tying it back to the core code written in D. Have you considered using wxD? New version on which Andrej is working at the moment will support wx-2.9.x/3.0 for which there is new Cocoa port. That would be another idea. It would also be possible to add some Objective-C code, or D code that calls Objective-C code, to do some platform specific functionality that wxD and wxWidget can't handle. -- /Jacob Carlborg
Re: Having trouble setting up libcurl on Windows 7
Hi guys! Brad Anderson Wrote: On Thu, Mar 15, 2012 at 3:10 AM, Gavin wzy17...@gmail.com wrote: 2.058 for Windows was released without std.net.curl built in. You'll have to rebuild phobos to get it working. It's not too hard though. I tried to rebuild Phobos using the instructions from this thread, but I didn't manage to get it work. More information about the errors is in this thread: forum.dlang.org/thread/rugjkrsqbnwlzlcsv...@forum.dlang.org#post-rugjkrsqbnwlzlcsvbss:40forum.dlang.org Maybe somebody who managed to get it built correctly can share phobos.lib for Windows 7 with curl support, please?
structs, tids, and concurrency.
Nesting a Tid in a struct is interpreted as having local
aliasing, though a bare Tid is not.
This doesn't work, though commenting out receiveOnly!S() and
tid.send(S(thisTid)) works:
-
import std.stdio;
import std.concurrency;
void main() {
auto thread = spawn(function void(Tid tid)
{
tid.send(thisTid);
tid.send(S(thisTid));
}, thisTid);
receiveOnly!Tid();
receiveOnly!S();
}
struct S {
Tid tid;
}
-
$ rdmd test.d
/usr/share/dmd/src/phobos/std/concurrency.d(319): Error: static
assert Aliases to mutable thread-local data not allowed.
../test.d(9):instantiated from here: send!(S)
Failed: dmd -v -o- '../test.d' -I'..' ../test.d.deps
Re: structs, tids, and concurrency.
On 03/30/2012 10:18 AM, Nathan M. Swan wrote: Nesting a Tid in a struct is interpreted as having local aliasing, though a bare Tid is not. http://d.puremagic.com/issues/show_bug.cgi?id=4957
Re: How to use D for cross platform development?
That's all great stuff. Thanks guys. I think in this respect D could really take off, i.e. as the natively compiled, portable core language that can easily interface to platform specific frameworks through C and C++. This, among other things, got me interested in D in the first place. I think developers are less and less willing to re-implement their programs (or portions of it) for each platform – especially now that mobile devices add yet another array of OSes to the market. It's a question of time, money, maintenance and last but not least of trying to avoid more work (doing the same thing really).
Re: How to use D for cross platform development?
On 2012-03-29 16:36:55 +, Jacob Carlborg d...@me.com said: Both I and Michel have created an Objective-C/D bridge that uses this approach. It lets you call Objective-C methods, create instances of Objective-C classes, create subclasses in D that inherit from Objective-C classes and so on. It did this all automatically. The problem with the bridge was the enormous template bloat. A GUI Hello World application takes around 60MB with the bridge. http://www.dsource.org/projects/dstep http://michelf.com/projects/d-objc-bridge/ All true. The tricky thing with Objective-C is that you need to subclass Objective-C classes to make use of Cocoa. It's that mechanism that let you create a D subclass of a Objective-C class that is so heavyweight, and also not very efficient. Just calling Objective-C code is relatively easy in D if you don't need to subclass, but it won't take you very far. That's why Michel started the DMD fork to directly support binding to Objective-C classes and methods. Indeed. And the approach makes much more sense. Only I don't really have time for compiler hacking these days. I still hope I'll be able to continue it later this year. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: How to use D for cross platform development?
On 2012-03-30 13:09, Michel Fortin wrote: Indeed. And the approach makes much more sense. Only I don't really have time for compiler hacking these days. I still hope I'll be able to continue it later this year. I don't know if you have seen this, but I took the liberty to add your project as an idea for GSOC 2012: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas#Objective-Csupport I hope it's Ok :) -- /Jacob Carlborg
Re: Documentation Layout
Am Wed, 28 Mar 2012 18:40:17 +0200 schrieb Nathan M. Swan nathanms...@gmail.com: That's pretty cool! I especially like the categories idea; it reminds me of Apple's documentation for Cocoa. It really helps you when you are thinking I need a function which does NMS Unfortunately the function that reads a file in chunks is a _struct_ called (lower case) chunks. The function that returns the current time is a method of the class Clock. Categories help us to divide and conquer the documentation, but it can still be misleading at times. This is mostly due to the flexibility of the language, that allows to use structs as functions (opCall), classes as namespaces (static methods) as well as templates. On top of that there are concepts that are spread out over several modules. Especially string handling which is in both std.string and std.array. Other such cases can be found with std.range/std.algorithm, I/O and numerics. Seriously, I think the way modules are complementing one another make it a bad approach in the long run to only document separate modules. There have been a few attempts at making DDoc more digestible. My approach would be: 1. List use cases: * What's the parameter order of function X? * Give me an overview over [string manipulation|range algorithms|...]. * What is contained in/the purpose of module X? * more? 2. Find out what is required to support each use case * Proposed concepts section? * Wiki pages/links * External DDoc files to allow documenting outside the constraints of a single module? * ... 3. Check back with what is already there and how to extend it -- Marco
Re: Documentation Layout
On 3/30/12, Marco Leise marco.le...@gmx.de wrote: snip Here's another mind-bender: import std.typetuple; Tuple!(int, int) x; // bz It's in std.typecons of all places. I would assume a tuple would be in a module called typetuple, but no.
Re: DIP16: Transparently substitute module with package
Le 30/03/2012 16:46, Andrei Alexandrescu a écrit : Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Destroy! Andrei I was waiting for it :D First, as all.d is already a convention in many D projects, why choose package.d ? I understand this is a keyword, but this will also be painfull for many developer. Second, what the rule of a .d file and a folder existing, but in different path (think -I switch of the compiler). In the first place, is the module declaration really usefull ? About the lookup rule, I understand that if I import a.b and use the function a.b.c.foo , then i must be able to refers to it as a.b.foo, but why a.foo ? It seems to me like going too far in the modification for no benefit (it can only increase the number of collision, and has no benefit I can think of).
Re: How to use D for cross platform development?
On 2012-03-30 12:34:50 +, Jacob Carlborg d...@me.com said: On 2012-03-30 13:09, Michel Fortin wrote: Indeed. And the approach makes much more sense. Only I don't really have time for compiler hacking these days. I still hope I'll be able to continue it later this year. I don't know if you have seen this, but I took the liberty to add your project as an idea for GSOC 2012: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas#Objective-Csupport I hope it's Ok :) I had not seen this. Great idea! -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DIP16: Transparently substitute module with package
On 03/30/2012 04:46 PM, Andrei Alexandrescu wrote: Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Destroy! Andrei Those are two proposals. I think the first one should be implemented. I don't really like the second one. 1. It is an over-general solution, because it does not solve a general problem. 2. Library writers lose control. All symbol names in the package are reserved when the package is deployed. It will be a breaking change to introduce a sub-package that happens to have the same name as some symbol defined in any module in the same package hierarchy. 3. symbol lookup is already hard enough to get right, because compile time reflection and conditional code generation can introduce ambiguities and contradictions. DMD does not get it right. It is likely that this change would make fixing this in a general but not-too-conservative way considerably harder. Maybe it would be better to just interpret foo.bar.baz as foo.bar.package.baz if foo.bar is a package that has been imported via the foo.bar.package rewrite? Of course, issue 2 probably would remain.
Re: Official deprecation dates, -property
Am Wed, 21 Mar 2012 03:30:02 +0100 schrieb bearophile bearophileh...@lycos.com: Here I have used () on a property. Currently -property enforces the usage of () on non-properties. But my logic tells me that it should also do the opposite and show an error if you use () with a @property method. What do you think? Here Jonathan M Davis has reminded me that TDPL asks for this second part too of the property enforcement: http://d.puremagic.com/issues/show_bug.cgi?id=7723#c4 Bye, bearophile IIRC a.functionPtrProperty()(); is required to call a function pointer stored in a property? To me a @property is a getter/setter where the setter takes one parameter and the getter has no arguments. By that logic only the syntax without () is required and ambiguities are avoided. (That's me being influenced by Delphi and C# properties) -- Marco
Re: DIP16: Transparently substitute module with package
On second thought, issue 2 is probably not that much of a problem.
Re: DIP16: Transparently substitute module with package
On 30/03/2012 15:46, Andrei Alexandrescu wrote: Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Destroy! Andrei The proposal doesn't say what happens when package.d is not found but foo/bar/ exists. Given that a lot of people will just use public import foo.bar.*; in that file, would it make sense for package.d missing to imply import foo.bar.*? That would save typing out every single file in there. Of course it would also be annoying if you wanted to import everything except one file, as you'd then have to type out every single import anyway. The other option is to error, which is probably a more sane option. -- Robert http://octarineparrot.com/
Re: DIP16: Transparently substitute module with package
On Fri, 30 Mar 2012 10:46:19 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). I think package.d should be allowed to specify module. Otherwise, something like /usr/include/d/std/datetime/package.d, what is the assumed package? If module is not useful here, it is not useful anywhere. I think the omission should be strictly anything after the package directory. For example, if you have std/algorithm/package.d and std/algorithm/sorting.d, where package.d imports sorting.d, you can refer to std.algorithm.sorting.sort by omitting sorting, but not by omitting algorithm or std. Other than that, this is a good change. -Steve
Re: Having trouble setting up libcurl on Windows 7
On Fri, Mar 30, 2012 at 1:52 AM, Gleb s4mm...@gmail.com wrote: Hi guys! Brad Anderson Wrote: On Thu, Mar 15, 2012 at 3:10 AM, Gavin wzy17...@gmail.com wrote: 2.058 for Windows was released without std.net.curl built in. You'll have to rebuild phobos to get it working. It's not too hard though. I tried to rebuild Phobos using the instructions from this thread, but I didn't manage to get it work. More information about the errors is in this thread: forum.dlang.org/thread/rugjkrsqbnwlzlcsv...@forum.dlang.org#post-rugjkrsqbnwlzlcsvbss:40forum.dlang.org Maybe somebody who managed to get it built correctly can share phobos.lib for Windows 7 with curl support, please? Sorry for the trouble. I should have checked this before I gave you the instructions. The win32.mak replacement I offered you was actually created from HEAD, not the v2.058 tag so it included the removal of the __fileinit stuff that didn't happen until after 2.058. You can find a proper win32.mak here: https://gist.github.com/3816217ffd041d62d6bd For anyone coming across this thread from the archive, use the patch file also in the above link instead of the whole file replacement. Unfortunately 2.059 won't include the changes (I'm kind of at a loss with how to proceed) but the win32.mak differs from the 2.058 version so using the patch is necessary in order to not break things. Regards, Brad Anderson
Re: DIP16: Transparently substitute module with package
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that you could do:
import std.algorithm; // has indexOf
import std.string; // has indexOf
void main() {
string.indexOf(foo, foo); - std.string.indexOf
}
That would ease usage of Phobos a little bit. OTOH 'string' already is
a keyword and things might get hairy..
Still this is one of the few proposals I like. My only caveat is the
comment: except the file is not allowed to use the module
declaration.. Wouldn't it be better if we explicitly declared a
module as a package instead? In foo\bar\package.d:
package foo.bar;
Since the module declaration must be on the first line (or second
line after shebang), you could special-case DMD to allow the package
keyword to be used here. I know D likes to abuse a keyword for
multiple things (hello Mr. Static!), but I think we could live with
it.
Re: DIP16: Transparently substitute module with package
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that you could do:
import std.algorithm; // has indexOf
import std.string; // has indexOf
void main() {
string.indexOf(foo, foo); - std.string.indexOf
}
I was actually kind of surprised when I found out this doesn't work. It
seems so natural to resolve ambiguity using as little context as necessary.
That would ease usage of Phobos a little bit. OTOH 'string' already is
a keyword and things might get hairy..
Still this is one of the few proposals I like. My only caveat is the
comment: except the file is not allowed to use the module
declaration.. Wouldn't it be better if we explicitly declared a
module as a package instead? In foo\bar\package.d:
package foo.bar;
Since the module declaration must be on the first line (or second
line after shebang), you could special-case DMD to allow the package
keyword to be used here. I know D likes to abuse a keyword for
multiple things (hello Mr. Static!), but I think we could live with
it.
Re: Having trouble setting up libcurl on Windows 7
On Friday, 30 March 2012 at 17:19:30 UTC, Brad Anderson wrote: You can find a proper win32.mak here: https://gist.github.com/3816217ffd041d62d6bd It worked like a charm! Thanks a lot!
Re: DIP16: Transparently substitute module with package
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Btw, I bet with the help of hackers like e.g. Kenji Hara we'll have this implemented in a matter of days (if it gets accepted). Compare that to having a C++ committee that would spend the next 5 years writing a 100-page spec on what is or isn't a package, heheh. Didn't Bjarne say on Going Native that he doesn't really know what a module is or should be? He should try D sometime. ;)
Re: git dmd broken for posix?
On 3/28/2012 8:18 AM, Trass3r wrote: The autotester has been showing a broken dmd testsuite for a while: http://d.puremagic.com/test-results/ Any bugzilla entry/pull request I may have missed? My fault. It's all green now.
Re: DIP16: Transparently substitute module with package
On Friday, March 30, 2012 09:46:19 Andrei Alexandrescu wrote: Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Destroy! The first part with package.d seems like a good idea and certainly affects some of what I've been doing with std.datetime. In order to split it right now, you need a new package name, leaving the original for importing everything, and this provides a better way of dealing with that. However, I'm very nervous about the second part. e.g. std.sort instead of std.algorithm.sort seems like a bad idea to me. It increases the odds of name conflicts for little benefit. Not to mention, it'll make it a lot more confusing to find what modules stuff is actually in if people start doing stuff like std.sort(arr); In the case of sort, you may know where it's from - particularly since it's so common - but the less well-known the function is, the less likely that is at all obvious where it comes from, and if you're dealing with 3rd party software, then it wouldn't be at all obvious. For instance, how would you know that party.foo is really party.bar.foo? You wouldn't. Being so lax about importing could really harm code readibility (and maintainibility, since it increases the odds of name clashes). So, I'm inclined to say that that is a _bad_ idea. I'd propose that we make it so that if a module publicly imports another module, then you could treat it as if it were in that module. So, because std.datetime.package publicly imports std.datetime.systime, you could use std.datetime.SysTime instead of std.datetime.systime.SysTime. The compiler would need to realize that they're exactly the same symbol (we've had bugs relating to importing with : and the like which ended up creating new symbols, and we don't want that here), but that shouldn't be all that hard. That gives you control over which symbols are able to be treated as if they were in a given package rather than affecting everything indiscriminitely (and if you use : with public imports, it should then be possible, to restrict it to the _exact_ set of symbols that you want if you don't want all of the symbols to be treated as if they were in that module). Another question is how this affects the documentation. Does package.d generate a page just like the other modules do? The lack of a module declaration could make that difficult (not impossible, but it would probably require changes to ddoc in addition to the module stuff). Also, does that page get treated in any special manner in how the documentation is laid out, because it's for the package as a whole (probably more of a site question than a ddoc one though)? I'd like to be able to have a page describing the package as a whole for std.datetime in addition to having the individual pages rather than just splitting it up, and leaving the programmer to read each of the individual pages with no overview. And I think that however package.d works, it needs to enable that. - Jonathan M Davis
Re: DIP16: Transparently substitute module with package
On Friday, March 30, 2012 20:06:57 Andrej Mitrovic wrote:
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that you could do:
import std.algorithm; // has indexOf
import std.string; // has indexOf
void main() {
string.indexOf(foo, foo); - std.string.indexOf
}
No, I don't think so. If I understand the proposal correctly, it would enable
std.indexOf (which doesn't help you at all in this case), not string.indexOf.
It's trying to make it so that you can treat a symbol in a sub-module as it
were in a higher module, and string.indexOf doesn't help with that at all.
- Jonathan M Davis
Re: DIP16: Transparently substitute module with package
On Friday, March 30, 2012 12:15:44 Brad Anderson wrote:
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/30/12, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that you could do:
import std.algorithm; // has indexOf
import std.string; // has indexOf
void main() {
string.indexOf(foo, foo); - std.string.indexOf
}
I was actually kind of surprised when I found out this doesn't work. It
seems so natural to resolve ambiguity using as little context as necessary.
It would certainly be desirable in some cases, but I believe that the reason
that it doesn't work is due to the ambiguities that it would create. I'd have
to go dig up old discussions on it though to remember all of the details.
alias is supposed to solve the problem, but it doesn't really work all that
well for it, since private doesn't hide symbols, it only makes them
inaccessible (just like with C++). So, creating aliases in a module causes
problems in other modules that import that module, even if the aliases are
private. There are definitely some folks pushing for private to actually start
hiding symbols (IIRC, there's even a pull request for it), but I don't know
what the odds of convincing Walter are. If/Once that happens, alias will
actually become usable for this sort of situation, and the inability to do
string.indexOf won't be as big a deal.
- Jonathan M Davis
Re: DIP16: Transparently substitute module with package
On Friday, 30 March 2012 at 18:39:44 UTC, Jonathan M Davis wrote: I'd propose that we make it so that if a module publicly imports another module, then you could treat it as if it were in that module. So, because std.datetime.package publicly imports std.datetime.systime, you could use std.datetime.SysTime instead of std.datetime.systime.SysTime. I'm not sure if that's a good idea. I'd prefer a new kind of import statement, perhaps something like: // module std.datetime.package alias import std.datetime.systime; which is similar to a public alias of everything in that module?
Re: DIP16: Transparently substitute module with package
On 3/30/12 1:39 PM, Jonathan M Davis wrote: However, I'm very nervous about the second part. e.g. std.sort instead of std.algorithm.sort seems like a bad idea to me. It increases the odds of name conflicts for little benefit. Example? Not to mention, it'll make it a lot more confusing to find what modules stuff is actually in if people start doing stuff like std.sort(arr); In the case of sort, you may know where it's from - particularly since it's so common - but the less well-known the function is, the less likely that is at all obvious where it comes from, and if you're dealing with 3rd party software, then it wouldn't be at all obvious. For instance, how would you know that party.foo is really party.bar.foo? You wouldn't. Why should you? Being so lax about importing could really harm code readibility (and maintainibility, since it increases the odds of name clashes). So, I'm inclined to say that that is a _bad_ idea. Maybe if you produce a solid example, I'd be convinced. Andrei
Re: DIP16: Transparently substitute module with package
My comments: 1. My first impression was that using foo/bar/package.d instead of foo/bar.d seemed a bit odd and messy. But I realize now that cleverly solves the issue where foo/bar.d would be considered to be inside a different package from foo/bar/*.d. So I like that. Personally, I think I would have gone with foo/bar/_.d as that sorts much, much better, but naming debates can go on forever, and I can live with package.d 2. I don't understand any of this: --- When looking up the symbol foo.bar.baz, currently an exact match is needed. However. when looking up .baz or simply baz, a flexible lookup is used that has many advantages (less verbose, hijacking detection etc). Therefore we think similar flexibility should be imparted to foo.bar.baz, as follows: If a qualified symbol foo.bar.baz appears in code, the compiler considers foo.bar a prefix that sets the starting point of the lookup, and then proceeds with looking up baz from that starting point. That means a program that imports std.algorithm may use std.sort for the symbol std.algorithm.sort. --- I *do* understand a program that imports std.algorithm may use std.sort for the symbol 'std.algorithm.sort', and I think that's a good idea. It solves a problem I hadn't even thought of. But I don't understand that stuff I quoted above. Perhaps you could reword/clarify? 3. Other than that stuff, I'm very much in favor of this. I'll have some of that!
Re: DIP16: Transparently substitute module with package
On Friday, 30 March 2012 at 18:15:57 UTC, Brad Anderson wrote:
On Fri, Mar 30, 2012 at 12:06 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
On 3/30/12, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Destroy!
That means a program that imports std.algorithm may use
std.sort
for the symbol std.algorithm.sort.
That's quite interesting. Would that also mean that you could
do:
import std.algorithm; // has indexOf
import std.string; // has indexOf
void main() {
string.indexOf(foo, foo); - std.string.indexOf
}
I was actually kind of surprised when I found out this doesn't
work. It
seems so natural to resolve ambiguity using as little context
as necessary.
Ya that was the behavior I expected as well. Would be great if it
worked like that. Just back trace the reference until the
ambiguity is resolved.
// -
Also, I'm probably missing something here, but I never understood
why importing a package doesn't work like it does in
Actionscript/Java/others...
import foo.bar.*; // everything
import foo.bar.all; // custom
That makes a lot of sense to me.
Nested function bug?
I ran into a strange and hard-to-describe problem with nested functions
closing over the argument to their enclosing function.
When a nested function (A) returns the value of another nested function
(B) that returns a parameter of the enclosing function (C), and when (A)
is returned from (C), then calling (A) returns an incorrect value if (A)
has a parameter of class type (it works when (A) has no class parameters).
The code below demonstrates this (using DMD 2.058, no optimizations). Is
this a bug?
auto foo(T)(int val)
{
int nested()
{
return val;
}
int escaping(T ignored)
{
return nested();
}
return escaping;
//return nested; // this works
}
struct Bar {}
class Baz {}
void main()
{
auto func1 = foo!int(55);
auto val1 = func1(12);
assert(val1 == 55); // works fine with integral type
auto func2 = foo!Bar(55);
Bar bar;
auto val2 = func2(bar);
assert(val2 == 55); // works fine with struct
auto func3 = foo!Baz(55);
auto baz = new Baz();
auto val3 = func3(baz);
assert(val3 == 55); // fails; val3 is different value on each run
}
rdmd
I suggest to add following line on top of rdmd main(): compiler = std.path.buildPath(std.path.dirName(args[0]), dmd);
Re: Nested function bug?
On 3/30/2012 1:13 PM, Ed McCardell wrote: I ran into a strange and hard-to-describe problem with nested functions closing over the argument to their enclosing function. When a nested function (A) returns the value of another nested function (B) that returns a parameter of the enclosing function (C), and when (A) is returned from (C), then calling (A) returns an incorrect value if (A) has a parameter of class type (it works when (A) has no class parameters). The code below demonstrates this (using DMD 2.058, no optimizations). Is this a bug? Looks like one. Please report this to http://d.puremagic.com/issues/enter_bug.cgi?product=D
Re: Nested function bug?
On 3/30/12, Ed McCardell edmcc...@hotmail.com wrote: The code below demonstrates this (using DMD 2.058, no optimizations). Is this a bug? You mean the result is 55 when you uncomment return nested;? All asserts pass for me when I use that return. Otherwise when using return escaping; I get: 1244764 1244764 4202631 2.058 win32.
Re: Nested function bug?
On 03/30/2012 04:51 PM, Andrej Mitrovic wrote: You mean the result is 55 when you uncomment returnnested;? All asserts pass for me when I use that return. Otherwise when using returnescaping; I get: 1244764 1244764 4202631 2.058 win32. On 64-bit linux, the first two asserts always pass using either return nested or return escaping. Just checked on 32-bit linux and I see the same behavior you are, with all three asserts failing using return escaping. --Ed
Re: DIP16: Transparently substitute module with package
Timon Gehr timon.g...@gmx.ch wrote in message news:jl4jmg$2j1r$1...@digitalmars.com... I don't really like the second one. 1. It is an over-general solution, because it does not solve a general problem. Maybe it would be better to just interpret foo.bar.baz as foo.bar.package.baz if foo.bar is a package that has been imported via the foo.bar.package rewrite? That occurred to me, and I thought about proposing the same thing you're suggesting, but on second thought I wasn't so sure: If I need to disambiguate between std.algorithm.find and foo.bar.baz.find, it might be nice to be able to just say Meh, just...that one in Phobos, ie 'std'. Or Just go with that 'foo' one. I could go either way, really.
Re: DIP16: Transparently substitute module with package
Robert Clipsham rob...@octarineparrot.com wrote in message news:jl4l5t$2m62$1...@digitalmars.com... On 30/03/2012 15:46, Andrei Alexandrescu wrote: Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Destroy! Andrei The proposal doesn't say what happens when package.d is not found but foo/bar/ exists. Given that a lot of people will just use public import foo.bar.*; in that file, would it make sense for package.d missing to imply import foo.bar.*? That would save typing out every single file in there. Of course it would also be annoying if you wanted to import everything except one file, as you'd then have to type out every single import anyway. That would effectively be the same as Java's import foo.* and a lot of people have issues with that. The other option is to error, which is probably a more sane option. That's what I'd suggest doing. Just treat it like importing any other missing package.
Re: DIP16: Transparently substitute module with package
On Friday, March 30, 2012 14:33:58 Andrei Alexandrescu wrote: On 3/30/12 1:39 PM, Jonathan M Davis wrote: However, I'm very nervous about the second part. e.g. std.sort instead of std.algorithm.sort seems like a bad idea to me. It increases the odds of name conflicts for little benefit. Example? std.sort works because there's only one sort. If there are two, you get a conflict (e.g. if you had std.path.sort which sorted paths in some path-specific manner). If std.path.sort existed now, then std.sort wouldn't work, and you'd be forced to specify std.algorithm.sort or std.path.sort, and that's fine. It would be similar to having to specify std.algorithm.indexOf when you've imported both std.string and std.algorithm. But the problem is when std.path.sort is added _later_. All of a sudden, code which used std.sort and worked is now broken. The problem does currently exist in that if we added indexOf to another module - say std.array - then code which imported either std.string or std.algorithm as well as std.array would break with the addition of std.array.indexOf, but your proposal makes it worse. Not only does it provide another way in which adding a function could result in conflicts when existing code is recompiled, but it makes it so that if you add any function anywhere in the _entire standard library_ which has the name as an existing one, you get a conflict (if anyone uses std.x rather than x or the full import path). D does a good job of providing ways to fix name conflicts, but it doesn't do a good job of preventing them when adding new symbols to a library (primarily because it doesn't use static imports by default), and your proposal makes that part of the problem worse. If std.x were to become common practice, then any time that you added a symbol to a library when that symbol was already used by another module, you'd create conflicts (combined with the fact that private doesn't hide symbol names but merely makes them inaccessible, this could result in a lot of symbol name conflicts). Not to mention, it'll make it a lot more confusing to find what modules stuff is actually in if people start doing stuff like std.sort(arr); In the case of sort, you may know where it's from - particularly since it's so common - but the less well-known the function is, the less likely that is at all obvious where it comes from, and if you're dealing with 3rd party software, then it wouldn't be at all obvious. For instance, how would you know that party.foo is really party.bar.foo? You wouldn't. Why should you? Do you know what the foo function does? If you don't, you're going to have to look it up. And if you don't know what module it comes from, you can't do that. You also have to know where foo is from if a foo function is added to another module and causes a conflict, because you're going to have to give the full import path to actually use it. That's currently true with just bare foo as well, but party.foo gives the illusion of specifying where foo is from without actually specifying where it's from. At least right now, if foo is used with its import path, you know that that's actually its import path. Also, what happens if we want to add a module named sort later? The fact that people are using std.sort means that adding std.sort as a module will break code. Granted, it's not very likely that we're going to add a module named sort, but there are plenty of other symbol names that it could happen with. But then again, if we decided to provide a module with all of the major sort algorithms, then maybe we _would_ create a module named std.sort. Just because we don't see a need now doesn't mean that we won't later. In either case, by allowing std.x where x is a symbol in any sub-module of std, you're going to create conflicts any time that you add a module which has the same name as an existing symbol anywhere in the library. Being so lax about importing could really harm code readibility (and maintainibility, since it increases the odds of name clashes). So, I'm inclined to say that that is a _bad_ idea. Maybe if you produce a solid example, I'd be convinced. Well, as I've pointed with a few examples here, your proposal will increase the chances of adding symbol conflicts any time that a symbol is added to a library all just so that you can do std.algorithm.sort instead of std.algorithm.submodule1.sort once sort has been moved to std.algorithm.sumodule1. And we could make it possible to do std.algorithm.sort without adding all of those possible conflicts. The simplest solution would simply be to make it so that if std.algorithm.sort is used, and std.algorithm is a package with a std.algorithm.package module, then the compiler looks in all of the sub-modules of std.algorithm to find sort. That solves the problem right there without increasing the odds of symbol conflicts across the entire library like your
Re: DIP16: Transparently substitute module with package
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.1240.1333130858.4860.digitalmar...@puremagic.com... Still this is one of the few proposals I like. My only caveat is the comment: except the file is not allowed to use the module declaration.. Wouldn't it be better if we explicitly declared a module as a package instead? In foo\bar\package.d: package foo.bar; Since the module declaration must be on the first line (or second line after shebang), you could special-case DMD to allow the package keyword to be used here. I know D likes to abuse a keyword for multiple things (hello Mr. Static!), but I think we could live with it. Or maybe just require the module name ends with .package
Re: DIP16: Transparently substitute module with package
On Fri, Mar 30, 2012 at 05:35:25PM -0400, Jonathan M Davis wrote: [...] But personally, I like the idea of making it so that publicly imported symbols can be accessed as if they were in the module that publicly imported them (with package.d being treated as if it had the same name as the package that it's in). That's essentially how it already works except when specifying the full import path for a symbol. And that way, you can specify in std.algorithm.package.d exactly what you want to be imported when std.algorithm is imported (including using : to restrict it to specific symbols in a module), and only those symbols will be treated as if they were part of std.algorithm - both for importing purposes and when specifying the import path when using a symbol. The library maintainer then has control over which symbols get used with which import paths. [...] +1. I also have my doubts about the wisdom of std.sort implicitly binding to std.algorithm.sort. It's nice syntactic sugar in the short term, but as Jonathan points out, it can cause headaches in the long term. I say we should hold off on that part of the proposal. T -- Microsoft is to operating systems security ... what McDonalds is to gourmet cooking.
Re: DIP16: Transparently substitute module with package
On 2012-03-30 14:46:19 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Destroy! Since you're asking… One thing the current system avoids is unresolvable symbols. If two symbol name clashes, you just qualify them fully and it'll always be unambiguous. For instance: .std.algorithm.sort(…) Now, if std.algorithm becomes both a module and a package, you could have both a sort function and a sort submodule with no way to distinguish between the two, even when fully qualified. I think this is why D does not allow modules to have the same name as packages. I understand that you try to work around this problem by inventing a .std.algorithm.package scope. Then you make it's content imported automatically inside the .std.algorithm scope for backward compatibility (and convenience). The problem is that if .std.algorithm.package contains a sort function and there is also a module called std.algorithm.sort, the fully-qualified name of that 'sort' module will become ambiguous. Moreover, whether the fully-qualified name .std.algorithm.sort is ambiguous or not depends on what modules were imported, which is not a very desirable behaviour. So to make sure there is no unresolvable fully-qualified names, when importing std.algorithm.sort the compiler should make sure that no symbol called 'sort' already exist in the .std.algorithm scope (which includes the symbols in .std.algorithm.package and all other packages inside std.algorithm). This is clearly untenable. - - - I recognize the need. If I may, I'll propose something simpler: 1. allow both std/algorithm.d and std/algorithm/sort.d to exist 2. importing std.algorithm.sort will also implicitly import std.algorithm (if it exists) and std (if it exists) 3. if any symbol of std.algorithm clash with the std.algorithm.sort module name, you get an error when importing std.algorithm.sort. Effectively, importing std.algorithm.sort becomes synonymous to importing std, std.algorithm, and std.algorithm.sort. This is what's needed to detect clashes in fully-qualified names. The only issue now (beside a few more imports) is that if std.algorithm imports any of its submodule it becomes a circular import. That's usually fine in D, but not when you have module constructors. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Nested function bug?
On 03/30/2012 04:45 PM, Walter Bright wrote: On 3/30/2012 1:13 PM, Ed McCardell wrote: The code below demonstrates this (using DMD 2.058, no optimizations). Is this a bug? Looks like one. Please report this to http://d.puremagic.com/issues/enter_bug.cgi?product=D Done: http://d.puremagic.com/issues/show_bug.cgi?id=7801
Re: rdmd
On 3/30/12 3:34 PM, zeljkog wrote: I suggest to add following line on top of rdmd main(): compiler = std.path.buildPath(std.path.dirName(args[0]), dmd); You may want to make it into a pull request. Thanks! Andrei
Re: Poll of the week - How long have you been in the D world?
On 26/03/2012 02:18, dnewbie wrote: Just out of curiosity, is D attracting new users? Are the old users running? Place your vote here http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f I see that the numbers are almost evenly balanced between the four categories. But does this really mean that we've attracted more people in the last two years than in all earlier years combined, or that an awful lot of old-timers have left? It would be good to do the poll again each year and see how the numbers compare. Stewart.
Re: Poll of the week - How long have you been in the D world?
On Fri, Mar 30, 2012 at 11:17:47PM +0100, Stewart Gordon wrote: On 26/03/2012 02:18, dnewbie wrote: Just out of curiosity, is D attracting new users? Are the old users running? Place your vote here http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f I see that the numbers are almost evenly balanced between the four categories. But does this really mean that we've attracted more people in the last two years than in all earlier years combined, or that an awful lot of old-timers have left? [...] That would be cause of great concern. Are the D1 people still around? T -- This is not a sentence.
Re: DIP16: Transparently substitute module with package
On 3/30/12 10:46 PM, Andrei Alexandrescu wrote: Starting a new thread from one in announce: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16 Please comment, after which Walter will approve. Walter's approval means that he would approve a pull request implementing DIP16 (subject to regular correctness checks). Great. Large modules are my main complaint about D. :-) If I correctly understand the second part (because I couldn't understand the text in the proposal until I read some comments here), then it makes sense. Is it like this? sort(...) - search sort in every module out there std.sort(...) - search sort in every module that's in the std package If both std.algorithm.sort and std.path.sort exist, or something like that, then you would anyway get a clash so you'd have to fully qualify it. But if std.algorithm.sort and foo.bar.sort and you'd import both: import std.algorithm.package; import foo.bar.package; and you'd wanted to use both, then it could be convenient: std.sort(...) foo.sort(...) Though I wonder if this indeed happens a lot. That's why I would wait until there's a real need for it. The main complaint people have is not having a way to import all files in a directory, which is the first point, but I never heard a complaint about the second point. Also, I think it would make sense to change the first part to this: * If the compiler sees a request for importing foo.bar and foo/bar is a directory, then automatically look for the file foo/bar/package.d. *If it doesn't exist, automatically expand the import to import all files under that directory.* If both foo/bar.d and foo/bar/ exists, compilation halts with an error. That way you have convenience and safety. Most of the time people just put in package.d a list of all the files in that directory. Maybe sometimes (not sure) people restrict that list to some modules. And in those cases you can just restrict the list in package.d Please, it's the year 2012. Compilers need to be smarter. Save people some typing time. You save them typing all the imports. But then you make them typing them in that pacakge.d file. Hmm...
Re: DIP16: Transparently substitute module with package
I'm pretty impressed with the idea, and look forward to its implementation, but I do have one question. How does this affect (if at all) the implicit friend relationship of declarations? Since package foo.bar is treated as a single module, do the classes in foo/bar/alpha.d and foo/bar/beta.d have access to each other's private members? I'm not sure whether I favor them losing or keeping their friend status. -- Chris NS
Re: Poll of the week - How long have you been in the D world?
On Friday, 30 March 2012 at 22:28:40 UTC, H. S. Teoh wrote: On Fri, Mar 30, 2012 at 11:17:47PM +0100, Stewart Gordon wrote: On 26/03/2012 02:18, dnewbie wrote: Just out of curiosity, is D attracting new users? Are the old users running? Place your vote here http://www.easypolls.net/poll.html?p=4f6fb7e5e4b04f389e5eb66f I see that the numbers are almost evenly balanced between the four categories. But does this really mean that we've attracted more people in the last two years than in all earlier years combined, or that an awful lot of old-timers have left? [...] That would be cause of great concern. Are the D1 people still around? T Some of us are -- though I don't know how many are actually still D1 people per se... I'd say most have made the jump by now. What I feel from the numbers is simply that we have a mostly steady rate of community growth.
