• DigitalDesigns (6/6) Jun 16 2018 mixin(`foo!(typeof(T.`~m~`));
• bauss (5/12) Jun 16 2018 You can't get that information when they're in another module,
• Jonathan M Davis (5/21) Jun 16 2018 There has been discussion of making private, protected, etc. accessible ...
• Adam D. Ruppe (4/6) Jun 16 2018 This breaks encapsulation.
• DigitalDesigns (16/22) Jun 17 2018 Yeah, but that is a lot of extra work when it is generally

DigitalDesigns <DigitalDesigns gmail.com> writes:

mixin(`foo!(typeof(T.`~m~`));

gives me an error about m being protected.

Error: class `X` member `name` is not accessible.

this also happens when using __traits(getMember, T, m); X is in 
another module. Works fine when X is in the same module.

I need to get the protected and private members for serialization.

bauss <jj_1337 live.dk> writes:

On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote:
 mixin(`foo!(typeof(T.`~m~`));

 gives me an error about m being protected.

 Error: class `X` member `name` is not accessible.

 this also happens when using __traits(getMember, T, m); X is in 
 another module. Works fine when X is in the same module.

 I need to get the protected and private members for 
 serialization.

You can't get that information when they're in another module, 
unfortunately.

The only solution would be to expose them as public or have a 
public member expose them.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

On Saturday, June 16, 2018 13:12:13 bauss via Digitalmars-d-learn wrote:
 On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote:
 mixin(`foo!(typeof(T.`~m~`));

 gives me an error about m being protected.

 Error: class `X` member `name` is not accessible.

 this also happens when using __traits(getMember, T, m); X is in
 another module. Works fine when X is in the same module.

 I need to get the protected and private members for
 serialization.

 You can't get that information when they're in another module,
 unfortunately.

 The only solution would be to expose them as public or have a
 public member expose them.

There has been discussion of making private, protected, etc. accessible to
type introspection, and I expect that it will work at some point, but yeah,
at the moment, it doesn't work.

- Jonathan M Davis

Adam D. Ruppe <destructionator gmail.com> writes:

On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote:
 I need to get the protected and private members for 
 serialization.

This breaks encapsulation.

A better design would be to have a class know how to serialize 
itself via a serializable interface.

DigitalDesigns <DigitalDesigns gmail.com> writes:

On Sunday, 17 June 2018 at 02:29:12 UTC, Adam D. Ruppe wrote:
 On Saturday, 16 June 2018 at 08:32:38 UTC, DigitalDesigns wrote:
 I need to get the protected and private members for 
 serialization.

 This breaks encapsulation.

 A better design would be to have a class know how to serialize 
 itself via a serializable interface.

Yeah, but that is a lot of extra work when it is generally 
unnecessary and breaks encapsulation far more than a CT 
reflection based scheme. CT reflection should not have these same 
restrictions and encapsulation does not technically apply.

Encapsulation cannot reflect in a generic way. Reflection can be 
generic and hence handle any case.  OOP and Reflection are two 
different things and encapsulation is mainly for OOP. After all, 
encapsulation is optional and one can code so things are highly 
dependent... so why should reflection break in one case but not 
the other? One can easily deal with encapsulation in reflection 
if they desire but it shouldn't be forced as it take away many 
useful possibilities.


With proper CT reflection one does not have to touch any code and 
it can just work. With oop one has to modify the classes to 
support serialization. That's a huge difference.