Writing Extensions

[Mark Waddingham]

On 2017-05-18 18:18, Mark Wieder via use-livecode wrote:
> That's unfortunate. It means that, aside from distributing the widget
> source code, compiled widgets are bound to a specific LC version with
> no guarantee that they will work with any other past or future
> version. Does 'major version' here mean 9.x or 9.0.x? Can I assume
> that the binary format will stay the same across all LC9.x releases?

I'm not sure it as much of a problem as it first appears to be - because 
much the same is true of LiveCode Script.

If you write a script in 9 which uses features of 9, it will not work in 
any version less than 9.

If you write a script in 8 then yes, we work very hard to ensure that 
scripts will work exactly the same in 9.

So LiveCode Script is source forward-compatible (because we work had to 
make it so); but not source backward-compatible.

Now, much the same is true of LiveCode Builder in terms of 
source-compatibility (any source-compatibility issues should be reported 
so we can look into it). However, currently, LiveCode Builder compiles 
to a bytecode format which we do not guarantee inter-major version 
compatibility of currently (whether 'major version' here is the first 
version point, or first two version points is immaterial - we do 
guarantee binary compatibility between maintenance releases).

However, 8.1.x module format is fixed and will not change, as is 
lc-compile and the lcb standard library. This means that those specific 
builds of tools will now and forever produce modules which load into 
8.1.x - so we have a LCB8.1 toolchain.

Similarly, when 9 goes GM, the module format, lcb standard library and 
lc-compile will forever produce modules which load into 9.0.x - so we 
have an LCB9.0 toolchain.

If there comes a point where we do perhaps need to break 
source-compatibility, we will make lc-compile more clever - making sure 
it can be passed a 'source version' argument. Or we will reconsider the 
module format slightly, raising its abstraction level slightly so this 
isn't an issue, write a suitable converter and happily move on.

The point is the whole problem can be sufficiently solved quite well 
with better tooling (which we are aware we need to work on); and in the 
future can be solved completely using a little bit of cleverness and 
exploiting the way LCB has been implemented.

> I have to say I'm surprised that we're still at this state of things
> so far after the fanfare introduction of extensions.

It is important to remember that LCB has only been in development (on 
and off) for about 2 1/2 years at this point. Rust has taken over 7 to 
get to source-compatibiliy stage (IIRC), and Swift broke source 
compatibility at least twice I think since its launch - so I don't think 
we are doing too badly (particularly when you compare the size of 
Mozilla, Apple and us... I'll leave you guys to do the math there).

And on a slightly tongue-in-cheek note: I'm surprised after 26 years, 
the linux world has not solved its binary compatibility problem. Indeed, 
they don't seem to care about it one bit - even though it causes huge 
amounts of wasted effort for any organisation daring to consider 
distributing *binary only* applications. God forbid! (Also, the further 
you move away from glibc in the Linux stack, the worse things get in 
terms of source compatibility too...) ;)

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps