| Actually I suppose Node:reorder should just be the OOP front end for n_order in a scheme like this. That alone would probably satisfy the majority of needs, and would be nicer than the current chains of after, before, etc. Auto-reordering should possibly be a different object?
S. On 30 Jul 2009, at 08:06, Scott Wilson wrote: I had another idea of how to do this. A simple and lightweight approach would be to implement an n_order message which allowed you to specify the ordering of a number of nodes explicitly. This would be more robust than a series of move messages, since it would not depend on the order in which those messages arrived, and would not fail if one of the nodes was already freed (just post a warning and continue with the ordering). This would avoid the need for a lot of clientside bookkeeping about node state, thus keeping things lightweight. The message would also take a target and addAction, with the normal defaults. An object-style Node:reorder method could determine an order using whatever constraints and then send a single n_order message to the server.
Thoughts?
S.
On 29 Jul 2009, at 18:17, Scott Wilson wrote: On 29 Jul 2009, at 18:01, James Harkins wrote: On Wed, Jul 29, 2009 at 11:52 AM, Scott Wilson <s.d.wilson.1@xxxxxxxxxx> wrote: Isn't sendsSignalTo effectively just a synonym for moveAfter then?
moveAfter is not persistent, but sendsSignalTo would be.
b.moveAfter(a);
a.moveToTail(s); // now b is before a and we have no way to repair it automatically
but...
b.receivesSignalFrom(a); // (the reverse method for mixerchannel)
a.moveToTail(s); // order is broken
Node.reorder; // hypothetical method that would fix the node ordering
Devil's advocate: In what case would you actually do a.moveToTail(s) if you wanted auto node reordering? If something is doing it behind the scenes, how do you guarantee that Node.reorder doesn't break that?
S.
|