Dan Sugalski:
# At 10:31 AM -0800 2/26/02, Brent Dax wrote:
# >Different scopes, different policies. Outside the core (and
# in places
# >with external visibility) we use the Parrot_Foo-type
# pointer-to stuff;
# >inside we use FOO. *This is the same policy we have now*, except for
# >the outside the core part. I want that because I want to present a
# >unified, simple interface to embedders so they don't have to
# sweat the
# >small details.
#
# Hrm. I think I'd prefer to not have differently named typedefs for
# things and pointers to things. We can hide the core struct from the
# outside, but I'd rather not change type things. If it's STRING
# inside, it should be Parrot_String outside, assuming we even expose
# our internal string type in any way.
#
# At the moment I'm not really sure we should be exposing anything past
# PMC and keys, but...
I don't think we can get away with not exposing strings. They're used
everywhere, and they represent tangible data that users will want to get
at.
# >I *really* don't want their program to not work because
# >they typed "Parrot_String" instead of "Parrot_String *".
#
# They'll run into the same problem if they type char instead of char
# *. Those things we don't have to worry about--their compiler will
# catch it, and if it doesn't, well, bugs happen.
But they'll know about char* unless this is their first C program. I
don't think we should expect them to know which of our types should be
used as pointers and which shouldn't.
Look at it this way. Pro: it makes things simpler for embedders and
extenders. Con: it isn't quite the same as the way types are done
internally. Which is more important?
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking, regex hacker, embedding coder, and boy genius
#define private public
--Spotted in a C++ program just before a #include
