An alternative FFI/Parser proposal
Klaus D. Witzel
klaus.witzel at cobss.com
Thu Aug 17 10:03:57 UTC 2006
On Thu, 17 Aug 2006 10:16:27 +0200, Andreas Raab wrote:
> Klaus D. Witzel wrote:
>> Nice if it would also provide some support for Lukas' suggestion, IMO.
>> Being able to browse senders of #apicall: and #cdecl: (e.g. any such
>> construct) is definitively an advantage (a free beer).
> Yes that would be nice. Got some time to spend on it? ;-)
Sure, I have. But don't wait for it. ExternalObject and friends have
priority 7 here (just one below InterpreterSimulator ;-)
>>> Unfortunately, there are also a couple of gotchas with the proposal:
>>> Most importantly, it requires that any parser can hand off the current
>>> input stream to a client and continue after it's getting the stream
>>> back. Not sure if all parsers could easily do that.
>> I can already see all the skip: -2's when the stream is passed ;-) How
>> about passing an interface to parser (a specialized contract which
>> delegates). That'd be a clean implementation.
> Yes, that would be the nicer solution if parsers can agree on a common
> protocol. However, I'm not sure that's doable (and it seemed to
> complicate the overall Gestalt of the proposal) so that in the mindset
> of proposing the simplest thing that all parties could agree on I just
> proposed a plain input stream.
NP (stream would be sufficient) but how about forcing parser packages to
subclass the contract? The contract could take responsibility for FFI
being present or not " parser notify: 'support for external objects not
installed in your image' ".
>>> In any case, this is a clear alternative that offers the same benefits
>>> of the original proposal ("clean", "extensible") while avoiding
>>> fundamentally breaking the FFI for no good reason.
>> Let the next user in her/his next project decide how to use FFI, how
>> about that.
> I don't understand what you mean by that. In which way would the user
> decide "how to use FFI"?
I meant, the parser/compiler writer is a user and transitively so is the
parser's user. If a parser/compiler package provided an alternative way to
use FFI, that would be the choice I had in mind.
>>> If anyone were to implement that proposal it would certainly find my
>> After all this embarrassment which was already exchanged?
> I have said from my first post that changing the FFI syntax is out of
> the question but that I'm open to discuss any alternatives. Nothing has
> changed from that.
[OT] NP but this was not my point :|
> - Andreas
More information about the Squeak-dev