Re: Policy of refering to packages? Policy of choosing package for ML-compatible functions?

[Olaf Till]

 Wed, Dec 21, 2016 at 10:59:41AM -0800, PhilipNienhuis wrote:
> Well there was a discussion at the time of the polygon functions:
> i.e., whether they should go in OF-mapping, or in OF-geometry: see
> here.
> <http://octave.1599824.n4.nabble.com/Re-regarding-location-of-Matlab-compatible-polygon-functions-tt4676164.html#none>

Thanks, I didn't think of this later thread, but have recalled it to
me now. As an attempt of a summary:

1. There are arguments for adhering to ML toolbox contents, e.g. the
   convenience of already having a scheme to which we could
   adher. Also, not doing so could cause real code incompatibilities,
   presently (due to the 'pkg load' mechanism), and possibly in the
   future (due to the use of namespaces).

2. Some (most?) of us value the freedom to place functions in those
   packages which we think suitable higher.

Due to 2., I wouldn't think a decision to adher to ML toolbox
structure will find a majority, at least not presently.


But, to return to the original issue, the current practice of
referring to an OF package from Octave for functions not in core is
somehow in contradiction to the current situation -- it seems to
assume a ML toolbox structure.

A pragmatical suggestion, which could cope with either situation:

- At the OF website, keep a list of all functions with links to the
  corresponding package.

- In Octave, refer to this list instead of a certain package.


BTW, referring to an OF function from Octave, be it to a certain
package or to an overall list of functions, wouldn't be so good if
there was more than one OF package containing a function with this
name. Should there be an agreement that within OF no such duplications
occur? Maybe yes, why shouldn't we avoid name clashes if we can (of
course the list at OF should also contain all defined variables, not
only functions). But this again touches the issue of possible future
introduction of namespaces into packages.
  
Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature