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 <brentdax@cpan.org> @roles=map {"Parrot $_"} qw(embedding regexen Configure) He who fights and runs away wasted valuable running time with the fighting.Thread Previous | Thread Next