On Tue, Mar 13, 2012 at 12:29:51PM +0000, Guido Trotter wrote: > On Tue, Mar 13, 2012 at 12:25 PM, Iustin Pop <[email protected]> wrote: > > On Mon, Mar 12, 2012 at 01:29:25PM +0100, Iustin Pop wrote: > >> On Mon, Mar 12, 2012 at 11:31:17AM +0000, Guido Trotter wrote: > >> > On Thu, Mar 8, 2012 at 12:44 PM, Iustin Pop <[email protected]> wrote: > >> > > Let me try to explain in words what is happening, and you can then > >> > > suggest a better name: > >> > > > >> > > - at first, we have old_pnode on which the instance lives, and > >> > > new_pnode > >> > > on which the instance will live > >> > > - we "remove" the instance from its old_pnode, which gives us the new > >> > > version of the old_pnode, which I called old_pnode' > >> > > - we "add" the instance to its new_pnode, which gives us the new > >> > > version > >> > > of new_pnode, called new_pnode' > >> > > > >> > > I thought of calling them old_pnode, old_pnode_after_remove, new_pnode, > >> > > new_pnode_after_add, but this seemed a bit "silly". > >> > > > >> > > I'm fine with any names, for the record, just don't know how to name > >> > > them nicely. > >> > > > >> > > >> > I'm fine with ' as long as it's clear what we mean. > >> > Perhaps we can document in our styleguide when and how to use ' > >> > variables? (as the new state of an entity after a transformation > >> > happening inside a function). > >> > >> Yes, definitely - I picked this naming style up from the fact that it is > >> indeed the customary use. > >> > >> I'll update the wiki then, thanks! > > > > Wiki updated, please take a look :) > > > > Thanks. This makes it clearer although I'm not sure we should allow > "that many" updated values, as it'd be almost a way of "working > around" some language functionality. > So I'd be even more strict into limiting them. But at least now it's > clear, thanks.
Oh, I'm fine to limit; 3 max 4 is fine, above that clearly you're doing the wrong thing; feel free to update. Anyway, where does that leave this particular patch/interdiff? iustin
