On Wed, 2002-03-13 at 19:09, Peter Zelezny wrote:
> 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:
So, you basically are asking me to throw away 95% of Java's capabilities
-- those which make Java as great as it is -- just so we can have a
little meaningless consistency?
I'm afraid I have to object here. Last time this was done was with DOM,
and boy, was that ever a monstrosity to behold...
I think each language's API should be specifically designed to work with
and take advantage of the capabilities of the language. Taking a
lowest-common-denominator approach, from my experience, helps no one and
hurts everyone.
In other words, I think the old way was _correct_.
> 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?
In keeping with my statement above about taking advantage of the
language's unique characteristics and capabilities, here's what I think
would be ideal:
--- BEGIN CODE SNIPPET ---
XChat xchat; // defined elsewhere
DCC[] dcc = xchat.getDCCList();
for (int i = 0; i < dcc.length; i++)
System.out.println("File: " + dcc[i].getFile());
--- END CODE SNIPPET ---
Notice how much shorter and cleaner my code is.
There is no sense in reinventing the wheel. There is no sense in
throwing away the wheel and using a cubical block just because that's
what all your neighbors use, either.
> 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.
And how can I be absolutely sure it's a string and not, say, an integer?
If I am to make it so that Java plugins are kept in the proverbial Java
'sandbox' that's kept Java applets on the Web so safe, I need to have
this type safety. Therefore I need some way to get the type of a given
field.
I should point out that the only times I've ever managed to get X-Chat
to crash as a result of running some Java code under my current system
is under one of three circumstances:
- There was a bug in my C++ code that connects Java to X-Chat.
- There was a bug in X-Chat.
- There was a deficiency in X-Chat's plugin interface that prevented me
from implementing a necessary safety mechanism.
I'd like to eliminate the third one, and not introduce additional
possibilities. The first two are enough.
Last but not least, if your insistence on API consistency is a condition
for the inclusion of my plugin into the main X-Chat tree, then I'd be
happy to maintain it separately from the main X-Chat tree. I still need
the functionality needed to enforce safety, though.
Regards,
Alex.
--
PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N-
o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI
D+++ G e h! !r y
------END GEEK CODE BLOCK------
This is a digitally signed message part