On 2011-10-26 07:44, Robert Jacques wrote:
On Tue, 25 Oct 2011 12:38:18 -0400, Jacob Carlborg <d...@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
