theefer forgot to cc list.
--- Begin Message ---
Enligt Anders Waldenborg <[EMAIL PROTECTED]>:
> I really want _iter_ in the name..
Ok.
> Also, is it xmms_ or xmmsc_? Maybe it is a entirely new system:
> "xmmsv_", which gives:
v(alue) doesn't seem to live in the same "namespace" as c(lient) or (server).
mh
and we have xmmsc_coll_t, also used in both the client and the server...
[light bulb lights up]
alright maybe we should use a common new namespace for both!
Considering the future (symmetric IPC, GenIPC, jetpacks), we could have all
common client/server types in there.
xmmsv_t
xmmsv_coll_t
xmmsv_list_iter_t
?
> Interesting. I was thinking that they operate on the value directly:
>
> xmmsv_t *v = xmmsv_new_list ();
> xmmsv_t *subv = xmmsv_new_int (10);
>
> xmmsv_list_append (v, subv);
Sure I agree with that. The question is what happens to the state of the
internal pointer. With:
> def append(v, entry):
> it = v.iter()
> it.last()
> it.insert(entry)
> end
It is changed. It's not necessarily what you expect. And more importantly,
using
this implementation, I don't see how one would manually move the internal
pointer back to its initial position (before append) without a _position
function?
> x_list_t is bi-directional no? I would not mind making it circular.
No, it isn't (currently). It could be indeed, if we want to. I just read the
TAoCP chapter on those ;-)
> Question is if you should be able to _goto_index outside list, or if you
> have to use _last for that.
_goto_index (list, list.length) would be an alias for _last (list). Sounds
natural to me, but it's arbitrary.
> > 1) you ref/unref using the value_t
> > 2) two solutions for iterators:
> > a) value_t.value contains a value_iter_t*, which is simply returned by
> > value_get_iterator. you never free the iterator.
> > b) value_t.value contains an x_list_t*, and value_get_iterator allocates
> a
> > new value_iter_t dynamically (which you must manually free, but
> freeing
> > it doesn't free the _list_, just the iterator).
>
> By 1) you mean that iter is dynamically allocated, and freed when value
> is destroyed?
1) + 2) a):
int callback (xmms_value_t *val) {
iter = xmms_value_get_list_iterator (val); /* pass internal pointer */
/* do stuff */
xmms_value_unref (val);
/* data has been freed, do NOT use iter anymore! */
}
1) + 2) b):
int callback (xmms_value_t *val) {
iter = xmms_value_get_list_iterator (val); /* allocates */
/* do stuff */
xmms_value_unref (val);
xmms_value_iter_unref (iter);
}
In b) we have one more level of refcounting. Is it worth it? Maybe we should
think of bindings too.
> Lets go for xmms_value_new_TYPE (TYPE val) as the only way to create
> value_t objects. And no way to change their value (except for lists).
Okay.
> >> Maybe dicts and propdicts just are lists of pairs?
> >> Then just some convenience functions to find stuff in the list.
> >
> > They are, but should we expose that?
>
> Don't know, should we?
No :-P
It's just wrong to be able to apply operations on an irrelevant type:
xmms_value_iter_seek_key (list); /* huh? */
xmms_value_iter_get (dict, &item); /* huh? */
xmms_value_iter_get_pair (list, &key, &val); /* huh? */
xmms_value_iter_next (dict, &item); /* huh? */
xmms_value_iter_next_pair (list, &item); /* huh? */
etc.
--
Sebastien Cevey - inso.cc
--- End Message ---
--
_______________________________________________
Xmms2-devel mailing list
Xmms2-devel@lists.xmms.se
http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
