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
# >'struct' name--inside the core you'll use String or PMC or
# whatever, and
# >outside you'll use Parrot_String or Parrot_PMC or whatever.
#
# Inside the core, there'll be no prefixes. Outside the core there'll
# be a prepended Parrot_.
#
# I don't want any postfix _t. Or any other pre or post fix inside the
# core. I don't see the point, honestly.
How about differentiating between struct and non-struct versions of
things?
At least the names of structs *must* be externally visible. Otherwise
we can't define external typedefs in terms of them. If the names are
externally visible, they have to be safe. Therefore, structs must have
the parrot_ prefix.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
#define private public
--Spotted in a C++ program just before a #include
