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
|