Re: [office-formula] User-Defined Functions

[robert_weir@us.ibm.com]

A specific example.  A company called Foo.com writes an extension library 
of functions for Excel.   One function is called Bar().   How should this 
functions be written out?

1) COM.MICROSOFT.Bar()?

2) COM.FOO.Bar()?

3) User.Bar()?

Approach #1 or #3 will lead to collisions.  Approach #2 is similar to how 
namespaces work with code libraries. It does not guarantee lack of 
collisions, but encourages providers of libraries to choose unique 
namespaces.

Also, consider that at some point we might have interoperable extension 
functions, meaning functions that are defined in terms of other standards, 
like XPath expressions, JavaScript or web services calls.  In that case, 
the extension function is not tied to any single implementation.  So it 
would not make sense to bind it to the editor's namespace, since the same 
extension function might be used in multiple editors.

So I wonder if we merely should describe a namespace mechanism and say 
that the default namespace is null and that the default namespace is 
reserved and no extension functions shall be in the default namespace. 
Whether extension functions use the namespace "User" or "COM.Foo" or 
"COM.Microsoft" is really none of our business.

A reasonable thing for an implementation to do would be:

1) When an end-user defines a new function, give it a namespace prefix,, 
either based on a GUID, the user's initials,time stamp or something else 
believed to be unique.  "User" would not be optimal since it would likely 
clash.

2) When writing a library of functions for re-use across spreadsheets, 
implementations might have to allow the user to assign a more meaningful 
prefix.

3) Where an implementation ships with its own built-in extensions, it 
should probably name them as COM.Microsoft.Excel or similar.

These are reasonable guidelines, but I don't think we need to specify 
these.  It would be enough to simply say that no extension functions shall 
use the default (null) namespace.


-Rob

Eike Rathke <erack@sun.com> wrote on 06/16/2010 10:06:36 AM:

> 
> Hi Robert,
> 
> On Thursday, 2010-06-03 11:42:12 -0400, Robert Weir wrote:
> 
> > > They have been briefly discussed. The outcome was that 
implementations
> > > should write them prefixed with "USER.", this seems not to have made 
it
> > > into section 5.7
> > 
> > 
> > Should there any difference between an implementation-specific 
extension 
> > function and a user-specific extension function?  I think there might 
also 
> > be 3rd party libraries of extension functions.
> 
> Implementation-specific extension functions should start with domain
> names as lined out in section 5.7, e.g. ORG.OPENOFFICE.* or 
COM.MICROSOFT.*
> 
> I think the "USER." prefix should be applied to all extension functions,
> user-defined or third party, that do not use the domain name approach.
> 
> > Main concern now is name collisions.  Simply saying 
USER.CurrencyConvert() 
> > may prevent the name from colliding with future intrinsic functions in 

> > OpenFormula that might use the name "CurrencyConvert", but it doesn't 
> > prevent collisions between two users with the same function name.
> 
> I don't see how we could prevent that. Introducing some sort of per
> document prefix or UUID would still not help for or disable library
> functions that have the same name on different systems / user
> installations and are doing actually the same. We can only recommend to
> library developers to use the domain name approach.
> 
>   Eike
> 
> -- 
> Automatic string conversions considered dangerous. They are the 
GOTOstatements
> of spreadsheets.  --Robert Weir on the OpenDocument formula 
> subcommittee's list.
> [attachment "att5lxlz.dat" deleted by Robert Weir/Cambridge/IBM]