[Circle-dev] ObjectProxy

[Paul LeoNerd Evans]

On Thu, Nov 19, 2009 at 04:00:26PM -0500, Kiyoshi Aman wrote:
> Hi, folks.
> 
> I have a proposal regarding Tangence (as a result of continued
> poking-around with tangence.objectproxy.ObjectProxy). Specifically,
> I'd like to add support for appending to and popping from indices into
> queues/arrays and build support for slices into these operations. I
> believe this would make Tangence more robust.
> 
> Ruminations as a result of baking these into tangence.objectproxy:
> - insert can't make use of slicing.
> - remove would be an arbitrary-positioned shift, thereby making shift redundant.
> - splice should probably be renamed to replace, since that's what it *does*.

I'm not sure what you mean by "slicing" here...

Also I think you may have somewhat missed the point of splice. splice is
NOT replace. splice performs, in one atomic operation, a combination of
a delete and an insert. It deletes a range of zero-or-more elements from
some point in the list, and in its place, inserts a new list of zero or
more elements. It is a generic list operation, supporting all the basic
operations, and more besides:

 push $foo    =>     splice $end, 0, ( $foo )
 unshift $foo =>     splice 0, 0, ( $foo )
 pop          =>     splice $end-1, 1, ()
 shift        =>     splice 0, 1, ()

Your operations are all expressible using splice:

 insert       =>     splice $position, 0, @elements
 remove       =>     splice $position, $count, ()
 replace      =>     splice $position, 1, ( $new_value )

You may be given to wonder why we have push/unshift/pop/shift in the
first place, then, given we have splice. The answer is twofold. Firstly,
by making these operations distinct we can support the array/queue
duallity; see below on this. Secondly, since the operation number is
encoded in an entire 8-bit byte, we've got 256 different operation types
to play with. It therefore makes sense to try to define lots of
operation types, so as to reduce the number and size of the
per-operation arguments.

Incidentally, move -could- be implemented by a delete and an add, except
that for efficiency we have a dedicated move operation so we don't have
to send the re-added value down the wire a second time. This makes a lot
of difference if the item is, say, an IRC channel window with all its
scrollback.

> - push should probably be renamed to append, for the same reason.

Well, the basic operations of push/pop/shift/unshift/splice were all
just named based on the perl functions of the same name. I'm not
-ooooverly- attached to these as a name, but if we want to rename some,
we should have a careful think about coming up with a good set of names
to express all their behaviours.

> - What do we need queues for, again? They're arrays without splice &
> move. Yay code duplication?

Correct; they are arrays without splice and move. This means, the only
operations you can perform on queues, operate on the head or the tail,
adding or removing elements only. This makes queues a much simpler
structure.

The distinction is meant to reflect differences in implementation, and
differences of use.

A queue could easily be implemented as a doubly-linked list structure,
because it knows it won't need arbitrary accesss to some elements in the
middle of the list. This is used for things like message scrollback or
input history buffers. The frontend code that implements the view of a
queue object knows it won't have to implement splice and move
operations, so, for example, we know we don't need to support moving a
line of scrollback to a different position in the GtkTextBuffer.

An array, by contrast, is intended for operations that directly
reference numbered elements by index. It would probably be implemented
by a real array. This is intended for things that require positional
access, such as the list of tabs on display in the Tabbed session
windows. Each tab is addressible individually, and can be inserted,
deleted or moved around.

The main difference, in essense, is what happens when you try to watch a
queue or an array property in an ObjectProxy in a front-end client.
Trying to watch an array property will fail if you do not provide code
to implement the splice and move operations. These would be tedious and
annoying to implement on things like IRC channel message window
scrollback, because you'd know that in practice they won't ever come up.

Hope that helps,

-- 
Paul "LeoNerd" Evans

leonerd at leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://mail.leonerd.org.uk/pipermail/circle-dev/attachments/20091120/7058af24/attachment.pgp>