Sébastien Cevey wrote:
Hello folks!

Hello!

[here was a nice high level motivation description]

Here follows some quick comments.

Here is my proposed API, strongly based on anders' ideas:

  /* Prototypes */
  xmms_value_list_t * xmms_value_list_get_iterator (xmms_value_t *val);
  int  xmms_value_list_get (xmms_value_list_t *it, xmms_value_t **val);
  int  xmms_value_list_valid (xmms_value_list_t *it);
  void xmms_value_list_first (xmms_value_list_t *it);
  void xmms_value_list_next (xmms_value_list_t *it);
  int  xmms_value_list_position (xmms_value_list_t *it);

I think I would s/xmms_value_list/xmms_value_iter/

Is xmms_value_list_position useful?

[]

Notes:
- There is no reason why xmms_value_list_get() should return false,
  except if you pass it a crap 'it' argument.  I think.

When outside list?

(which would have the side effect that you could do:
while (xmms_value_iter_get (it, &v)) {
  do_stuff (v);
  xmms_value_iter_next (it);
}
)


- We can have recursive lists/dicts/etc with that.

\o/

- We could probably add a foreach function, as well as convenience
  aliases (_goto_index (it, pos), _last (it),
  xmms_value_list_get_int (it, &i), etc)

I think _last should be part of the low-level api. (i.e internally lists have pointers to last argument aswell)

- position here is in the interval [0; list_length]. if
  position==list_length, the iterator is one step beyond the last
  element (you cannot advance it more).

As I said above I'm not sure the function for getting iterator's current position is useful. As for the convenience function _goto_index yes I agree (or maybe not on the ability to position it outside the list)

That was it for accessing the list!

Or was it? :)

You are forgetting (intentionally or not) the ownership/referencecounting.

Does the "list" value own the iterator? Are values you get from iter_get() borrowed or do you need to unref them?

Now on to the API to modify to the
list!

  void xmms_value_set_empty_list (xmms_value_t *val);

I guess this means that we have similar api for all types:

v = xmms_value_new ();
xmms_value_set_int(v, 1337);

And not:

v = xmms_value_new_int (1337);


That means that we can initialize a "typeless" value_t? Do we really want that.

Having no "xmms_value_set_int" means that the _same_ value_t can be used for all ints with same value.

Lists are of course a different beast as they have to be mutable. But keeping the api same and thus having a xmms_value_new_list() is better imho.

Unless you have some arguments where splitting allocation of value_t and setting its value is useful.

[]

- _insert inserts the given value at the current position, thus
  shifting the current item to the right. it also works if the
  iterator points to the end of the list: you shift the end and insert
  the value instead (AKA append).
- We can have various aliases for lazy people, as shown above.
- Do we need any more basic functions than those two?

I think those are enough.

This is only for lists; dicts and propdicts will each have their own
iterator type and functions, which I will detail later.

Or will they?

Maybe dicts and propdicts just are lists of pairs?

Then just some convenience functions to find stuff in the list.


 anders


--
_______________________________________________
Xmms2-devel mailing list
Xmms2-devel@lists.xmms.se
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel

Reply via email to