On 2012-04-02 16:31, Don Clugston wrote:

> To be brutally honest, I don't think that's got much to do with the
> language. It's got to do with Phobos adopting the Big Ball Of Mud design
> pattern. There's no reason for the existing modules to be so huge. Eg, I
> created std.internal.math so that the math modules would stay small.
> Not only are the modules huge, they import everything.

I couldn't agree more.

> I'd like to see some attempt to fix the problem within the language
> right now, before jumping straight into language changes.

That's not very hard. It will just break existing code.

-- 
/Jacob Carlborg

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message news:op.wb47llmueav7ka@localhost.localdomain...
>
> I currently have an HD tube tv which runs at 1080i.  The nice thing about tubes is that standard definition *does* look more normal in it.

Yea. They don't make them anymore though :(

> But the  bad part is that most HD signals are *expecting* you to have a flat  panel.  Whenever I watch a sports game, I get pissed that the score is cut  off by my TV because they put it on the exact edge of the picture.
>

A lot of Wii homebrew actually does that too. Annoying as hell. It's like people forgot what used to be common-knowledge design principles.

Le 02/04/2012 18:00, Jacob Carlborg a écrit :
> On 2012-04-02 16:31, Don Clugston wrote:
>
>> To be brutally honest, I don't think that's got much to do with the
>> language. It's got to do with Phobos adopting the Big Ball Of Mud design
>> pattern. There's no reason for the existing modules to be so huge. Eg, I
>> created std.internal.math so that the math modules would stay small.
>> Not only are the modules huge, they import everything.
>
> I couldn't agree more.
>

I did noticed that, but this isn't the only problem.

>> I'd like to see some attempt to fix the problem within the language
>> right now, before jumping straight into language changes.
>
> That's not very hard. It will just break existing code.
>

Yes, this is the point : refactoring a big module into submodules is hard because it break a lot of code, which is something we don't want ina standard lib for instance.

Not because it isn't possible, but because almost all D code repose on phobos, so refactoring it into submodules is likely to massively break existing code.

Andrei and Walter's proposal does not break existing code because it makes folders into modules.



On Tue, Apr 3, 2012 at 8:43 AM, deadalnix <deadalnix@gmail.com> wrote:
> Le 02/04/2012 18:00, Jacob Carlborg a écrit :
>
>> On 2012-04-02 16:31, Don Clugston wrote:
>>
>>> To be brutally honest, I don't think that's got much to do with the language. It's got to do with Phobos adopting the Big Ball Of Mud design pattern. There's no reason for the existing modules to be so huge. Eg, I created std.internal.math so that the math modules would stay small. Not only are the modules huge, they import everything.
>>
>>
>> I couldn't agree more.
>>
>
> I did noticed that, but this isn't the only problem.
>
>
>>> I'd like to see some attempt to fix the problem within the language right now, before jumping straight into language changes.
>>
>>
>> That's not very hard. It will just break existing code.
>>
>
> Yes, this is the point : refactoring a big module into submodules is hard because it break a lot of code, which is something we don't want ina standard lib for instance.
>
> Not because it isn't possible, but because almost all D code repose on phobos, so refactoring it into submodules is likely to massively break existing code.

Le 03/04/2012 09:58, Rory McGuire a écrit :
> Andrei and Walter's proposal does not break existing code because it
> makes folders into modules.
>

Yes, I was explaining why a solution is needed here.

I think the public import method is better than the one from Walter and Andrei, which is lacking in some aspects.

On 3 April 2012 19:58, Rory McGuire <rjmcguire@gmail.com> wrote:
> Andrei and Walter's proposal does not break existing code because it makes folders into modules.

Completely off topic, but can you please refrain from top-posting? Its not a big deal, just generally quoting above you is preferred.

Because it breaks the natural flow of conversation
Why shouldn't you top-post?

--
James Miller

On Apr 3, 2012 10:44 AM, "James Miller" <james@aatch.net> wrote:
>
> On 3 April 2012 19:58, Rory McGuire <rjmcguire@gmail.com> wrote:
> > Andrei and Walter's proposal does not break existing code because it makes folders into modules.
>
> Completely off topic, but can you please refrain from top-posting? Its not a big deal, just generally quoting above you is preferred.
>
> Because it breaks the natural flow of conversation
> Why shouldn't you top-post?
>
> --
> James Miller

Sure

On Apr 3, 2012 10:19 AM, "deadalnix" <deadalnix@gmail.com> wrote:
>
> Le 03/04/2012 09:58, Rory McGuire a écrit :
>
>> Andrei and Walter's proposal does not break existing code because it makes folders into modules.
>>
>
> Yes, I was explaining why a solution is needed here.
>
> I think the public import method is better than the one from Walter and
Andrei, which is lacking in some aspects.

To me that proposal is public importing. Just without breaking code. I also like it because it reminds me of __init__.py