Bryan C. Warnock:
# On Tuesday 26 February 2002 14:31, Brent Dax wrote:
# > 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?
#
# Depending on how you're wired, it makes things more complex
# on the outside.
# You've, in essence, doubled the number of types that need to be known.
# If any type needs to be passed by reference, you can't simply
# & and * it -
# you have to determine what the new, proper type is. (Well,
# you don't have
# to, unless you've one of the picky compilers, which makes a
# lot of this
# discussion moot.)
How is this the case? STRING ** and Parrot_String * are equivalent.
You can use & on both a STRING * and a Parrot_String to get a STRING**
(a.k.a. a Parrot_String *). I don't see where the problem is.
# Embedders and extenders understand pointers and addresses.
# What's more
# important is hiding the guts behind the label, not what the label is.
True, but as long as we're re-labeling things we might as well make the
labels reflect usage. I seriously doubt any embedder will need to
create a string or PMC themselves--and, in fact, that won't be possible
since the size of string and PMC structs won't be known to embedders or
extenders. There's no point in giving them the chance to screw up.
Let's say that strings are defined to embedders as such:
struct parrot_string_t;
typedef struct parrot_string_t Parrot_String;
Doing something like this:
int main() {
Parrot_String foo;
...
}
won't work anyways, since we don't know anything about a parrot_string_t
other than the fact that it exists. That throws a compiler error, and
the embedder will have to dig around in the docs to find out that he
needs that to be a pointer.
Now, if the typedef was:
typedef struct parrot_string_t *Parrot_String;
then you can declare a Parrot_String and it'll Just Work. There's no
loss in functionality because a bare parrot_string_t is illegal anyways.
I just don't see any compelling reason to expose the fact that
Parrot_Strings and Parrot_PMCs should only be declared as pointers.
It's an unnecessary complication that doesn't yield any extra
functionality.
--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
