[Circle-dev] ObjectProxy

[Paul LeoNerd Evans]

On Fri, Nov 20, 2009 at 01:11:04PM -0500, Kiyoshi Aman wrote:
> > > 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...
> 
> I'm not sure how 'slicing' is confusing, but perhaps that's because
> I'm using the word in the Python sense (i.e., array[1:3] is elements
> 1, 2, and 3 from array).

Ah; OK.. so that's entirely reading it... I don't see then what you're
getting at here; the clients will have the data stored in them anyway,
so we don't need a way to query partial information by slices over the
wire.

> ...Which is essentially a 'replace' when all's said and done. You're
> removing some number of elements and putting a perhaps similar number
> of elements in their place, after all.

*shrug* It's a well-defined operation with a well-defined name.. See my
later comment about renaming...

> >  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 )
> 
> Except Python does not have a splice(), so the fact that the current
> reference implementation is written in a language which can do all of
> my suggested operations via splice is kind of irrelevant. ;)

Neither does C :)

The point of the Tangence -interface- is to define an -interface-.
Whether Python arrays natively can splice() is irrelvant. That splice
operation can still be implemented in terms of whatever is the local
native operations it does have; purely guesswork:

  def splice(array, start, count, newvalues):
     array.remove(start, count)
     array.insert(start, newvalues)

> (Apply the attached bundle (via 'hg unbundle') to
> http://hg.atheme.org/users/aerdan/tangence-python/ and I think you'll
> see what precisely I'm getting at here.)

I'll take a look....

> > 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.
> 
> I said nothing about removing 'move'. I merely elected not to comment
> on it because I didn't see anything wrong with it. ;)

Oh sure; I just thought I'd mention that for the sake of completeness :)

> > > - 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.
> 
> 'Insert' allows for arbitrary placement of elements (see list.insert
> in Python), thereby eliminating a need for unshift.

Except that unshift implies "at the start of the list" so you're saving
the extra down-the-wire encoding overhead of having to put that count as
its own argument.

Again, we've got 256 operations to use here, we don't mind having lots
of them. Defining extra operations only uses extra code space in the
programs at either end, that's memory and therefore cheap. Bandwidth is
expensive. Remember our optimisation order:

  Roundtrips
  Bandwidth
  CPU time
  Memory

That said, we could still manage some more operations here which all
wrap variations on splice()

 insert_start == unshift
 insert
 insert_end == push

 remove_start == shift
 remove
 remove_end == pop

Possibly also

 replace_start
 replace
 replace_end

to do guaranteed length-preserving replacements of a range of elements.
Not sure on that one, we'd need to think up the use cases.

In any case, splice allows us to do any of these things, perhaps with
slightly less byte efficiency. If we find some application in using a
given arrangement a lot, we can always give it its own name.

> 'Remove' genericizes the operations inherent in pop/shift, and does so in a way
> that allows for multiple elements to be removed at once (something
> which shift can't do...)

Err.... Tangence's shift takes a count of elements to remove.

Also, again like unshift, pop and shift imply their location, thus
saving down-the-wire encoding of where it should apply.

> > > - 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.
> 
> ...Except the only benefit you gain from having two different list
> types is a bit of memory usage on lists which don't need splice/move.
> Both of the 'new' operations I suggested would be applicable on both
> types of lists, and in any case they're just code duplication in both
> the reference implementation and in my Python one. I would see the
> need for such if we were working from a C or C-like codebase, but it's
> a bit silly in Perl or Python.

Again, I think you missed the point. I'll use a really concrete example.


In Circle, the scrollback events on a WindowItem are stored in a QUEUE.
Not an ARRAY. Were they in an ARRAY, then every Circle frontend would
have to implement splice and move operations. E.g. the GTK one would
have to be able to splice buffer lines in the GtkTextBuffer object to
swap lines of scrollback around. That code would be annoying to
implement. Furthermore, since the backend isn't going to throw such
operations at it, it would be implemented knowing it's probably going to
lie unused.

Instead, we implement it as a QUEUE. A QUEUE is a sort of "ARRAY lite";
it says "I promise I will not move elements around, nor insert anywhere
other than at the end, nor delete anywhere other than at the beginning".

It is this forward declaration of what operations will or won't be
called on the object, which is the distinction between QUEUE and ARRAY.

-- 
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/c32e80c6/attachment.pgp>