Re: Coding standards (was Re: typedefs)

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 19:40, Nicholas Clark wrote: > On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote: > > Besides, struct etc. are their own namespace, aside from the normal > > variables/functions namespace. No need for any pre/postfix at all. > > Until someone wishes to em

Re: Coding standards (was Re: typedefs)

2002-03-22 Thread Nicholas Clark
On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote: > Besides, struct etc. are their own namespace, aside from the normal > variables/functions namespace. No need for any pre/postfix at all. Until someone wishes to embed the public headers into a C++ program. Or finds themselves

Re: typedefs

2002-03-22 Thread Nicholas Clark
On Fri, Mar 22, 2002 at 11:52:16AM -0500, Melvin Smith wrote: > On Friday 22 March 2002 11:36, Dan Sugalski wrote: > > At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote: > > I'm up in the air as to whether any of the core routines should have > > a Parrot prefix--I'm thinking not, as I don't think

RE: typedefs

2002-03-22 Thread Brent Dax
Dan Sugalski: # At 3:53 PM -0800 3/22/02, Brent Dax wrote: # >Bryan C. Warnock: # ># > Besides, what's the probability it'll be a problem if we # prefix all # ># > struct names with 'parrot_'? # ># # ># You don't really want to do that, do you? # > # >Yes, in fact, I do. In the general case, you

RE: typedefs

2002-03-22 Thread Dan Sugalski
At 3:53 PM -0800 3/22/02, Brent Dax wrote: >Bryan C. Warnock: ># > Besides, what's the probability it'll be a problem if we prefix all ># > struct names with 'parrot_'? ># ># You don't really want to do that, do you? > >Yes, in fact, I do. In the general case, you will never have to use the >'str

Re: Coding standards (was Re: typedefs)

2002-03-22 Thread Segher Boessenkool
"Bryan C. Warnock" wrote: > > On Friday 22 March 2002 17:53, Russ Allbery wrote: > > Brent Dax <[EMAIL PROTECTED]> writes: > > > > > Parrot_Foo for external names, FOO for internal names, struct > > > parrot_foo_t for struct names. > > > > POSIX reserves all types ending in _t. I'm not sure th

RE: typedefs

2002-03-22 Thread Brent Dax
Bryan C. Warnock: # On Friday 22 March 2002 18:05, Brent Dax wrote: # > Russ Allbery: # > # Brent Dax <[EMAIL PROTECTED]> writes: # > # > Parrot_Foo for external names, FOO for internal names, struct # > # > parrot_foo_t for struct names. # > # # > # POSIX reserves all types ending in _t. I'm not

Re: typedefs

2002-03-22 Thread Russ Allbery
Brent Dax <[EMAIL PROTECTED]> writes: > Russ Allbery: > # POSIX reserves all types ending in _t. I'm not sure that extends to > # struct tags, but it may still be better to use _s or something else > # instead to avoid potential problems. > My understanding is that it only reserves types that s

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 18:05, Brent Dax wrote: > Russ Allbery: > # Brent Dax <[EMAIL PROTECTED]> writes: > # > Parrot_Foo for external names, FOO for internal names, struct > # > parrot_foo_t for struct names. > # > # POSIX reserves all types ending in _t. I'm not sure that extends to > # struct

Coding standards (was Re: typedefs)

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 17:53, Russ Allbery wrote: > Brent Dax <[EMAIL PROTECTED]> writes: > > > Parrot_Foo for external names, FOO for internal names, struct > > parrot_foo_t for struct names. > > POSIX reserves all types ending in _t. I'm not sure that extends to > struct tags, but it may sti

RE: typedefs

2002-03-22 Thread Brent Dax
Russ Allbery: # Brent Dax <[EMAIL PROTECTED]> writes: # > Parrot_Foo for external names, FOO for internal names, struct # > parrot_foo_t for struct names. # # POSIX reserves all types ending in _t. I'm not sure that extends to # struct tags, but it may still be better to use _s or something else

Re: typedefs

2002-03-22 Thread Russ Allbery
Brent Dax <[EMAIL PROTECTED]> writes: > Parrot_Foo for external names, FOO for internal names, struct > parrot_foo_t for struct names. POSIX reserves all types ending in _t. I'm not sure that extends to struct tags, but it may still be better to use _s or something else instead to avoid potenti

Re: [PATCH] base types (was Re: typedefs) [APPLIED]

2002-03-22 Thread Dan Sugalski
At 11:53 AM -0500 3/22/02, Bryan C. Warnock wrote: >On Friday 22 March 2002 11:46, Dan Sugalski wrote: >> That's fine. Throw in typedefs for both ways to start, so we can do >> this incrementally, if you would. Applied, thanks. -- Dan -

[PATCH] base types (was Re: typedefs)

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 11:46, Dan Sugalski wrote: > That's fine. Throw in typedefs for both ways to start, so we can do > this incrementally, if you would. Index: config_h.in === RCS file: /home/perlcvs/parrot/config_h.in,v retriev

Re: typedefs

2002-03-22 Thread Melvin Smith
To: Dan Sugalski <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subjec

Re: typedefs

2002-03-22 Thread Dan Sugalski
At 11:41 AM -0500 3/22/02, Bryan C. Warnock wrote: >On Friday 22 March 2002 11:36, Dan Sugalski wrote: >> At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote: >> >We're still all over the place with typedef name formats. We've FOO, Foo, >> >and foo_t. We tried to hash this out before, but we di

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 11:36, Dan Sugalski wrote: > At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote: > >We're still all over the place with typedef name formats. We've FOO, Foo, > >and foo_t. We tried to hash this out before, but we didn't come to a clear > >consensus. (We got sidetracked b

Re: typedefs

2002-03-22 Thread Dan Sugalski
At 10:02 AM -0500 3/22/02, Bryan C. Warnock wrote: >We're still all over the place with typedef name formats. We've FOO, Foo, >and foo_t. We tried to hash this out before, but we didn't come to a clear >consensus. (We got sidetracked by typedeffing pointers to typedefs.) All Parrot typedef'd t

RE: typedefs

2002-03-22 Thread Brent Dax
Bryan C. Warnock: # On Friday 22 March 2002 10:36, Brent Dax wrote: # # > # > Parrot_Foo for external names, FOO for internal names, struct # > # > parrot_foo_t for struct names. Now let's argue about if # > # Parrot_Foo is # > # > typedefed as a pointer or not. ;^) # > # # > # Oy vay!, none of

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 10:36, Brent Dax wrote: > # > Parrot_Foo for external names, FOO for internal names, struct > # > parrot_foo_t for struct names. Now let's argue about if > # Parrot_Foo is > # > typedefed as a pointer or not. ;^) > # > # Oy vay!, none of which match PDD 07. Except that

RE: typedefs

2002-03-22 Thread Brent Dax
Bryan C. Warnock: # On Friday 22 March 2002 10:07, Brent Dax wrote: # > Bryan C. Warnock: # > # We're still all over the place with typedef name formats. # > # We've FOO, Foo, # > # and foo_t. We tried to hash this out before, but we didn't # > # come to a clear # > # consensus. (We got sidetrac

Re: typedefs

2002-03-22 Thread Bryan C. Warnock
On Friday 22 March 2002 10:07, Brent Dax wrote: > Bryan C. Warnock: > # We're still all over the place with typedef name formats. > # We've FOO, Foo, > # and foo_t. We tried to hash this out before, but we didn't > # come to a clear > # consensus. (We got sidetracked by typedeffing pointers to t

RE: typedefs

2002-03-22 Thread Brent Dax
Bryan C. Warnock: # We're still all over the place with typedef name formats. # We've FOO, Foo, # and foo_t. We tried to hash this out before, but we didn't # come to a clear # consensus. (We got sidetracked by typedeffing pointers to typedefs.) # # What's it going to be? Parrot_Foo for externa