Usability of "allMembers and derivedMembers traits now only return visible symbols"

[Basile B. via Digitalmars-d]

On Sunday, 4 September 2016 at 03:45:50 UTC, Martin Nowak wrote:
> On Saturday, 3 September 2016 at 17:23:53 UTC, Basile B. wrote:
>> On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak 
>> wrote:
>>> On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:
>>>> I don't agree with the current solution:
>>>
>>> Well let's come up with a better solution then.
>>> Let's start by finding some proper use-cases that require 
>>> introspection on private members w/o having access to them.
>>
>> In my user library, the serialization is based on the @Set and 
>> @Get UDAs. Typically there would be a setter (a public method) 
>> and no getter (i.e the data is read directly either from a 
>> protected or private variable).
>
> A public setter for private members is weird, but well.

No in Object Pascal that's a common to have

     property Foo: string read fFoo write setFoo;

By the way there's an error from my part, in my lib it's @SetGet 
which gives access to private/protected field "directly".

> As a library template can't read private fields, you don't need 
> the @Get attribute.
>
>> The introspection is used to create a property descriptor.
>
> What does that mean? You're creating a property in the 
> serialised data?

The introspection creates a special structure for each property 
annotated with @Set, @Get, or @SetGet. This is a kind of 
interface for serialization/binding/object inspector (a bit like 
"published" in Object Pascal).

https://gist.github.com/BBasile/39fb66f7a0189660182cc637ab8d698b/archive/3e0f7441cfba89b5959b78eef63b9538d137a55a.zip (you can "dub a.d")

>
> Defining de-/serialize methods in the class/struct, e.g. with a 
> mixin template would be the cleaner and more obvious approach 
> IMO.

I see your strategy...each time someone will find an argument to 
make the traits omniscients you'll say, "no because it's cleaner 
to do like that" ?