At 09:27 PM 7/14/2002 -0700, Brent Dax wrote: Wow, Brent lives! :)
>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. I always hear this, but in real life it is never much of a problem. Especially with a namespace like [Parrot] Honestly, reserved identifier's are one area I will always be admittedly ignorant about. C is not changing much nowadays, and the odds of there ever being a POSIX or ANSI api using any form of *Parrot* are, well, 0. So, I say use Parrot, _Parrot, or __Parrot with abandon and forever put this ANSI/POSIX collision argument to bed. >That means deciding what's harder and what's easier. Personally, I find >Parrot_ easier than plat_ to remember. I'll go along with either of your schemes, as long as we standardize on one and stick to it. That also means cleaning up all of the current names to match one or the other. -Melvin
