• Gor Gyolchanyan (28/28) May 09 2012 If this was brought up before, sorry for spamming.
• deadalnix (2/27) May 09 2012 It has been raised, and this is a +1 for me.

Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:

If this was brought up before, sorry for spamming.

I've been working on dynamic memory structuring mechanism (run-time
struct types) and I've felt the need to "import" the structure for a
dynamic struct type from a static (regular D) struct type.
When I was iterating over the members using __traits(allMembers,
StructType) it successfully went through all members, but when (in
case of a data field) I queried the type and address of the member
using __traits(getMember, structInstance_, memberName) it displayed an
error about the member not being defined. I figured out, that it was
because of the member being private. Therefore, I have 2 questions:

1. If the __traits(getMember, ...) won't return private members, why
does __traits(allMembers, ...) show them?
2. Why doesn't __traits(getMember, ...) return the private member in
the first place? One could easily hack around this limitation by
having the member analysis in a mixin template, so the analysis ends
up in the same module, hence giving access to the private members.
This doesn't provide any safety - only removes syntax sugar.

There are numerous cases, where private members need to be accessed
(serialization, for instance), wouldn't it be better to
__traits(getProtection, ...) in cases, where protection needs to be
respected?
After all, it's not in the D's philosophy to restrict people from
doing things "for their own good", like java does (that's why I hate
java). A back door for those, who know what they're doing is always
needed.

-- 
Bye,
Gor Gyolchanyan.

deadalnix <deadalnix gmail.com> writes:

Le 09/05/2012 12:13, Gor Gyolchanyan a écrit :
 If this was brought up before, sorry for spamming.

 I've been working on dynamic memory structuring mechanism (run-time
 struct types) and I've felt the need to "import" the structure for a
 dynamic struct type from a static (regular D) struct type.
 When I was iterating over the members using __traits(allMembers,
 StructType) it successfully went through all members, but when (in
 case of a data field) I queried the type and address of the member
 using __traits(getMember, structInstance_, memberName) it displayed an
 error about the member not being defined. I figured out, that it was
 because of the member being private. Therefore, I have 2 questions:

 1. If the __traits(getMember, ...) won't return private members, why
 does __traits(allMembers, ...) show them?
 2. Why doesn't __traits(getMember, ...) return the private member in
 the first place? One could easily hack around this limitation by
 having the member analysis in a mixin template, so the analysis ends
 up in the same module, hence giving access to the private members.
 This doesn't provide any safety - only removes syntax sugar.

 There are numerous cases, where private members need to be accessed
 (serialization, for instance), wouldn't it be better to
 __traits(getProtection, ...) in cases, where protection needs to be
 respected?
 After all, it's not in the D's philosophy to restrict people from
 doing things "for their own good", like java does (that's why I hate
 java). A back door for those, who know what they're doing is always
 needed.

It has been raised, and this is a +1 for me.