Are there examples of extensions?

[geoffcanyon]

There seem to be many examples of widgets, but are there any examples of simple language extensions?

[trevordevore]

Here is a library example: https://github.com/runrev/livecode/blob ... canvas.lcb

[LCMark]

@geoffcanyon: There's only one library example at the moment - you can find it here - https://github.com/runrev/livecode/tree ... ies/canvas. (Warning: I've not updated this in a while - so it might not work out of the box).

[trevordevore]

I just set up a github repository where I will keep my public extensions. There is a url_parser library that you can take a look at as well.

https://github.com/trevordevore/livecode-extensions

Note, however, that I develop against the latest Develop branch so there is some syntax in the library that may not compile in do-1. For example, the library uses 'returns String' rather than 'as String' when defining the return value of a handler.

[geoffcanyon]

Thanks, Trevor and Mark, I'll have a look.

[Peter Wood]

@Trevor

I notice that you use the "identifier" community.livecode.trevordevore in your extension. Is it standard to use community.livecode?

I was wondering if, given that anybody with a commercial subscription is eligible for an @livecode.org address, it would be good to use org.livecode as the standard naming for community contributions.

[LCMark]

@PeterWood: Anyone can register for an account to use with the extensions store - if you do, then you get a prefix community.livecode. The global naming of packages uses reverse host name convention - we (LiveCode Ltd) control community.livecode and bought the domain for the purpose of providing anyone with a globally-unique naming prefix for their packages.

You will be able to provide your own domain for use in this way eventually too - we will be setting up a domain verification system (a bit like google uses for certain things). This will be just so that we can verify that the person asking to use that domain actually controls it.

In terms of livecode.com/livecode.org; at the moment we are reserving these prefixes for certain uses. For example, the widgets that we (LiveCode Ltd) explicitly write, maintain and support will have a com.livecode prefix. In terms of livecode.org then I'm still considering this - it is unlikely it will be allowed for general use, but might well be 'given' to a group which is endowed with the responsibility for managing collections of widgets and extensions developed by contributors (or at least something along these lines).

These kinds of things are still in their early days and we have on the list a couple of things to ensure names we choose now don't tie us forever. In particular:

The ability to change the kind of a widget at runtime - http://quality.runrev.com/show_bug.cgi?id=14942 - this would be a short-term measure, allowing users to run a simple script to rebind any widgets on a stack to a renamed variant.

The ability to create an 'alias' package which forwards an old name to a new one - http://quality.runrev.com/show_bug.cgi?id=14947 - this is the 'correct' way to do the above. The idea here is that should the name of a published package need to change, you create the new one containing the actual implementation, then re-create the old way which is simply a redirect. When both are installed into the IDE, when a stack is re-saved any widgets bound to the old named package will automatically rebind to the new one.

[Peter Wood]

@Mark Many thanks for the clear and comprehensive explanation. The approach makes a lot of sense.