octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: odepkg private functions in core


From: Carnë Draug
Subject: Re: odepkg private functions in core
Date: Fri, 13 Nov 2015 12:18:18 +0000

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?
Or maybe we could move the odepkg functions that depend on them to core?

Carnë



reply via email to

[Prev in Thread] Current Thread [Next in Thread]