Re: Plugin Interface: xchat_list API

[Peter Zelezny <zed@linux.com>]

On 07 Mar 2002 14:24:47 -0800
Alexander Hvostov <root@aoi.dyndns.org> wrote:

> > 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?
> 
> Just to lend a little insight, in Java, you could have, say, a Session
> class, with the method:
> 
>   Object get(String fieldName)
> 
> Then, you pass the name of the field you want as 'fieldName', and the
> return is an arbitrary object, but you don't know what type it is. (You
> have to run tests on its type via 'instanceof', or cast it if you
> already know its type or if it's OK to throw an exception from a failed
> cast.)
> 
> When this 'get' method creates the new object to be returned, it does
> need to know what kind of object to construct, so I need to have a
> facility for asking X-Chat what the proper type is for a given field, so
> that we can construct the proper kind of object here. (Or you can return
> a null type somehow, if the field doesn't exist.) I _don't_ need to have
> a list of the fields' names -- just the type of a field given its name.
> 
> There would probably be some other convenience methods for accessing
> fields, like:
> 
>   String getTopic()
> 
> This would just be a wrapper around the generic 'get' method above,
> though. It would be written something like this:
> 
>   String getTopic() {
>     return (String) get("topic");
>   }
> 
> Here, it gets the topic, casts it to a string, and returns it.
> 
> And no, it's not possible to make a class with fields/methods that are
> dynamically created. They have to be there at compile time. That means
> that the Java classes (eg, Session) need to be updated when some fields
> are added/removed, to add the appropriate methods in Java. If you try to
> run some Java code that's designed for a newer version of X-Chat than
> what it's being run on, and it tries to access a method that doesn't
> exist in the older version, then an exception will be thrown. The Java
> code trying to access this method is allowed to catch the exception and
> recover, so as to be made backwards-compatible.
> 
> Or the Java code can use the generic 'get' method, in which case it will
> get a 'null' return for nonexistent fields, and will have to check that
> and deal with it appropriately.
> 
> Regards,
> 
> Alex.

If you want to include your Java and Python plugins into the main dist, I
think they should be standardized. That is, they should have pretty much the
same API as the C-plugin interface. I don't want to make the same mistake
as 1.x.x where C/perl/python were all totally different. So, about the
xchat_list API, can't they be provided directly? E.g. in Java you could do
something like:

xchat_list list;

list = xchat.list_get(ph, "dcc");
if (list != NULL)
{
	while(xchat.list_next(ph, list))
	{
		System.out.println(xchat.list_str(ph, list, "file"));
	}
	xchat.list_free (ph, list);
}

I assume you have a 'xchat' class or something like that?

This way the code looks 95% like the C version, with only subtle changes
for the language (xchat. instead of xchat_). I assume Gustavo could do
something similar with the Python?

If it can be implemented like this, I don't see a need for a function that
returns a list of available fields and types. The implementation of
xchat.list_str would simply call the C-plugin xchat_list_str and give the
result direct (or converted to a Java String). For that, I might remove
that "context" field that was causing some confusion.

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