On 21 October 2015 at 15:59, Rik <address@hidden> wrote:
On 21 October 2015 at 09:03, Jacopo Corno <address@hidden> wrote:
Dear all,
While doing the cleanup in odepkg after moving functionalities in core, I
realized a problem in the current structure.
For odepkg to work with 4.2, some of the functions that are currently
private need to be accessible. They should not be used directly by the user,
but some of the solvers in odepkg need access to:
integrate_adaptive.m
integrate_const.m
integrate_n_steps.m
odepkg_event_handler.m (now ode_event_handler.m)
ode_struct_value_check.m
starting_stepsize.m
The functions that remain "really" private are:
AbsRel_Nom.m
kahan.m
runge_kutta_interpolate.m
and the steppers (runge_kutta_45_dorpri.m and the steppers of whichever
solver we will move to core).
Is it possible to move them out? Or is there a better solution to deprecate
their direct access by the user?
Cheers,
Jack
This occasionally happens. I can think of three solutions immediately, but
maybe someone else can think of something better.
1) Have the "pkg load" script for odepkg add the core ode/private directory
to Octave's path.
2) Move the helper functions up from the private directory into the ode
directory. Rename them to have '__' prefix and postfix which indicates that
they are really for internal use even though they are visible to the
programmer. See, for example, scripts/plot/util which has
__plt_get_axis_arg__.m, __default_plot_options__.m, etc.
3) Have the "pkg install" script copy over the necessary files from
ode/private into the odepkg's own private directory. Given that you can't
install a package without having core Octave around, these will always be
available for copying.
I'm not sure those are good ideas. If the functions are private, core
makes no promise over those functions interface, not even their
existence in future releases.
If they are useful by other non-core functions, could it be argueed they
would be useful for the users too, and therefore should be made public?