On Wednesday, 6 August 2014 at 05:53:55 UTC, Philippe Sigaud wrote:
> I see. I didn't know one could create an A.B 'outside'. I saw inner types as Voldemort types, but that is true only for inner structs in functions.

 But we weren't creating them, we were copying them, no constructors were used. If the struct is private that may follow different rules as the struct can't leave the outer struct. hmmm static and private... other keywords to try, but offhand it's been a while i don't know if either would change the behavior. Could just be inner scope limitations. Might be other tags/modifiers...

 I feel helpless :(


> I already tried to propagate a ref through A's methods, but that made a mess: I have lots of methods, which have all to transmit this ref, only for *one* of them being able to update it.
>
> Thanks for you explanations :)
> I'm now using classes and inner classes. I'm not fond of classes, but that's working correctly.

 I'm not sure if it would help, but sometimes if you reverse the logic you might get what you want by putting the data in B instead of A.

 The example coming to mind is from the game 'Mark of the Ninja'. In order to speed up and get their code to work how they wanted, instead of having guards listen for sounds (which would be a constant pinging to look for sounds and other effects), the sound listened for the guards and notified them...

 So if the data is in B, A can access B's data; Although if you have another class C next to B, then communication between them becomes more of a pain probably...

 Just something to consider

> hmmm static and private... other keywords to
> try, but offhand it's been a while i don't know if either would change the
> behavior. Could just be inner scope limitations. Might be other
> tags/modifiers...
>
>  I feel helpless :(

No need to ;-) Thanks for your help, don't sweat it too much.

>  I'm not sure if it would help, but sometimes if you reverse the logic you
> might get what you want by putting the data in B instead of A.

I have a lot of Bs (nodes in a graph). They compute some things and
when they get a result, they update A's field. Each A holds the entry
point to their inner graph of Bs and waits for the results.
So I don't see how I could invert it, really.

What  *could* do it to have the graph of Bs in thread and sending results as messages to another thread, where A is waiting for them.

It's just... I'm so used to being able to mix and compose 'concepts'
in D: structs in functions, classes in classes in structs, functions
returning functions returning structs, etc. I'm used to begin able to
organise my code as I see the problem space.
But here, with a struct-in-a-struct, I hit a wall. Not fun, but not
problematic too...