On Friday 28 July 2006 10:23, Leopold Toetsch via RT wrote: > Am Freitag, 28. Juli 2006 18:41 schrieb chromatic:
> > Hm, sort of. Is there any reason not to call it from Parrot_new() and > > not make the C API users do it? > > Well, when the next (and maybe common) step is: > > pf = Parrot_readbc(interp, sourcefile); > > then the creation of the dummy PF structure was in vain. I.e. the dummy is > only needed for _compile_string and friends. > > We could create a new API > > Parrot_new_with_PF(Parrot_Interp parent, const char *pf_name) > > or such though, which does both. I would use this one all the time instead of Parrot_new() then (and I don't know why pf_name is necessary; that's just noise that people shouldn't have to provide -- why make people pass in "dummy" if they'll always pass in "dummy"?). In general, I don't know *how* users will use the embedded Parrot, whether they'll ever load any bytecode or will only ever always compile code from strings. To my mind, instead of having two calls which do almost similar things depending on how well you predict code paths, we ought to have a single default which does something harmless in the load_bc() case and does something necessary in the other case. -- c
