Howdy, Whiteknight++ asks some good questions that we need to seriously think about.
I think a utility that reads HLL source code and then prints out a list of deprecations with links to deprecation pages would mostly solve this problem. I am willing to help hack on this. We may also want to look into making something like Package::DeprecationManager [0] for Parrot. Deprecations will always happen. We need to make it as easy as possible for HLL devs to understand and respond to them. Duke [0] http://search.cpan.org/dist/Package-DeprecationManager/ On Tue, Nov 30, 2010 at 4:10 PM, Andrew Whitworth <[email protected]> wrote: > Several functions were renamed by GCI students to help get TT #443. > It's a deprecation item that has been eligible to be changed since > 1.4. > > I'm not against keeping the old names around (as macros) to help ease > the transition in theory. In practice, where do we draw the line? > There has already been almost 2 years notice that the change would be > coming. We've followed all the deprecation policy guidelines and > waited plenty of time after eligibility to make these changes. How > long do we need to keep exporting those names for the purpose of > easing the transition? Forever? > > I'm not trying to be facetious, I really do want to know for future > reference what people expect to happen when we make a C-level API > change like this. There comes a point in the process when we need to > stop offering the old function and start expecting people to be using > the new version. Knowing when that point should be is going to be > extremely important for us in the coming months, so we should figure > it out now. > > I'm happy to put together a patch for Rakudo tonight. I can get > started on that soon. I'm also happy to continue supporting the old > name of this function as a macro if we have a clear plan for when such > a duplicate should be offered and for exactly how long. Saying that > we're going to backwards-support all C-level function interfaces > forever is really not something I would support. > > The function in question has been renamed to > Parrot_hll_get_ctx_HLL_namespace, for reference. > > --Andrew Whitworth > > > > On Tue, Nov 30, 2010 at 5:35 PM, Andy Dougherty <[email protected]> > wrote: >> Rakudo won't build with the current parrot master. The first error >> message is about the function 'Parrot_get_ctx_HLL_namespace'. Were some >> functions renamed? If so, the old names should still be kept around as >> wrappers for the new names, at least for a while. >> >> (Breakage like this makes it really hard to reliably bisect for important >> changes.) >> >> -- >> Andy Dougherty [email protected] >> _______________________________________________ >> http://lists.parrot.org/mailman/listinfo/parrot-dev >> > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Jonathan "Duke" Leto [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
