On Monday 09 June 2008 16:44:02 James Keenan via RT wrote: > On Thu Aug 03 11:58:05 2006, chip wrote: > > Public headers are the ones in C<include/parrot> directory. These are > > included by embedders and extenders. They must not declare or define any > > symbol that isn't clearly Parrot-specific. Prefixing symbols with > > C<Parrot> > > > or C<PARROT> is the easiest & safest way, but it can lead to a lot of > > verbosity, so I'm willing to entertain exceptions or new conventions. > > > > It's OK for public headers might have non-public parts protected with > > C<#ifdef PARROT_IN_CORE>. Those non-public parts might #define shorter > > versions of the public symbols, e.g. C<#define foo Parrot_foo>. > > This appears closely related to what Chip posted in 40059, so I am > adding an RT refer link. > > Since this is not my area of expertise, would anyone care to comment?
There are pluses and minuses. Shorter code is nice, but there can be some confusion from people who want to write to Parrot's external API (long names) but read core code (short names). Likewise, someone who's used to writing to Parrot's external API might use the long names in a patch to the core. As well, judicious use of #define directives will let us make migrate functions to their long names while not having to refactor every place they occur in Parrot. With that in mind, it's probably a good idea in general, but at a lower priority than paring down the huge number of exported symbols. (That, at least, requires fixing dynpmc vtable initialization.) -- c
