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" ?
