Johann 'Myrkraverk' Oskarsson writes:
But there are only a handful of lrecords who actually implement
properties: strings, extents, faces, glyphs, symbols, gtkobjects and
gtkboxed; in 21.4 at least. Of course there can be more types that do
this too.
Possibly some that you don't know about and can't fix. I have at
least three branches (currently dormant) that implement new types. I
don't remember offhand whether any of them implement object property
lists, but all are intended for the mainline "someday". It would be
annoying to track down such a bug.
Has that changed in 21.5 so everything can have properties?
Quite possibly more do, but it would probably still be only a handful.
Anyway, the question is really about lowering the barrier for new
module developers.
Not entirely. You also have to consider not screwing old ones.
Neither of us has any idea how many such types exist out in people's
workspaces, not just in modules but in modified cores, too. XEmacs
has long been a favorite platform for corporate variants, for example.
> What do you mean by "type"? As I use the word, every
lrecord/lcrecord
> is a different type. Most modules do create specialized lrecords, and
> aside from those there are currently over 100 different ones in the
> enum of lrecord_types in core.
In this case, I mean an emodule that implements a type.
But what do you mean by "implement a type"? Both ldap and postgresql,
as well as my unmerged branches, all create and register new lrecord
types as extensions to the enum in lrecord.h. I consider that to be
implementing a type. Do you?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta