If memory serves me right, Dan Sugalski wrote: > I do actually like it. I was shooting for simplicity with the > assumption that, since we were calling out to non-parrot-aware code, > all bets were off with respect to type safety. If you load in > libgtk.so and call functions dynamically there's not much we can do > with respect to proper security.
Well IMHO you can't add in any type safety in between parrot and C ... All I am suggesting is that .. 1) As far as possible .. have a sort of "extern" declaration in parrot domain, so we get a warning from the compile when I try to call that function in the .pbc file ... Sort of proxy for the native call ?.. A sort of check for type of param and number ... 2) When you are using it directly (unsafe) ... you deserve it if it blows up ... dlopen , dlsym does it frequently with me ... ;-) This 2 pronged approach is IMHO the ideal way ... afterall perl is all about many ways to do the same thing ... > >But well ... I should admit , I'm just trying to make the C# to parrot > >compilation as safe as IL .... (PInvoke and stuff...) > > No problem with that. I think you're not going to get it by default, > since my big thing's speed, but it does mean we need to reevaluate > things, since we need typechecking in safe code. Well if we can generate verifiable IL ... we should be able to generate type-safe Parrot code ... That's more of a language feature than bytecode feature .. What I was concerned was that we wouldn't have an extern definition for the native call to check if the actual params in C# are correct and of the same type as the formal params of the native func... Especially if we're going to check the calls before runtime ... (as is customary in static typed languages)... Hope I make myself clear, Gopal -- The difference between insanity and genius is measured by success
