Jump to page: 1 2 3
Thread overview
traits getProtection
Apr 01, 2012
Adam D. Ruppe
Apr 01, 2012
Adam D. Ruppe
Apr 01, 2012
James Miller
Apr 02, 2012
Dmitry Olshansky
Apr 02, 2012
Adam D. Ruppe
Apr 02, 2012
Dmitry Olshansky
Apr 03, 2012
Robert Jacques
Apr 03, 2012
Adam D. Ruppe
Apr 03, 2012
Andrej Mitrovic
Apr 04, 2012
Robert Jacques
Apr 04, 2012
deadalnix
Apr 04, 2012
Adam D. Ruppe
Apr 06, 2012
deadalnix
Apr 02, 2012
Jonathan M Davis
Apr 02, 2012
deadalnix
Apr 02, 2012
Simen Kjærås
Apr 02, 2012
Timon Gehr
Apr 03, 2012
deadalnix
Apr 03, 2012
Timon Gehr
Apr 03, 2012
deadalnix
Apr 04, 2012
Jonathan M Davis
Apr 04, 2012
deadalnix
Apr 04, 2012
Jonathan M Davis
Apr 04, 2012
deadalnix
Apr 04, 2012
Jonathan M Davis
Apr 05, 2012
deadalnix
Apr 05, 2012
Martin Nowak
April 01, 2012
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 string c;
    protected int d;
    package void e() {}
}

void main() {
    Test t;
    static assert(__traits(getProtection, __traits(getMember, t, "a")) == "public");
    static assert(__traits(getProtection, __traits(getMember, t, "b")) == "private");
    static assert(__traits(getProtection, __traits(getMember, t, "c")) == "export");
    static assert(__traits(getProtection, __traits(getMember, t, "d")) == "protected");
    static assert(__traits(getProtection, __traits(getMember, t, "e")) == "package");
}
==



This will help D automatically generate things like
external interfaces that use the protections.

For instance, I plan to use it in my web.d to only
make functions marked "export" available via the
web interface. Currently, you have to use a naming
convention to hide functions - a leading underscore -
even on private members. This is ok, but not great.

But with the protection trait, we can mark it with
a much more natural "private", or any of the other
specifiers D has.


I'm sure other uses will come up too.

April 01, 2012
Code: https://github.com/D-Programming-Language/dmd/pull/856
April 01, 2012
On 2 April 2012 06:27, Adam D. Ruppe <destructionator@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.
>
> From the test:
> ==
> class Test {
>    public int a;
>    private int b;
>    export string c;
>    protected int d;
>    package void e() {}
> }
>
> void main() {
>    Test t;
>    static assert(__traits(getProtection, __traits(getMember, t, "a")) ==
> "public");
>    static assert(__traits(getProtection, __traits(getMember, t, "b")) ==
> "private");
>    static assert(__traits(getProtection, __traits(getMember, t, "c")) ==
> "export");
>    static assert(__traits(getProtection, __traits(getMember, t, "d")) ==
> "protected");
>    static assert(__traits(getProtection, __traits(getMember, t, "e")) ==
> "package");
> }
> ==
>
>
>
> This will help D automatically generate things like external interfaces that use the protections.
>
> For instance, I plan to use it in my web.d to only
> make functions marked "export" available via the
> web interface. Currently, you have to use a naming
> convention to hide functions - a leading underscore -
> even on private members. This is ok, but not great.
>
> But with the protection trait, we can mark it with
> a much more natural "private", or any of the other
> specifiers D has.
>
>
> I'm sure other uses will come up too.

Looks good, adds a lot to the compile-time reflection capabilities. My thoughts for it are similar to yours, generating bindings from "export"ed members, so you don't need to maintain separate lists or use a naming convention.

--
James Miller
April 02, 2012
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 {
> public int a;
> private int b;
> export string c;
> protected int d;
> package void e() {}
> }
>
> void main() {
> Test t;
> static assert(__traits(getProtection, __traits(getMember, t, "a")) ==
> "public");
> static assert(__traits(getProtection, __traits(getMember, t, "b")) ==
> "private");
> static assert(__traits(getProtection, __traits(getMember, t, "c")) ==
> "export");
> static assert(__traits(getProtection, __traits(getMember, t, "d")) ==
> "protected");
> static assert(__traits(getProtection, __traits(getMember, t, "e")) ==
> "package");
> }
> ==
>
>
>
> This will help D automatically generate things like
> external interfaces that use the protections.
>
> For instance, I plan to use it in my web.d to only
> make functions marked "export" available via the
> web interface. Currently, you have to use a naming
> convention to hide functions - a leading underscore -
> even on private members. This is ok, but not great.
>
> But with the protection trait, we can mark it with
> a much more natural "private", or any of the other
> specifiers D has.
>
>
> I'm sure other uses will come up too.
>

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 technique you present allows user code to depend on private functions being there.
I argue that we shouldn't even provide a _possibility_ for external stuff to depend on private members.
Same argument in limited scope goes for protected.

As for export, I thinks it looks OK.

-- 
Dmitry Olshansky
April 02, 2012
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 way it is right now in D: if you use the
reflection traits, you can see and access private members.

Worse yet, the way it is now, there's no way to tell
they are marked private when using reflection!

That's one of the reasons why I want to add this - it
lets us check.


I remember asking if private members should be hidden from
reflection before, and the answer was no - I think it had
to do with them being useful for serialization and stuff
like that.
April 02, 2012
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, which is a good
>> thing.
>
> That's not the way it is right now in D: if you use the
> reflection traits, you can see and access private members.
>
> Worse yet, the way it is now, there's no way to tell
> they are marked private when using reflection!
>

Awful.

> That's one of the reasons why I want to add this - it
> lets us check.
>
>
> I remember asking if private members should be hidden from
> reflection before, and the answer was no - I think it had
> to do with them being useful for serialization and stuff
> like that.

Now I get it, traits hasIndirections would need it too, and it's too big a feat to lose it.

-- 
Dmitry Olshansky
April 02, 2012
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 technique you present allows user code to depend
> on private functions being there.
> I argue that we shouldn't even provide a _possibility_ for external
> stuff to depend on private members.
> Same argument in limited scope goes for protected.

As it stands, private has _no_ effect on symbol visibility. All it affects is symbol accessibility. For instance, if you create a private alias in a module, it affects every module that imports your module, or if you create a function which causes an overload conflict, it creates an overload conflict regardless of whether it's private or not. C++ is the same way. Access modifiers are just that, _access_ modifieres. They _only_ affect accessibility, not visibility.

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 to seriously reconsider the current behavior), but I don't know if there's any real chance of convincing Walter or not.

- Jonathan M Davis
April 02, 2012
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, which is a good thing.
>> If I read it right, the technique you present allows user code to depend
>> on private functions being there.
>> I argue that we shouldn't even provide a _possibility_ for external
>> stuff to depend on private members.
>> Same argument in limited scope goes for protected.
>
> As it stands, private has _no_ effect on symbol visibility. All it affects is
> symbol accessibility. For instance, if you create a private alias in a module,
> it affects every module that imports your module, or if you create a function
> which causes an overload conflict, it creates an overload conflict regardless of
> whether it's private or not. C++ is the same way. Access modifiers are just
> that, _access_ modifieres. They _only_ affect accessibility, not visibility.
>

Reflection should reflect what the reflectee is. Private stuff are part of the reflectee.

> 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 to seriously
> reconsider the current behavior), but I don't know if there's any real chance
> of convincing Walter or not.
>

This would be a huge mistake. For instance, private method are sometime meant to be overridden in subclasses, which is impossible if symbol is inaccessible.

NVI for instance would be impossible in such a situation.
April 02, 2012
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix <deadalnix@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 to seriously
>> reconsider the current behavior), but I don't know if there's any real chance
>> of convincing Walter or not.
>>
>
> This would be a huge mistake. For instance, private method are sometime meant to be overridden in subclasses, which is impossible if symbol is inaccessible.
>
> NVI for instance would be impossible in such a situation.

NVI is perfectly possible with protected.
April 02, 2012
On 04/02/2012 10:59 PM, Simen Kjærås wrote:
> On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix <deadalnix@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 to
>>> seriously
>>> reconsider the current behavior), but I don't know if there's any
>>> real chance
>>> of convincing Walter or not.
>>>
>>
>> This would be a huge mistake. For instance, private method are
>> sometime meant to be overridden in subclasses, which is impossible if
>> symbol is inaccessible.
>>
>> NVI for instance would be impossible in such a situation.
>

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.

> NVI is perfectly possible with protected.

Exactly. Furthermore, private implies final anyway.
« First   ‹ Prev
1 2 3