On 8/26/14, 9:46 AM, Dicebot wrote:
...and it has just been merged! ^_^
Thanks Walter!
Nice! This felt like a glaring hole,
and you've filled it!
..and it has just been merged! ^_^
Thanks Walter!
On Tue, 26 Aug 2014 16:46:19 +
Dicebot via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
..and it has just been merged! ^_^
WOW! that's great!
Thanks Walter!
second that!
signature.asc
Description: PGP signature
On 8/26/14, 9:46 AM, Dicebot wrote:
...and it has just been merged! ^_^
Thanks Walter!
Congratulations for a job well done. -- Andrei
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
On 8/19/2014 7:01 AM, Dicebot wrote:
Walter, now that release is out can you please state your
opinion about
https://github.com/D-Programming-Language/dmd/pull/3651 ? It
is blocking Phobos
module split and decoupling.
I keep
On Sunday, 24 August 2014 at 14:15:25 UTC, Kagamin wrote:
On Sunday, 24 August 2014 at 02:22:41 UTC, Dicebot wrote:
Well difference is that internal substring in the fully
qualified name that is much more likely to tell user he is
better to not touch it. However, original Kagamin proposal of
On Sunday, 24 August 2014 at 02:22:41 UTC, Dicebot wrote:
Well difference is that internal substring in the fully
qualified name that is much more likely to tell user he is
better to not touch it. However, original Kagamin proposal of
embedding it into module names themselves does address that
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 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
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
On 8/19/2014 7:01 AM, Dicebot wrote:
Walter, now that release is out can you please state your
opinion about
https://github.com/D-Programming-Language/dmd/pull/3651 ? It
is blocking Phobos
module split and decoupling.
I keep
All I want is that whatever decision Walter makes to happen
sooner than in few years from now.
Dicebot:
All I want is that whatever decision Walter makes to happen
sooner than in few years from now.
There are other pending patches, like the support for the nice
[$] syntax by Kenji.
I keep thinking there's gotta be a way to do this without
language changes. or I keep thinking there
On Fri, 22 Aug 2014 20:48:22 +
bearophile via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
or (smart plan!) just apply the necessary PRs, build dmd from sources
and start using the features. if authors of popular libraries will do
this, there will be no choice and
On Sat, 23 Aug 2014 04:50:36 +0300
ketmar via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
to be honest, i myself is a happy user of Kenji's $ patch and
package(...) patch. yes, it costs some efforts to keep 'em up-to-date,
but hey, i have no life anyway.
signature.asc
On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
Any specific ideas? I can't imagine any clean solution - and
proposed language extensions fits naturally into existing
system without introducing any new concepts. It is also
somewhat frequently asked about in NG.
---
module
On Wed, 20 Aug 2014 07:25:43 +
Kagamin via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
but it requires to dump all 'subpackages' into one flat directory and
with ugly names.
proposed extension will not break any existing code, yet will allow much
nicer hierarchy.
On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via
Digitalmars-d-announce wrote:
but it requires to dump all 'subpackages' into one flat
directory and
with ugly names.
Huh? If std.datetime and std.regex are subpackages of `std`
package, it usually means, they should reside in `std`
On Wed, 20 Aug 2014 09:26:36 +
Kagamin via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Huh? If std.datetime and std.regex are subpackages of `std`
package, it usually means, they should reside in `std` directory,
no? And how explicit package protection can change
On Wednesday, 20 August 2014 at 09:26:37 UTC, Kagamin wrote:
On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via
Digitalmars-d-announce wrote:
but it requires to dump all 'subpackages' into one flat
directory and
with ugly names.
Huh? If std.datetime and std.regex are subpackages of
On Wednesday, 20 August 2014 at 13:05:54 UTC, Dicebot wrote:
Your proposal makes such module layout illegal:
std.package1.module1
std.package1.module2
std.package1.subpackage.module1
std.package1.subpackage.module2
(can't have symbols in subpackage that are also available to
package1 but not
On Wednesday, 20 August 2014 at 09:40:37 UTC, ketmar via
Digitalmars-d-announce wrote:
imagine mybiglib, mybiglib.internal, mybiglib.other, and each
of them
not single module, but package itself. so we have module
mybiglib.other.thingy which wants to use functions from
module
On Wednesday, 20 August 2014 at 14:25:59 UTC, Kagamin wrote:
If some utility is internal to std.package1 an used in the
entire std.package1, shouldn't it sit in std.package1? Why push
it to subpackage?
std.package1.module1
std.package1.module2
std.package1.internal - package1's internals go
On Wednesday, 20 August 2014 at 14:33:53 UTC, Kagamin wrote:
On Wednesday, 20 August 2014 at 09:40:37 UTC, ketmar via
Digitalmars-d-announce wrote:
imagine mybiglib, mybiglib.internal, mybiglib.other, and each
of them
not single module, but package itself. so we have module
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 not good?
It gets really unwieldy when you want to put a whole bunch of things into
one project
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 into flat set files (solving only part of the
problem) but
On Wed, 20 Aug 2014 14:33:52 +
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 not good?
ah, why we need such things as subdirectories at all? CP/M was fine
without concept
On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote:
It may semantically belong to subpackage but still needs to be
available to package1, something not uncommon in templated code
(subpackage is generic implementation, package1 is
specialization that still needs access to non-public
On Wednesday, 20 August 2014 at 15:13:06 UTC, Kagamin wrote:
On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote:
It may semantically belong to subpackage but still needs to be
available to package1, something not uncommon in templated
code (subpackage is generic implementation,
On 8/20/14, 7:49 AM, ketmar via Digitalmars-d-announce wrote:
On Wed, 20 Aug 2014 14:33:52 +
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 not good?
ah, why we need such
On Wednesday, 20 August 2014 at 17:19:58 UTC, Andrei Alexandrescu
wrote:
On 8/20/14, 7:49 AM, ketmar via Digitalmars-d-announce wrote:
On Wed, 20 Aug 2014 14:33:52 +
Kagamin via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
Do we need a hierarchy of internals, is the
module foo.bar.one;
module foo.bar.internals; // package-protected utilities
module foo.bar.subpkg.two;
module foo.bar.subpkg.internals; // package-protected utilities
Current situation: module 'one' cannot access the 'bar.subpkg'
utilities, and module 'two' cannot access the 'bar' utilities.
On Wed, 20 Aug 2014 10:19:59 -0700
Andrei Alexandrescu via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
No need to demean the question. It is valid. -- Andrei
sorry, i don't mean to insult anyone, just trying to make people see
analogies. hierarchies are everywhere, it's
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
On 8/19/2014 7:01 AM, Dicebot wrote:
Walter, now that release is out can you please state your
opinion about
https://github.com/D-Programming-Language/dmd/pull/3651 ? It
is blocking Phobos
module split and decoupling.
I keep
On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
On 8/19/2014 7:01 AM, Dicebot wrote:
Walter, now that release is out can you please state your
opinion about
https://github.com/D-Programming-Language/dmd/pull/3651 ? It
On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
On Tuesday, 19 August 2014 at 17:08:25 UTC, Walter Bright wrote:
On 8/19/2014 7:01 AM, Dicebot wrote:
Walter, now that release is out can you please state your
opinion about
https://github.com/D-Programming-Language/dmd/pull/3651 ? It
50 matches
Mail list logo
