On Thu, 2002-03-14 at 05:45, Peter Zelezny wrote:
> Having two ways to access the lists is probably not the best, but we're
> getting there :)
You know the old Perl motto...
> > > I think the indexing using 'i' is unimplementable though.
> >
> > Because it's a singly linked list?
>
> Well yeah sort of. It's not provided as an array in C, so you'd probably
> need to make a COPY of the entire list before being able to index it
> with 'i'. Making a copy means you need to know all the fields available
> (yeah we're back here again).
Not to mention being a waste of memory. I presently do direct access to
the applicable data structures.
Speaking of which, I could use a way to retain a reference of some kind
to a list element after a call to xchat_list_next. Perhaps
xchat_list_next should _return_ the next list element, rather than
simply updating the xchat_list pointer to point to the next list
element.
This is necessary if I'm going to have an object class for, say, DCCs.
This would work by saving the pointer to the individual list element,
and using this pointer in calls to xchat_list_str and friends when
necessary. I hope you haven't implemented this in a way that would
prevent you from doing this easily...
> > --- BEGIN CODE SNIPPET ---
> > XChat xchat; // defined elsewhere
> >
> > for (Iterator i = xchat.getList("dcc"); i.hasNext();)
> > System.out.println("File: " +
> > ((XChatListElement) i.next()).getField("file"));
> > --- END CODE SNIPPET ---
> >
> > As before, this would throw an exception if the field doesn't exist.
> >
> > In this configuration, we can have a DCC class (like the previous
> > example), but we don't reference this class by name. That way it gets
> > past the compiler.
>
> That looks pretty good. But I think you'd still need a field/type
> list. Unless... is having getFieldStr and getFieldInt such a bad thing?
I can do that, as long as it's guaranteed that a call to getFieldStr for
an int field (or something like that) will cause an exception to be
thrown.
This is especially tricky with getting the int field. If you try to do
xchat_list_int on, say, a string field, how does xchat_list_int signal
that the field is not an integer field? It can't return -1, or any other
'funny value', because there _are_ no 'funny values' -- anything it
returns is a perfectly legal integer value. There is no way to
distinguish between a regular return and an error return.
Anyway, you said earlier that you have a big case statement for
determining the type of field; why not just use that to implement the
field/type list? It seems to me that this would be a pretty minimal
amount of work with significant gain in return.
> > One last thing. In Java, it is possible to access a class, method, etc
> > that doesn't exist at compile time but does exist at run time, using the
> > Reflection API.
> >
> > --- BEGIN CODE SNIPPET ---
> > XChat xchat; // defined elsewhere
> >
> > for (Iterator i = xchat.getList("dcc"); i.hasNext();) {
> > Object o = i.next();
> >
> > System.out.println("File: " +
> > o.getClass().getMethod("getFile", new Class[] {}).invoke(o, new
> > Object[] {});
> > }
> > --- END CODE SNIPPET ---
> >
> > This way, you can get it past the compiler. It's harder than having a
> > generic way of getting fields, like above, but it's still possible.
>
> Now you're just scaring me.
Sorry...
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