Re: zed: When will the new PI be done?

[Peter Zelezny <zed@linux.com>]

On Thu, 7 Mar 2002 01:50:58 -0300
Gustavo Niemeyer <niemeyer@conectiva.com> wrote:

> > > It'd be nice to have a list of fields, and some way to know
> > > what each type is going to be. This would make it easy for
> > > higher level interfaces to wrap this information into
> > > smart objects, avoiding specific code for each list.
> > 
> > There's no list available in the code, so I'd have to add
> > one in especially for this. Can't you just pass whatever the
> > python coder gives you to xchat_get_int/str? Python coders can then just
> > use the same docs as for the C-plugin interface to find out what fields
> > are available.
> 
> It shouldn't be hard to add one, a NULL terminated array of strings
> (probably staticaly allocated for each list) would do the job. I can
> help you if you're busy with other stuff.
> 
> Being able to access data types is also highly advisable. It's not
> confortable (and dangerous!) for high level developers to convert
> between different types.
> 
> I can imagine something like:
> 
> void xchat_list_get_fields(xchat_plugin *ph, char *list,
>                            char **name, int **type);
> 
> These requirements are not 100% necessary, and they will probably be
> unuseful for C plugin developers. OTOH, they will be a big difference
> for the python interface and for other languages using similar concepts.
> My idea is to return a list of objects with attributes, so one'd be able
> to call list_get() and access "user.nick" and "user.host", for example.
> I can't imagine anything easier.

I don't know if I like this idea. Why not just make xchat.get_info(ph, id)
available under python? Trying to make all these objects like User,
Channel etc, seems like too much work for little effect. 

Can fields of a class/object be dynamic anyway? What if someone does user.abc
(abc being a new field added later) on an older version of xchat? Under
the C-plugin interface, it'd just return NULL and no problem, but wouldn't
python throw an error?


> PS. The documentation mentions dcc->context list attribute as being
> a string. This should probably be a long, given the data nature.

dcc->context? Where do you see that?

If you mean "channels"->context, it's really a (void *) just like all
xchat_get_context, xchat_find_context etc. So returning it as (char *) is good
enough, while returning it as an int could fail on 64-bit machines. Don't
think of it as a string, it's more like:

xchat_get_str (return a POINTER)
xchat_get_int (return an INTEGER)


-- 
Peter Zelezny. <zed@linux.com>
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/