Compiler patch for runtime reflection

[Jacob Carlborg]

On 2011-10-26 07:44, Robert Jacques wrote:
> On Tue, 25 Oct 2011 12:38:18 -0400, Jacob Carlborg <doob at me.com> wrote:
>> On 2011-10-25 16:21, Robert Jacques wrote:
> [snip]
>>> Both are protection attributes. The problem of taking the delegate of a
>>> mutable member on a const object, is the exact same problem as taking
>>> the delegate of a private member.
>>
>> I don't agree.
>
> [snip]
>
>>> Bypassing the protection type system and delegate escape are very
>>> different things. The escape of a delegate is fully controlled by the
>>> coder of the class/module; with bypass mechanisms, the library writer
>>> has no control.
>>
>> So how should this be fixed? Make it a compile error to create a
>> delegate from a private method?
>
> I think we are taking about different things. Today in D, due to a bug,
> for example
>
> foo.bar()
>
> won't compile because it's private/not-const/etc. But
>
> (&foo.bar)()
>
> will compile. That 'feature' is what I thought you were referring to. If
> the writer of a class wants to let a delegate of a private member
> function escape, I don't have a fundamental problem with it. But I do
> have a problem with someone who isn't the writer of the class doing so.

I'm referring to the above but, as I've already written and you haven't 
replied to is, I don't understand how it can be prevented.

> [snip]
>
>>> Still, __traits is still the full fledged compile-time reflection
>>> feature and doesn't bypass protection attributes.
>>
>> Yeah, but for a serialization library I want to be able to serialize
>> private fields. This is known issue that this breaks encapsulation.
>
> I understand that at times when serialization has to break
> encapsulation. My opinion though, is that classes should have to opt in,
> before the serializer goes ahead and breaks their carefully designed
> encapsulation. i.e. someone should have to code review the class to make
> sure everything is kosher. For code you are developing, this is as
> simple and straightforward as adding a single mixin statement to the class.

It's not straightforward when serializing third party types. One of my 
goals when I started writing my serialization library was to, somewhere 
down the road, create a window/interface builder for DWT. The builder 
would (de)serialize the widgets available in DWT and save it as an XML 
file. Since I'm the current maintainer of DWT I could go and modify DWT 
to fit my needs but I don't think that's the right approach and will 
make merging future versions of SWT more difficult.

-- 
/Jacob Carlborg