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
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
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
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
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
"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
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
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
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
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
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
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
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
-
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
To: Dan Sugalski <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subjec
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
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
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
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
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
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
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
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
23 matches
Mail list logo