On 9/4/16 11:09 AM, Martin Nowak 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:
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.
Still haven't heard really good use cases for the above, but the
trade-offs for also allowing access to private members aren't that bad,
thus it seems like the better path forward.
See http://forum.dlang.org/post/ymkehalxcigswvltl...@forum.dlang.org
There are a few cases I can think of:
* Serialization and deserialization, shallow and deep. These would need
access to the object layout, and possibly field names too (for
cross-checking and versioning purposes).
* Binary saving, loading, and fixup (a subset of
serialization/deserialization) - that thing when you copy raw memory to
a file and then load it raw and fix pointers up.
* Memory management and garbage collection: access to field types allows
efficient generic tracing.
* Database interfacing, automated binding, object-relational mapping,
etc. It stands to reason that field names would be needed and fields
would be private, yet the database loader does have access to them.
Of course the more important applications are those I can't yet imagine.
The way I see it introspection must have full power and unfettered
access. So definitely it must be able to pass through regular protection.
Andrei
