Embedding vs. extending interface types
Mattia Barbon
I feel I'm becoming annoying, but: the embedding and extending
interfaces are still using different names for Parrot_Interp/Parrot_INTERP.
Which one is correct?
Thanks!
Mattia
Gordon Henriksen
> I feel I'm becoming annoying, but: the embedding and extending
> interfaces are still using different names for
> Parrot_Interp/Parrot_INTERP. Which one is correct?
Mattia,
Both are correct. Sort of. :) Parrot_INTERP is an opaque type, which is
a technique for improving binary compatibility. In the core, which is
always compiled as a unit, the fields of the interpreter structure can
be accessed directly. But to preserve binary compatibility if the struct
layout is modified, embedders and extensions (which are built separately
from the core) must use accessor functions, and in fact do not generally
even have the struct definition.
Thus, in parrot/extend.h,
For non-core users: typedef void * Parrot_INTERP in non-core users
For core users: typedef struct Parrot_Interp * Parrot_INTERP for core
users
Looks like Parrot_INTERP is the best name to use in general, though.
This is rather on the unclear side. I would have clarified this by using
"private" or "opaque" on the internal name for the struct, or prefixing
with an underscore to indicate a private identifier—rather than
differentiating just by capitalization.
... okay, I'm beginning to agree with you. There's another name, Interp,
for the same structure, defined in parrot/interpreter.h. That, and
struct Parrot_Interp is a struct while Parrot_Interp is a pointer.
—
Gordon Henriksen
mali...@mac.com
Gordon Henriksen
> Mattia Barbon wrote:
>
>> I feel I'm becoming annoying, but: the embedding and extending
>> interfaces are still using different names for
>> Parrot_Interp/Parrot_INTERP. Which one is correct?
>
> [blahblahblah]
Spoke too soon. Parrot_INTERP looks unnecessary. Parrot_Interp already
has the needed opacity guards in place.
—
Gordon Henriksen
mali...@mac.com
Leopold Toetsch
AFAIK both. Embedding and extending are to different APIs. The former
has access to internals the latter doesn't. So they get different types
for e.g. the interpreter.
> Thanks!
> Mattia
leo
Mattia Barbon
> On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote:
>
> > I feel I'm becoming annoying, but: the embedding and extending
> > interfaces are still using different names for
> > Parrot_Interp/Parrot_INTERP. Which one is correct?
>
> Mattia,
>
> Both are correct. Sort of. :) Parrot_INTERP is an opaque type,
> which is
> a technique for improving binary compatibility. In the core, which
> is
I know that. The problem, as you note in your next mail, is:
Parrot_Interp already has opacity guards, and _is used as an opaque
type in embedding interface_. Now having two parts of the _external_
interface use differently-named opaque types for the same thing
seems pointless, if not confusing.
I personally prefer the internal and externalidentifier having the
same name, but I don't care, as long as the external interface is coherent.
> always compiled as a unit, the fields of the interpreter structure
> can
> be accessed directly. But to preserve binary compatibility if the
> struct
> layout is modified, embedders and extensions (which are built
^^^^^^^^^^^^^^^^^^^^^^^^
Currently, embedders use Parrot_Interp, while extenders use
Parrot_INTERP...
Regards
Mattia
Gordon Henriksen
> Mattia Barbon <mattia...@libero.it> wrote:
>
>> I feel I'm becoming annoying, but: the embedding and extending
>> interfaces are still using different names for
>> Parrot_Interp/Parrot_INTERP. Which one is correct?
>
> AFAIK both. Embedding and extending are to different APIs. The former
> has access to internals the latter doesn't. So they get different types
> for e.g. the interpreter.
All embedders see is this:
/* include/parrot/interpreter.h */
struct Parrot_Interp;
typedef struct Parrot_Interp *Parrot_Interp;
i.e., struct Parrot_Interp is declared, but never defined. So the extra
Parrot_INTERP type is just cruft. Also, it's not used anywhere in the
source tree except in extend.h and extend.c.
And does anyone ever use the Interp type from below?
/* include/parrot/interpreter.h */
typedef struct Parrot_Interp {
...
} Interp;
—
Gordon Henriksen
mali...@mac.com
Leopold Toetsch
> All embedders see is this:
> typedef struct Parrot_Interp *Parrot_Interp;
I don't do decisions on embedding or extending interfaces. But it seems
to be the time to decide (and clean/unite) the current names:
struct Interp* / struct Parrot_Interp* / Parrot_Interp / Parrot_INTERP
> Gordon Henriksen
leo
Gordon Henriksen
> Gordon Henriksen <mali...@mac.com> wrote:
>
>> All embedders see is this:
>>
>> typedef struct Parrot_Interp *Parrot_Interp;
>
> I don't do decisions on embedding or extending interfaces. But it seems
> to be the time to decide (and clean/unite) [...]
Speaking of cleaning and uniting, what is with this?
#define bufstart obj.u.b.bufstart
#define buflen obj.u.b.buflen
#if ! DISABLE_GC_DEBUG
# define pobj_version obj.pobj_version
#endif
#define struct_val ptrs._struct_val
#define pmc_val ptrs._pmc_val
#define cache obj.u
#define metadata pmc_ext->metadata
#define next_for_GC pmc_ext->next_for_GC
#define synchronize pmc_ext->synchronize
# define PMC_data(pmc) (pmc)->pmc_ext->data
#else
# define PMC_data(pmc) (pmc)->data
#endif
—
Gordon Henriksen
mali...@mac.com
Leopold Toetsch
> Speaking of cleaning and uniting, what is with this?
> #define bufstart obj.u.b.bufstart
> #define buflen obj.u.b.buflen
These are *currently* necessary macros, until the PMC/PObj layout is
really carved in stones. You had in your proposal a different PMC
structure layout. Testing such things is vastly simplified by having
accessor macros.
I'm not a friend of such macros. But they are needed as long as the
actual structure might change. I did introduce all pobj.h related
macros. They can go away, when *all* issues are resolved.
> Gordon Henriksen
leo
Gordon Henriksen
> Gordon Henriksen <mali...@mac.com> wrote:
>
>> Speaking of cleaning and uniting, what is with this?
>>
>> #define bufstart obj.u.b.bufstart
>> #define buflen obj.u.b.buflen
>
> These are *currently* necessary macros, until the PMC/PObj layout is
> really carved in stones. You had in your proposal a different PMC
> structure layout. Testing such things is vastly simplified by having
> accessor macros.
Yes, I know. ;) I was going to test a real layout change, but the macros
were so tangled up that I wound up just appending 4 ints to struct PMC
to simulate.
> I'm not a friend of such macros. But they are needed as long as the
> actual structure might change. I did introduce all pobj.h related
> macros. They can go away, when *all* issues are resolved.
I know what they are, and have no problem with them. I don't think they
should be removed. But this particular batch are a mess. I just
submitted a couple of patches to clean them up a little, though I didn't
get through the entire source tree yet.
—
Gordon Henriksen
mali...@mac.com
Dan Sugalski
>Il Sat, 24 Jan 2004 19:42:20 -0500 Gordon Henriksen
><mali...@mac.com> ha scritto:
>
>> On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote:
>>
>> > I feel I'm becoming annoying, but: the embedding and extending
>> > interfaces are still using different names for
>> > Parrot_Interp/Parrot_INTERP. Which one is correct?
>>
>> Mattia,
>>
>> Both are correct. Sort of. :) Parrot_INTERP is an opaque type,
>> which is
>> a technique for improving binary compatibility. In the core, which
>> is
> I know that. The problem, as you note in your next mail, is:
>Parrot_Interp already has opacity guards, and _is used as an opaque
>type in embedding interface_. Now having two parts of the _external_
>interface use differently-named opaque types for the same thing
>seems pointless, if not confusing.
And pointless. Let's just rename it to Parrot_Interp everywhere.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Gordon Henriksen
> And pointless. Let's just rename it to Parrot_Interp everywhere.
I've submitted a patch for this already.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
gor...@iclub.com