Hi Stephen, xemacs-beta,
On Wed, Nov 26, 2014 at 3:32 AM, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
Johann 'Myrkraverk' Oskarsson writes:
You can return a type derived from Lisp_Opaque object, which is just
blob of memory containing the data. That's all you need to do if it
just gets passed to other libClang objects. Turning it into an
integer or the like is a bad idea, as that means you can't type check
objects passed to libClang interfaces.
Since, afaict, this particular void * is never passed around directly,
I think I'll just hide it from the lisp level completely. Maybe just
throw a semi-helpful error if anyone tries to (get) it.
That said, I never grokked how to use Lisp_Opaque. So far I've been
using lcrecords, which are both semi-documented and have an interface
for modules. I say semi-documented because there are things missing
from the comments in lrecord.h about implementing them in a module.
Maybe I'll write a short tutorial when I have slightly more experience.
Property lists are application-specific, user-supplied attributes.
the cursor type doesn't need them you don't need to implement it.
Ok, then the question is, what is a better strategy, not to implement
it at all, which gives the error "Object type has no properties" which
can be slightly surprising and misleading if any of the (get), (put)
and (remprop) are implemented; vs. returning nil?
I'd like answers from people who have actually used property lists for
something; if any.
And on that note, why is that the internal putprop callback is
supposed to return 0 to throw a lisp error, but the remprop callback
is supposed to return -1? Wouldn't it have been better to synchronize
it? (This is from Fput and Fremprop in fns.c). I also just checked,
and afaict, this has not changed in 21.5. Given how few modules are
actually out there (mine may be the only one who does types) do you
want to change it?
> Also, the (get cursor 'kind) returns another type, which
I've not yet
> wrapped. This is an enumerator documented at
> and I wonder what some options are to represent this in elisp?
I would most likely use symbols. Whether to use keywords is a matter
of taste. I probably wouldn't. [...] Creating a
separate enum type seems like overengineering; if you want to
introspect the set of enumerators, a defconst at Lisp level seems
sufficient. If you really want to, you can create that list read-only
at the C level in your module.
Overengineering or not, it does make it slightly easier to typecheck
for the functions that take these enumerators as arguments; see here:
But that doesn't mean I can't use symbols. Maybe I'll do it the XP
way and try both a type wrapper and symbols to see which feels better.
XEmacs-Beta mailing list