FFI and apicall/cdecl type

Andreas Raab andreas.raab at gmx.de
Wed Jul 19 07:22:59 UTC 2006


mathieu wrote:
> I don't understand why you have to ask in 2 different way the
> ExternalType (xType := descriptorClass atomicTypeNamed: here and xType
> := descriptorClass structTypeNamed: sym)?

There is no particular reason that I remember why there isn't a unified 
interface like #typeNamed:. I think it's probably because this code 
changed a number of times and I wrote it under pressure and never looked 
at it again (hey, it works just fine even if it ain't the most pretty 
code ;-) There are reasons why you'd have to know in other places but 
the parser really couldn't care less.

> What the mssage #hasInterned:ifTrue: served for in this case?

Only as an optimization (if there isn't an interned name for the type we 
don't even need to check). I *vaguely* seem to remember that the 
structure management used to be a lot more complex than it ultimately 
ended up being; this might also explain why I'd split the two into the 
(cheap) atomic test and an (expensive) struct variant.

Note that the line saying "self interactive ifTrue:[^nil]" *is* relevant 
however. What it does is to disable the "forward declaration" of 
external types that are used in FFI calls. It is required since two 
ExternalTypes can refer to each other in their methods (e.g., 
TypeA>>methodA using TypeB and TypeB>>methodB using TypeA) and without 
this forward declaration feature you'd never be able to load any such 
classes. The particular line simply disables that when you use an 
interactive input (browser) to ensure that you do indeed declare the 
types when you use the parser interactively.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list