March 30, 2012
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
March 30, 2012
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.
March 30, 2012
On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix <deadalnix@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
March 30, 2012
Le 30/03/2012 14:13, Steven Schveighoffer a écrit :
> On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix <deadalnix@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.
March 30, 2012
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

March 30, 2012
Le 30/03/2012 02:10, Steven Schveighoffer a écrit :
> On Wed, 28 Mar 2012 20:21:41 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/
>>
>>
>> Andrei
>
> Is anyone else's computer complaining about drdobbs having an invalid
> certificate? I read the article, and then I wanted to reference it
> again, and I got the error. Now I'm hesitant to accept the certificate
> because it seems to come from a completely different site...
>
> -Steve

I have a lot of problems with drdoob, but not that one. Still, I don't what this website is made of, but it seems dangerous material. Hopefully the content is good.
March 30, 2012
On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix <deadalnix@gmail.com> wrote:

> Le 30/03/2012 14:13, Steven Schveighoffer a écrit :
>> On Fri, 30 Mar 2012 08:10:14 -0400, deadalnix <deadalnix@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
March 30, 2012
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 sooooo slowly, especially the newer games.


March 30, 2012
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
March 30, 2012
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"!