Walter Bright wrote in message news:lt7tan$24ei$1...@digitalmars.com...
1. I hate writing documentation. I really really hate it.
Join the club :-)
=)
Sorry you got to be the pioneer with the arrows in your back, but you've
paved the way for the rest of us.
I don't really mind, for
Kagamin wrote in message news:ujtkjzyvjhtvmcvjh...@forum.dlang.org...
On Friday, 22 August 2014 at 08:18:18 UTC, Daniel Murphy wrote:
2. These features are rather difficult to use, and I don't want people
to think they can just plug-and-play. I've spent a lot of time fighting
compiler
On Friday, 22 August 2014 at 15:06:14 UTC, Dmitry Olshansky wrote:
Example structure:
mod/package.d
mod/internal/bar.d
mod/...
I actually face it in Phobos right now, my blocked pull:
https://github.com/D-Programming-Language/phobos/pull/2412
I think, it should have structure
On Wednesday, 20 August 2014 at 14:40:34 UTC, Dicebot wrote:
On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote:
As I see on the realistic example of datetime, which is BIG,
we only need to split it into a flat set of files without an
overly deep package hierarchy.
We _may_ split it
On Wednesday, 20 August 2014 at 14:40:34 UTC, Dicebot wrote:
On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote:
As I see on the realistic example of datetime, which is BIG,
we only need to split it into a flat set of files without an
overly deep package hierarchy.
We _may_ split it
On Wednesday, 20 August 2014 at 20:39:06 UTC, Chris
Nicholson-Sauls wrote:
module foo.bar.one;
module foo.bar.internals; // package-protected utilities
module foo.bar.subpkg.two;
module foo.bar.subpkg.internals; // package-protected utilities
and module 'two' cannot access the 'bar' utilities.
23-Aug-2014 12:57, Kagamin пишет:
On Friday, 22 August 2014 at 15:06:14 UTC, Dmitry Olshansky wrote:
Example structure:
mod/package.d
mod/internal/bar.d
mod/...
I actually face it in Phobos right now, my blocked pull:
https://github.com/D-Programming-Language/phobos/pull/2412
I think, it
On Wednesday, 20 August 2014 at 14:44:21 UTC, Rory McGuire via
Digitalmars-d-announce wrote:
On Wed, Aug 20, 2014 at 4:33 PM, Kagamin via
Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Do we need a hierarchy of internals, is the problem this big?
Why
mybiglib.wisdom is
On 2014-08-23 11:12, Kagamin wrote:
If some thing is used in entire foo.bar package, then it's foo.bar's
internal, not foo.bar.subpkg's internal. I think, it's natural when the
wider the thing is used, the higher in hierarchy it sits.
A symbol declared package can only be accessed within its
On Saturday, 23 August 2014 at 09:14:13 UTC, Dmitry Olshansky
wrote:
Yes, that was my initial pull. The stuff inside was marked as
`package`, as only package.d currently has the same public API.
Then Dicebot suggested that since all modules are for the
moment internal they have to be moved
On Saturday, 23 August 2014 at 09:24:04 UTC, Jacob Carlborg wrote:
A symbol declared package can only be accessed within its own
package. It cannot be accessed from sub packages or super
packages.
I didn't know about that. Should it really work that way?
23-Aug-2014 13:33, Kagamin пишет:
On Saturday, 23 August 2014 at 09:14:13 UTC, Dmitry Olshansky wrote:
Yes, that was my initial pull. The stuff inside was marked as
`package`, as only package.d currently has the same public API.
Then Dicebot suggested that since all modules are for the moment
On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky
wrote:
For what its worth I'd _prefer_ std.regex.internal as in my
opinion internals got to be well contained. But as discussed,
`package` doesn't work this way.
It can be a philosophical matter, but in my experience grouping
by
On Saturday, 23 August 2014 at 11:04:35 UTC, Jacob Carlborg wrote:
That's what we're trying to fix with this change.
The proposal is to make internals visible to super packages, I
only wonder whether internals visible to some package should be
hidden from its subpackages.
On Thursday, 14 August 2014 at 07:51:11 UTC, Alex wrote:
On Thursday, 14 August 2014 at 07:07:59 UTC, Alex wrote:
Invoking stuff is easy. I'd rather reimplement the
communication to the dcd server instead to not get such a
bottleneck if you're on windows or typing really fast.
Executing an
Author posted part 2 http://tomerfiliba.com/blog/dlang-part2/
On 8/23/14, Adam D. Ruppe via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Author posted part 2 http://tomerfiliba.com/blog/dlang-part2/
If I read that right it seems they're using D in his startup? Pretty
cool. A bit of googling reveals the company's name is Weka.IO.
On Saturday, 23 August 2014 at 16:28:33 UTC, Adam D. Ruppe wrote:
Author posted part 2 http://tomerfiliba.com/blog/dlang-part2/
In reddit thread one of commenters complained about D performance
and linked this benchmark : https://github.com/nsf/pnoise
I tried running it and don't see
On Sunday, 24 August 2014 at 02:19:18 UTC, Dicebot wrote:
On Saturday, 23 August 2014 at 16:28:33 UTC, Adam D. Ruppe
wrote:
Author posted part 2 http://tomerfiliba.com/blog/dlang-part2/
In reddit thread one of commenters complained about D
performance and linked this benchmark :
On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky
wrote:
If the user relies that a symbol is found in
std.internal.regex.backtracking, moving it will break the code
too. So
what's the difference?
I don't see the difference. In any case user should see public
aliases and never
On Saturday, 23 August 2014 at 11:12:34 UTC, Kagamin wrote:
On Saturday, 23 August 2014 at 11:04:35 UTC, Jacob Carlborg
wrote:
That's what we're trying to fix with this change.
The proposal is to make internals visible to super packages, I
only wonder whether internals visible to some
On Saturday, 23 August 2014 at 11:08:31 UTC, Kagamin wrote:
On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky
wrote:
For what its worth I'd _prefer_ std.regex.internal as in my
opinion internals got to be well contained. But as discussed,
`package` doesn't work this way.
It can
On Saturday, 23 August 2014 at 09:00:30 UTC, Kagamin wrote:
What is difficult to find? With flat structure you have all
files right before your eyes. If you need std.datetime.systime
module, you open std/datetime/systime.d file - that's the
reason of needlessly restricting code structure with
On Sun, 24 Aug 2014 02:39:39 +
Dicebot via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
It is the same reasoning as with deep filesystem hierarchies and,
well, any data hierarchies
i already told that, but without any effects.
signature.asc
Description: PGP
24 matches
Mail list logo
