On 9 January 2013 09:39, S Krish <[email protected]> wrote:
>
>
> The issue is not limited to only pragma as the route, it can the
> CompiledMethod extension or any. Eventually stripping source/ disconnecting
> the sources / changes file is an expectation....
>
> Otherwise can there be an easy way of truncated changes / sources file of
> the NativeBoost part alone read only that can allow the functionality as is.
>
> Bar this part of the code I am sure all the rest can be a pragma, so may
> need to figure that out..how this may fit in compile / parse .
>
Potentially you could move things to pragmas,
but at cost of increased complexity and losing flexibility.
Putting things into pragmas will heavily dictate how you should
organize your code,
and will lead to canonization of interface, which will be very hard to
change later (if you need that).
Original FFI implementation is a good example of that, where the
syntax of <cdecl: ..>
are not compatible with common pragma syntax. And the problem is ,
that once choice was done (no matter how good or bad it is), now it is
really hard to change it.
But then imagine, how you could turn this to pragmas:
^ self nbCall: self signature module: self module options: self options
or this:
^ self nbCallout
function: #( int foo())
address: [ self getMyFunctionAddress ]
The only thing you need right now is to capture arg names, so indeed,
we need a pragma to indicate an intent, something like:
<captureArgNames>
^ self nbCall: self signature module: self module options: self options
But as i said before, i don't want to hack compiler right now, i
postpone changes for Opal.
Then you will be able to write something like that:
shellExecute: lpOperation file: y parameters: z directory: w show: v
<nativeCall>
^ self nbCall: .... module: 'Shell32.dll'
the rest will be handled under the hood (including things like working
without source code).
--
Best regards,
Igor Stasenko.
