John Porter:
# Brent Dax wrote:
# > > 2. What does having a Parrot_ prefix signify, considering
# > > both the opcodes and the embed api use it?
# >
# > It signifies one of the following:
# > -This function is externally visible.
# > -This function belongs to Parrot at large, and not any particular
# > subsystem (e.g. Parrot_sprintf and friends). -This function has an
# > identical name to a C library function because it emulates it for
# > certain platforms (e.g. Parrot_dlopen (?)). -This function is
# > autogenerated, so we're going to be paranoid about naming
# conflicts.
#
# Maybe I'm just being naive... but it seems to me that if
# there are four different meanings, there should be four
# different actual prefixes.
Well, let's go over the justifications for the first three meanings
having Parrot_...
-External visibility: This is something we want to have unequivocally
identified with Parrot. Also, we don't want unnecessary stuff added on
(which is why we don't want Parrot_extern_ or something).
-General functions: This is something that doesn't belong to any
particular category, so we don't want to prefix it and artificially
categorize it.
-C library wrappers: This is Parrot's version of the function, so it
makes sense to prefix it with Parrot_.
The third category I can see having a prefix of plat_ (for platform) or
some such, and perhaps the second could have misc_, but I foresee that
becoming annoying. (Which seems better to you, Parrot_sprintf or
misc_sprintf?)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
