On Sunday, 27 January 2013 at 14:27:21 UTC, Andrei Alexandrescu wrote:
> I agree that mod1.func should not even be visible from mod2.
>

Not even via reflection ?

On Sunday, 27 January 2013 at 14:43:26 UTC, deadalnix wrote:
> On Sunday, 27 January 2013 at 14:27:21 UTC, Andrei Alexandrescu wrote:
>> I agree that mod1.func should not even be visible from mod2.
>>
>
> Not even via reflection ?

Debatable, so far I am planning to propose full hiding. No direct reflection, no DDOC via import, no trace of symbol in object file. Like it was possible in C/C++. Detailed investigation may reveal valid use cases though, than design may need to become more complex.

On 1/27/13 9:43 AM, deadalnix wrote:
> On Sunday, 27 January 2013 at 14:27:21 UTC, Andrei Alexandrescu wrote:
>> I agree that mod1.func should not even be visible from mod2.
>>
>
> Not even via reflection ?

Not even. Note that private struct/class member visibility via reflection is a different matter.

Andrei

OK, I have gathered most of the data I wanted and writing DIP right now.

Only moment not perfectly clear for me are serialization libraries and private. Can someone who has been doing similar things provide few snippets of serializing fields/variables serializer has no access to, in a way it is done now?

I have asked Jacob via e-mail about his Orange but may be someone else can stand up.

P.S. Raw data I am making decisions on top of sits here: http://wiki.dlang.org/Access_specifiers_and_visibility . Everyone is welcome to correct me in the wrong parts.

On Monday, 28 January 2013 at 14:18:38 UTC, Dicebot wrote:
> P.S. Raw data I am making decisions on top of sits here: http://wiki.dlang.org/Access_specifiers_and_visibility . Everyone is welcome to correct me in the wrong parts.

Very good job !

But is more a stating of how things are now rather than a DIP.

On Monday, 28 January 2013 at 14:28:00 UTC, deadalnix wrote:
> On Monday, 28 January 2013 at 14:18:38 UTC, Dicebot wrote:
>> P.S. Raw data I am making decisions on top of sits here: http://wiki.dlang.org/Access_specifiers_and_visibility . Everyone is welcome to correct me in the wrong parts.
>
> Very good job !
>
> But is more a stating of how things are now rather than a DIP.

Ye, thus I have said "raw data" and "I am writing DIP now" :)
I have just gathered all related stuff together to get a big picture and leave no issues unresolved by DIP. DIP itself will be published either this evening (GMT +0) or tomorrows morning.

On 2013-01-28 15:15, Dicebot wrote:
> OK, I have gathered most of the data I wanted and writing DIP right now.
>
> Only moment not perfectly clear for me are serialization libraries and
> private. Can someone who has been doing similar things provide few
> snippets of serializing fields/variables serializer has no access to, in
> a way it is done now?
>
> I have asked Jacob via e-mail about his Orange but may be someone else
> can stand up.

Orange uses ".tupleof" to iterate all fields and also to get/set the value of a field. This will bypass the protection attribute and allows to get/set private/protected/package fields. The serializer would be a lot less user friendly if the user had to manually serialize each protected field.

The serializer also uses __traits(getAttribute) for the fields and classes/structs to any attached attributes. If the above cannot work for private fields I guess there's back to using mixins to a static fields which are a uglier than attributes.

-- 
/Jacob Carlborg

On Monday, 28 January 2013 at 20:10:16 UTC, Jacob Carlborg wrote:
> The serializer would be a lot less user friendly if the user had to manually serialize each protected field.

Can Orange work on structs/classes that have not been intended to be used with it, e.g. imported from some other arbitrary module?

If not (and your mention of annotations seems to suggest that), the easiest solution would be to just provide the serialization code in the module where the class is defined (e.g. a public static member function), no?

David

On 2013-01-28 21:15, David Nadlinger wrote:

> Can Orange work on structs/classes that have not been intended to be
> used with it, e.g. imported from some other arbitrary module?

Yes. It can serialize arbitrary third party types without any extra code.

> If not (and your mention of annotations seems to suggest that), the
> easiest solution would be to just provide the serialization code in the
> module where the class is defined (e.g. a public static member
> function), no?

That's also possible.

-- 
/Jacob Carlborg