John Porter:
# Brent Dax wrote:
# > Ashley Winters:
# > > c. parrot_sprintf
# >
# > Lowercase is always the hallmark of struct names, i.e.
# > parrot_string_t.
#
# Ehhh... you yourself said something about plat_ and misc_
# as (theoretical) alternatives.
#
# Anyway, it's a silly rule. Upper-case (and lower-case) are
# going to have to do multiple duty.
Here's the rules, roughly as they stand right now:
-Functions start with Parrot_[a-z] or just [a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with PARROT_[A-Z] or just [A-Z].
-Struct names are of the form parrot_[a-z_]+_t.
Perhaps we should change the rules to this:
-Public functions start with Parrot_[a-z].
-Typedefed names start with Parrot_[A-Z] or just [A-Z].
-Macros and constants start with PARROT_[A-Z] or just [A-Z].
-Struct names are of the form parrot_[a-z_]+_t.
-Private functions start with parrot_[a-z] or just [a-z].
If people want that scheme, speak now or forever hold your peace. :^)
# Here's four:
#
# Parrot
# parrot
# _Parrot
# _parrot
#
# Here's two more:
#
# __Parrot
# __parrot
The last four are reserved by various C and C++ standards.
# Public API clearly should be Parrot. Any decisions regarding
# the rest should be for the benefit and convenience of us the
# developers. Right? Why make things harder for ourselves?
That means deciding what's harder and what's easier. Personally, I find
Parrot_ easier than plat_ to remember.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
He who fights and runs away wasted valuable running time with the
fighting.
