Le 04/04/2012 15:52, Adam D. Ruppe a écrit :
On Wednesday, 4 April 2012 at 07:05:59 UTC, deadalnix wrote:
It should be provided as lib by std.traits . And no need for language
changes.
It wouldn't account for the case I actually want: checking
for export.
Good point. You are right, it is
Le 04/04/2012 19:43, Jonathan M Davis a écrit :
In Posix-land, _everything_ is exported. AFAK, this whole idea of marking
functions as exported or not is a Windows-only thing. And honestly, it's one
of my biggest complaints about programming in Windows. It's seriously annoying
to have to deal
Le 04/04/2012 04:48, Jonathan M Davis a écrit :
On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
Le 02/04/2012 22:59, Simen Kjærås a écrit :
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnixdeadal...@gmail.com wrote:
Now, there are a number of people very unhappy about this state of
affairs
Le 04/04/2012 03:04, Robert Jacques a écrit :
On Tue, 03 Apr 2012 08:30:25 -0500, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
As someone who has implemented a runtime reflection library in
D, it is entirely possible to detect
On Wednesday, April 04, 2012 09:04:41 deadalnix wrote:
Le 04/04/2012 04:48, Jonathan M Davis a écrit :
On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
Le 02/04/2012 22:59, Simen Kjærås a écrit :
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnixdeadal...@gmail.com
wrote:
Now, there are
On Wednesday, April 04, 2012 15:49:59 deadalnix wrote:
Le 04/04/2012 10:41, Jonathan M Davis a écrit :
Plus, this isn't a real issue, because the final keyword exists.
It's a _huge_ issue, because it means that nearly every single private
function in a class in D will need to be marked
On Mon, 02 Apr 2012 19:10:01 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say private
protection is that user is never ever able to see(!) it. Thus it user
can't
Le 02/04/2012 22:59, Simen Kjærås a écrit :
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix deadal...@gmail.com wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well (personally, I think that the
fact that
it makes private
Le 03/04/2012 00:00, Timon Gehr a écrit :
Making private symbols invisible to other modules or at least excluding
them from symbol clashes is necessary. The current behaviour is not
useful or desirable in any way.
This smells like religious coding to me.
NVI is perfectly possible with
On 04/03/2012 08:27 AM, deadalnix wrote:
Le 03/04/2012 00:00, Timon Gehr a écrit :
Making private symbols invisible to other modules or at least excluding
them from symbol clashes is necessary. The current behaviour is not
useful or desirable in any way.
This smells like religious coding to
On Mon, 02 Apr 2012 08:05:09 -0500, Dmitry Olshansky dmitry.o...@gmail.com
wrote:
On 02.04.2012 16:04, Adam D. Ruppe wrote:
On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say
private protection is that user is
On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
As someone who has implemented a runtime reflection library in
D, it is entirely possible to detect whether a function is
marked private/protected or not using __traits today.
How did you do it? __traits(compiles) is the best I
On Tue, 03 Apr 2012 08:30:25 -0500, Adam D. Ruppe destructiona...@gmail.com
wrote:
On Tuesday, 3 April 2012 at 13:14:00 UTC, Robert Jacques wrote:
As someone who has implemented a runtime reflection library in
D, it is entirely possible to detect whether a function is
marked private/protected
On Tuesday, April 03, 2012 08:23:49 deadalnix wrote:
Le 02/04/2012 22:59, Simen Kjærås a écrit :
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix deadal...@gmail.com wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well
On 01.04.2012 22:27, Adam D. Ruppe wrote:
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
From the test:
==
class Test {
On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say
private protection is that user is never ever able to see(!)
it. Thus it user can't depend on private members being there,
which is a good thing.
That's not the
On 02.04.2012 16:04, Adam D. Ruppe wrote:
On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say
private protection is that user is never ever able to see(!) it. Thus
it user can't depend on private members being there,
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say private
protection is that user is never ever able to see(!) it. Thus it user
can't depend on private members being there, which is a good thing.
If I read it right, the
Le 02/04/2012 19:10, Jonathan M Davis a écrit :
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say private
protection is that user is never ever able to see(!) it. Thus it user
can't depend on private members being there,
On Monday, April 02, 2012 20:02:20 deadalnix wrote:
Le 02/04/2012 19:10, Jonathan M Davis a écrit :
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say private
protection is that user is never ever able to see(!) it.
On 1 April 2012 21:27, Adam D. Ruppe destructiona...@gmail.com wrote:
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix deadal...@gmail.com wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well (personally, I think that the fact
that
it makes private aliases effectively useless is reason enough
On 04/02/2012 10:59 PM, Simen Kjærås wrote:
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix deadal...@gmail.com wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well (personally, I think that the
fact that
it makes private
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
From the test:
==
class Test {
public int a;
private int b;
export
Code: https://github.com/D-Programming-Language/dmd/pull/856
On 2 April 2012 06:27, Adam D. Ruppe destructiona...@gmail.com wrote:
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
26 matches
Mail list logo
