On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> 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 P
On Tuesday 16 July 2002 01:02 am, Melvin Smith wrote:
> >It's also unnecessary. It isn't like there aren't perfectly good
> >alternatives--what's wrong with "Parrot__"?
>
> Well, what's wrong with Parrot_ ?
There's nothing wrong with Parrot_ -- as long as it isn't used *everywhere*.
A good thing
At 11:08 AM 7/15/2002 -0700, Damien Neil wrote:
>On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> > >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 [Parro
On Mon, Jul 15, 2002 at 12:34:52AM -0400, Melvin Smith wrote:
> >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]
It is a good idea to avoid using the reserved identif
Brent Dax writes:
>[EMAIL PROTECTED]:
># Good stuff. Didn't you also send out a draft PDD about how
># types should
># be named and managed in parrot at one point? I, for one,
>
>At one point I sent out a patch to PDD7 that handled type naming.
(I don't know what happened to this specific pa
Paul Kienzle:
# On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
# > On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > > -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 se
On Mon, Jul 15, 2002 at 02:26:55AM +, Ashley Winters wrote:
> On Monday 15 July 2002 02:25 am, Brent Dax wrote:
> > -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_ (fo
Brent Dax wrote:
> If people want that scheme, speak now or forever hold your peace.
Sounds reasonable to me. (FWIW)
> > _Parrot
> > _parrot
> > __Parrot
> > __parrot
>
> The last four are reserved by various C and C++ standards.
Damn, I forgot about that. I'm a C coder from Way Ba
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
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-c
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 h
Ashley Winters:
# On Monday 15 July 2002 02:25 am, Brent Dax wrote:
# > -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 perhap
[EMAIL PROTECTED]:
# Good stuff. Didn't you also send out a draft PDD about how
# types should
# be named and managed in parrot at one point? I, for one,
At one point I sent out a patch to PDD7 that handled type naming.
# would love to
# see a PDD that described C-level nanming and namespa
On Monday 15 July 2002 02:25 am, Brent Dax wrote:
> -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
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 particul
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. Par
Brent,
Good stuff. Didn't you also send out a draft PDD about how types should
be named and managed in parrot at one point? I, for one, would love to
see a PDD that described C-level nanming and namespace management in
general.
--Josh
At 3:11 on 07/14/2002 PDT, "Brent Dax" <[EMAIL PROTECTE
Ashley Winters:
# 1. Why is test_main.c not named main.c?
Because parrot.exe was originally named test_prog.exe, so at the time it
made sense for it to be called test_main.c.
# 2. What does having a Parrot_ prefix signify, considering
# both the opcodes and
# the embed api use it? It's hard to
Hrm, I had intended to put my questions at the end. I hit Send early.
Questions:
1. Why is test_main.c not named main.c?
2. What does having a Parrot_ prefix signify, considering both the opcodes and
the embed api use it? It's hard to distinguish between them.
3. What source files implement wh
19 matches
Mail list logo
