Re: odepkg private functions in core

[rik]

On 11/13/2015 04:18 AM, Carnë Draug wrote:
> 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?
It didn't sound to me like these functions were generally useful, and
therefore making them public wasn't a good idea.

> Or maybe we could move the odepkg functions that depend on them to core?
Jacopo can comment, but it seemed like a large number of solvers would
depend on the three integrate_XXX functions so moving the odepkg functions
that depend on them would really mean eliminating odepkg and adding lots of
the solvers to core.

--Rik