On Thursday, 20 June 2013 at 07:59:57 UTC, Jonathan M Davis wrote:
The _only_ reason that we added package.d was to allow us to
split up modules
in place without breaking existing code. And it works as well
as it does,
because the _only_ new feature that it provides is making it so
that when
On Thursday, June 20, 2013 08:45:21 TommiT wrote:
> On Thursday, 20 June 2013 at 05:24:12 UTC, TommiT wrote:
> > This is how I see the logic of this new feature you're adding:
> >
> > When you have a folder named "mod" which contains a file named
> > package.d, the mod folder becomes conceptually
On Thursday, 20 June 2013 at 05:24:12 UTC, TommiT wrote:
This is how I see the logic of this new feature you're adding:
When you have a folder named "mod" which contains a file named
package.d, the mod folder becomes conceptually a file with same
name and the extension "d". I.e. the folder con
Also, if we loosen the encapsulation provided by the package
access specifier so that it allows access also to modules in
nested packages, then why is this keyword even named "package".
Newcomers to the language would be asking us why is this keyword
names "package", when it provides access bey
This is how I see the logic of this new feature you're adding:
When you have a folder named "mod" which contains a file named
package.d, the mod folder becomes conceptually a file with same
name and the extension "d". I.e. the folder conceptually becomes
a module, which you can then import to
On Thursday, June 20, 2013 05:39:30 TommiT wrote:
> On Wednesday, 19 June 2013 at 22:40:47 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, June 20, 2013 00:21:45 TommiT wrote:
> >> Also, I'm just curious why do you keep saying "we don't want to
> >> complicate the package access specifier any fu
On Wednesday, 19 June 2013 at 22:40:47 UTC, Jonathan M Davis
wrote:
On Thursday, June 20, 2013 00:21:45 TommiT wrote:
Also, I'm just curious why do you keep saying "we don't want to
complicate the package access specifier any further"? Because
isn't the current specification of the package acces
On Thursday, June 20, 2013 00:21:45 TommiT wrote:
> Also, I'm just curious why do you keep saying "we don't want to
> complicate the package access specifier any further"? Because
> isn't the current specification of the package access specifier
> the simplest possible that it could ever be? "Every
On Wednesday, 19 June 2013 at 20:05:56 UTC, Jonathan M Davis
wrote:
On Wednesday, June 19, 2013 13:13:54 TommiT wrote:
On Wednesday, 19 June 2013 at 07:12:30 UTC, Jonathan M Davis
wrote:
> [..] But even if you can't, I don't think that it's worth it
> to
> complicate the package attribute any
On Wednesday, June 19, 2013 13:13:54 TommiT wrote:
> On Wednesday, 19 June 2013 at 07:12:30 UTC, Jonathan M Davis
>
> wrote:
> > [..] But even if you can't, I don't think that it's worth it to
> > complicate the package attribute any further. [..]
>
> I'd like to quote the TDPL foreword by Walter
On Wednesday, 19 June 2013 at 07:12:30 UTC, Jonathan M Davis
wrote:
[..] But even if you can't, I don't think that it's worth it to
complicate the package attribute any further. [..]
I'd like to quote the TDPL foreword by Walter:
"To the best of my knowledge, D offers an unprecedentedly adroit
On Wednesday, 19 June 2013 at 09:55:32 UTC, TommiT wrote:
Your suggestion makes breaking modules into packages easier to
understand but harder to do.
...and not to mention, just plain ugly. I mean look at how those
files that are part of a package end up being in different
folders and you hav
On Wednesday, 19 June 2013 at 07:12:30 UTC, Jonathan M Davis
wrote:
On Wednesday, June 19, 2013 08:51:38 TommiT wrote:
I can't put a member function into a different file if it's
supposed to have access to private data of its enclosing
class/struct.
Then you can put the class in a different fi
On Wednesday, June 19, 2013 08:51:38 TommiT wrote:
> On Wednesday, 19 June 2013 at 06:47:05 UTC, Jonathan M Davis
>
> wrote:
> > Then just put whatever is supposed to be shared between them in
> > the package
> > that they were both in originally. package stuff is not part of
> > the public API,
>
On Wednesday, 19 June 2013 at 06:47:05 UTC, Jonathan M Davis
wrote:
Then just put whatever is supposed to be shared between them in
the package
that they were both in originally. package stuff is not part of
the public API,
so when you're refactoring package code, you're refactoring
code that y
On Wednesday, 19 June 2013 at 06:25:02 UTC, TommiT wrote:
I don't like the extra complication either, ...
I should have said, I don't like the added complexity. But I
think this is one of those things that becomes totally obvious
once you use it for a while and get used to thinking about the
On Wednesday, June 19, 2013 08:25:00 TommiT wrote:
> > If it's worth letting nested packages have access to their
> > parent packages package-level stuff, then
> > let's just do that for everything.
>
> But this is not enough. Let's say you have modules A.d and B.d
> under the same package. Now, i
On Wednesday, 19 June 2013 at 06:25:02 UTC, TommiT wrote:
Now, if A.d uses something that is marked 'package' inside B.d,
you can't break both A.d and B.d into these new module-package
thingies without re-structuring your code.
And it may not be even possible to re-structure the code, like
wh
On Wednesday, 19 June 2013 at 05:35:17 UTC, Jonathan M Davis
wrote:
I _really_ don't like the idea of having the presence of
package.d affect the package modifier, and I don't think
that anything which controls how many levels deep the
package modifier gives the package access to is worth the ex
On Wednesday, June 19, 2013 06:49:49 TommiT wrote:
> On Thursday, 6 June 2013 at 06:09:41 UTC, Max Samukha wrote:
> > 'package' should be fixed so that 'package' declarations are
> > accessible within nested packages.
>
> I don't think the 'package' access specifier should give
> privileges to *al
On Thursday, 6 June 2013 at 06:09:41 UTC, Max Samukha wrote:
'package' should be fixed so that 'package' declarations are
accessible within nested packages.
I don't think the 'package' access specifier should give
privileges to *all* nested packages. Rather, I think we just need
to invent a
On Friday, June 07, 2013 10:55:36 nazriel wrote:
> If it was carefully discussed and I somehow missed those
> discussion or I am not allowed to see them, then I am sorry and
> please ignore this and my previous post in this topic.
Actually, Daniel Murphy, Martin Nowak, and I discussed it with Walt
On 6/7/13, nazriel wrote:
> But still it looks weird to me that allowing access to
> std.datetime.time.Clock via std.datetime.Clock, even though Clock
> is defined in std.datetime.time and std.datetime.package is only
> publicly importing it, is ok.
This could come as a benefit. For example, a us
On Thursday, 6 June 2013 at 18:10:11 UTC, Jonathan M Davis wrote:
If you have that problem, then you don't publicly import the
entire module.
It's up to the package designer to decide which portions of the
package get
publicly imported. But since std.datetime.Foo would be
ambiguous, I don't
t
On Thu, 06 Jun 2013 22:59:41 +0200, Sad panda wrote:
Can we use some other word for counterargument than destroy please. :(
(resume discussion)
But we like destroy.
--
Simen
Can we use some other word for counterargument than destroy
please. :(
(resume discussion)
On Thursday, June 06, 2013 11:16:03 Walter Bright wrote:
> On 6/6/2013 11:09 AM, Jonathan M Davis wrote:
> > We've already discussed this at length. It's possible that we missed
> > something, but this proposal is not something that we just jumped into
> > without thinking it through first. In fact
On 6/6/2013 11:09 AM, Jonathan M Davis wrote:
We've already discussed this at length. It's possible that we missed
something, but this proposal is not something that we just jumped into without
thinking it through first. In fact, it actually took quite a bit to talk Walter
into the necessity of i
On Thursday, June 06, 2013 16:53:37 nazriel wrote:
> Few issues I remember were:
>
> module std.datetime.core;
> class Foo {}
>
> module std.datetime.calendar;
> class Foo {}
>
> module std.datetime;
>
> public import std.datetime.core;
> public import std.datetime.calendar;
>
> module usage;
On Thursday, June 06, 2013 13:47:29 Andrej Mitrovic wrote:
> I've argued the same thing before. And as a cream on top I'd like
> allowing package on virtual methods. That way I can have internal
> virtual methods which can be extended in other modules or modules in
> subpackages (if the two feature
On Wednesday, 5 June 2013 at 22:31:21 UTC, Andrei Alexandrescu
wrote:
https://github.com/D-Programming-Language/dmd/pull/2139
Andrei
I had a spin[1] with it long before Adam Wilson made it so
popular topic. Feature was frequently mentioned on IRC as
desired. Unfortunately I faced few holes i
On 6/6/13, Max Samukha wrote:
> There is not much to debate. Get your hands dirty with a real
> project having more than two levels of packages and you'll see
> that the first is ultimately better.
I've argued the same thing before. And as a cream on top I'd like
allowing package on virtual metho
On Thursday, 6 June 2013 at 06:26:17 UTC, Jonathan M Davis wrote:
On Thursday, June 06, 2013 08:09:38 Max Samukha wrote:
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis
wrote:
> But I believe that package level access only works on the
> same
> level, so you
> couldn't have separate
On Thursday, June 06, 2013 08:31:57 Marco Leise wrote:
> If package is ambiguous, maybe it needs to be split in two or
> take a parameter package(std.algorithm) or something like that
> to serve both use cases.
While that might be nice, I'm inclined to think that it would be better to
avoid the e
Am Wed, 05 Jun 2013 22:35:59 -0400
schrieb "Jonathan M Davis" :
> std.compress.zlib;
> std.compress.lzw;
>
> At that point, it would be trivial to have a common module of some kind with
> shared functionality which has package access level.
>
> - Jonathan M Davis
+1
If package is ambiguous, m
On Thursday, June 06, 2013 08:09:38 Max Samukha wrote:
> On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
> > But I believe that package level access only works on the same
> > level, so you
> > couldn't have separate modules for compressing and
> > decompressing as was being
> > s
On 6/5/2013 5:13 PM, Walter Bright wrote:
On 6/5/2013 3:31 PM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/pull/2139
Well, I am destroyed. I need to do some more engineering. The problem is that
packages and modules have become conflated with this change.
Fixed
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
But I believe that package level access only works on the same
level, so you
couldn't have separate modules for compressing and
decompressing as was being
suggested.
'package' should be fixed so that 'package' declarations are
On Thursday, 6 June 2013 at 02:36:12 UTC, Jonathan M Davis wrote:
But I believe that package level access only works on the same
level, so you couldn't have separate modules for compressing
and decompressing as was being suggested. It would need to be
more like
std.compress.zlib;
std.compres
On Thursday, June 06, 2013 04:10:26 Marco Leise wrote:
> Am Wed, 05 Jun 2013 18:31:22 -0400
>
> schrieb Andrei Alexandrescu :
> > https://github.com/D-Programming-Language/dmd/pull/2139
> >
> > Andrei
>
> To those who don't want to see a < 1000 lines module: Please
> consider that as soon as we'
Am Wed, 05 Jun 2013 18:31:22 -0400
schrieb Andrei Alexandrescu :
> https://github.com/D-Programming-Language/dmd/pull/2139
>
> Andrei
To those who don't want to see a < 1000 lines module: Please
consider that as soon as we'd merge multiple compression
algorithms into one file for the sake of mak
On 6/5/2013 3:31 PM, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/dmd/pull/2139
Well, I am destroyed. I need to do some more engineering. The problem is that
packages and modules have become conflated with this change.
Andrei Alexandrescu:
https://github.com/D-Programming-Language/dmd/pull/2139
Probably you already know the following things because they see,
similar solutions.
Python uses "__init__.py" instead of "package.d", it can also be
empty:
http://docs.python.org/2/tutorial/modules.html
__init__
https://github.com/D-Programming-Language/dmd/pull/2139
Andrei
44 matches
Mail list logo
