Thread overview | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 01, 2012 traits getProtection | ||||
---|---|---|---|---|
| ||||
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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | Code: https://github.com/D-Programming-Language/dmd/pull/856 |
April 01, 2012 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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 Re: traits getProtection | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjærås | 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. |
Copyright © 1999-2021 by the D Language Foundation