View mode: basic / threaded / horizontal-split · Log in · Help
January 27, 2013
Re: Fixing module-scope private
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 ?
January 27, 2013
Re: Fixing module-scope private
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.
January 27, 2013
Re: Fixing module-scope private
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
January 28, 2013
Re: Fixing module-scope private
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.
January 28, 2013
Re: Fixing module-scope private
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.
January 28, 2013
Re: Fixing module-scope private
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.
January 28, 2013
Re: Fixing module-scope private
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.
January 28, 2013
Re: Fixing module-scope private
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
January 28, 2013
Re: Fixing module-scope private
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
January 28, 2013
Re: Fixing module-scope private
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home