help-octave
[Top][All Lists]
Advanced

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

Re: Best practices for loading packages


From: JuanPi
Subject: Re: Best practices for loading packages
Date: Thu, 27 Mar 2014 14:05:18 +0100

On Thu, Mar 27, 2014 at 12:38 PM, Daniel Kraft <address@hidden> wrote:
> Hi!
>
> I've recently started to appreciate what packages can do to keep code
> structured in Octave.  Now I'm wondering what the "best practices" for
> loading packages are.
>
> In particular, if I write a function "foo" that uses some package "bar",
> and then use the function itself from my main program.  What I'm
> currently doing in the main script is something like this:
>
>   clear ("all");
>   pkg load bar;
>   ... other things ...
>   foo ();
>
> I. e., I load the package together with a lot of other "initialisation"
> things right at the beginning of each main program that uses foo.
> However, in some sense this seems not optimal -- a user of foo need not
> necessarily know that foo uses package "bar", and also the main program
> may not need or even want the package to be loaded (except indirectly
> for using foo).
>
> Hence, I can also load all necessary packages in foo directly.  This
> ensures that users of the function need not worry about loading all
> required packages (which should be "hidden implementation details" of
> the function).  However, this still leaves the package loaded for the
> main program -- and without even explicitly stating that the package is
> loaded there, it may lead to even more confusion / problems if the
> package clutters the namespace in an unexpected way.
>
> Unloading "bar" when the function returns is also not possible, since it
> is not guaranteed that the package is indeed not used anywhere else....
>
> What is the recommended way of handling this situation?  Just load all
> packages in the main program?  Or is there a way to "ensure" that a
> package is loaded just for the scope of a function executing?  (Similar
> to #include of headers in some .cpp file or import directives in certain
> languages that only concern a "local" scope (one compilation unit).)
>
> Thanks!  Yours,
> Daniel
>
> --
> http://www.domob.eu/
> OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
> Namecoin: id/domob -> https://nameid.org/?name=domob
> --
> Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
> To go: Mon-Pri
>
>
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/help-octave
>

Hi,

I do not know of any solution at the moment. My usual approach is to
let the user know what packages are needed and I do not do any
automatic loading, just raising errors when the function is not found
(or leaving octave to do that). The dependencies of a packages need to
be known by the user and they are readily accessible in the
DESCRIPTION file.

The way packages are working so far is just to group functions and
they still behave like monolithic entities. Carnë has many times
discussed the idea of having a function per package import in the way
python does this. It would be nice, but sounds like loads of work, a
major change! Is it worth? I do not know, so far I can work with
packages without problems.

Additionally one could think of a "local" option to package load, int
eh way warnings and errors can be switched off and on. But this is
just loading at one point and unloading when the tasks are finished,
which you already considered as a bad solution. Again, I see no need
to do this if you accept that packages should be loaded by the time
another package that depends on them is going to be used. A crazy
idea-solution to this problem would be to have "higher level"
namespaces, and when a package is loaded the functions are decorated
with it, so one could call "plot" and use the base (or the latest
whatever is more efficient to implement) plot function or
my_package::plot to use a function of a packaged that was loaded and
shadows the base function. Ideas, ideas, ideas... good? bad? I let the
software engineers decide. This could also be implemented if packages
are objects and the functions implemented on them methods of the
package object, something that would be implementable when we have
classdef... if you wanna go Java-ish.

So answering your question: Let the user do the loading unloading of packages.






-- 
JuanPi Carbajal
-----
"Ave Imperator, moritvri te salvtant"
Naumachiarii, AD 52



reply via email to

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