On Fri, 30 Mar 2012 14:27:43 -0400, Walter Bright <newshound2@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.

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

"Jacob Carlborg" <doob@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.

"deadalnix" <deadalnix@gmail.com> wrote in message news:jl47k0$1old$2@digitalmars.com...
> 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.

Another option is to do this:

    module foo;
    public import  foo_.bar;
    public import  foo_.baz;

    module foo_.bar;
    [...]
    module foo_.baz;
    [...]

The benefit of that is that the user doesn't even have to know or case about any such conventions (actually I might do that with my libs intead of the all.d I've been using). The (somewhat small) downside though, is that anything in "foo.d" is not in the same package as "foo_/*.d", which could matter on things with the "package" access specifier. But that's easily solved by keeping "foo.d" limited to imports only.

Of course, *all* this stuff goes away if we could just simply do:

    module foo;
    public import  foo.bar;
    public import  foo.baz;

    module foo.bar;
    [...]
    module foo.baz;
    [...]

Which IMHO seems like a simple "removing undue limitations". But maybe there's technical problems with that I haven't thought of?

On 3/30/2012 12:11 PM, Steven Schveighoffer wrote:
> On Fri, 30 Mar 2012 14:27:43 -0400, Walter Bright <newshound2@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

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:idxacwhjfymfbmezlmks@forum.dlang.org...
> 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"!

I always use rdmd to compile anything with >1 file, so tossing in more files makes absolutely zero difference to me.

"deadalnix" <deadalnix@gmail.com> wrote in message news:jl47vt$1old$5@digitalmars.com...
> Le 30/03/2012 07:29, Nick Sabalausky a écrit :
>> "Steven Schveighoffer"<schveiguy@yahoo.com>  wrote in message news:kgwyziwlndczqtafbvrf@forum.dlang.org...
>>> On Friday, 30 March 2012 at 01:55:23 UTC, Nick Sabalausky wrote:
>>>>
>>>> Yea, that occurred to me, too.<wishful musing>I'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>
>>>
>>> I don't think it was a mistake, it makes perfect sense to me.  On the
>>> other hand, I fully understand why Meyers' prescription is useful for
>>> humongous code bases.  However, I don't see this causing much trouble
>>> for
>>> code I write.
>>>
>>> For instance, you have two classes you may have put into the same module
>>> because they are categorically related (not necessarily friends in C++
>>> terms).  It's highly unlikely that you "accidentally" access private
>>> information across the classes.  So how much time is "wasted" checking
>>> the
>>> other class for external references?  Probably none.
>>>
>>
>> Large portions of D's access specifiers were completely unenforced for a long time and it never caused me much trouble. Doesn't mean they didn't still need to enforced.
>>
>>
>
> Because projects were small.

Right, my point is, just because you're not accidentally accessing things you shouldn't, doesn't mean those safeguards shouldn't still be in place. At the very least it makes it easier to reason about the code: You can just look at it and *know* there's no improper access going on. No need to tiptoe around keepng an eye out for it on the off chance that you or someone else did manage to slip something in there accidentally *or* deliberately.

"Steven Schveighoffer" <schveiguy@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 parts of it. I normally can't stand "casual" games. I can't stand Miis (got sick of them within a year of the Wii first coming out) I can't stand the non-disableable elevator music in that game. And there are a lot of stinker games in Sports Resort (Cycling anyone? Didn't think so) But I've played so much of the Bowling and Frisbee Golf it's ridiculous. The Archery, Golf, Swordfighting, and Island Flyby are surprisingly good, too. (The rest is largely forgettable, though.)

But yea, I really have gotten sick of Nintendo's bullshit:

- All their core IPs are getting systematically dumbed down.

- They never let you skip cutscenes, unless the game save says it's already shown you it...which proves they're pulling that unskippable shit *deliberately*. Truly moronic design. I don't even watch them, I just switch to a TV channel, or turn the TV off and then come back later.

- The system menu "music" that never ends.

- The endless stream of nanny health screens. There's literally *two or three* of them *every* time you turn on the system to play.

- Many game saves are *blocked* from being backed up to SD or even taken to a friend's system.

- And oh yea, you're not allow to play imports, or write software or run non-official code on a device you *legitimately own*.

Shit, they're actually *worse* than *Apple*, for fuck's sake! How the hell is that even possible?

All that crap is why I decided "Fuck you, Nintendo" and softmodded the goddamn thing. Thanks to things like Priiloader, a couple USB loader apps, Homebrew Channel and Homebrew Browser:

- I no longer have the initial startup health screen.

- I no longer have to listen to that "music" in the system menu which got painfully irritating after the first *year* of listening to it.

- I can do WTF I want with game saves.

- I can play imports. Fuck region coding.

- I can keep all my games on a USB HDD, so I:

    * Don't have to worry about the discs getting damaged.

    * OR the laser burning out (already became a problem on my XBox1, but
almost irrelevant now thanks to XBMC).

    * OR swapping discs just to play something different (seriously, WTF is
this, 1995?).

    * AND as a bonus, load times are now *much* faster.

- I can write software for it (Meh, if I ever had the time)

- I can play some very clever homebrew games like Sand Traps ( http://wiibrew.org/wiki/Sand_Traps )

Hail hackers, Fuck Nintendo's suits.

And fuck the DMCA - a completely illegitimate law and the *only* thing making *any* of this illegal.

(Plus I can discover that a game is total crap *before* blowing fifty bucks on it, instead of *after*...Not that I would do that...)

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:udpabjwyzxlollbizxzz@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 sooooo 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*.

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.

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 :-)