valueDiff for arrays?

[Mark Waddingham]

On 2018-08-04 04:00, Brian Milby via use-livecode wrote:
> Other than the fact that coding is fun :)

Yes - but coding in LCS is much more fun, quicker (for me, anyway - and 
I've been writing C/C++ for nigh-on 30 years) - more importantly it is 
also MUCH MUCH more secure.

Additionally, it is also the *one* language that everyone on this list 
understands and comprehends. and more secure than in C++

In general coding things in C++ in the engine should be strictly 
reserved for things where it is *absolutely* required - and in this 
case, I don't see an absolute requirement in this case (yet!).

This would be fundamental operations, and the interconnection with 
things where doing it in LCS or LCB is not feasible or cannot produce 
the fidelity required to do it.

All array operations in LiveCode (union, intersect etc.) can all be 
written precisely (as in replicating exact functionality of the engine) 
in LCS. Indeed, I'm pretty sure there are comments lurking around either 
in tests, or in the engine source which show the LCS equivalent. In this 
case, the C++ implementation is merely a 'hand-coded' to-C++ compilation 
of the an LCS handler for all intents and purposes (and I'm not even 
sure there is much performance advantage to it being so - perhaps an 
interesting project to determine, for those that are interested in such 
things!).

My suggestion here would be *first* write an LCS handler which does what 
you want. Then rewrite it, trying to distill it down so it does a single 
orthogonal operation (it might be what you actually want is a 
composition of two or more). Get a 'perfect' LCS implementation written 
which uses the engine's various 'internal' features (names, 
copy-on-write) etc. to make sure it is as efficient as it can be 
(centered around the use of lists / arrays - i.e. actual individual 
values - rather than string-lists).

This will give rise to a name of the operation, or fundamental 
operations it is composed of; the name(s) of which will lead to 
potential syntax for it/them... For example, there is zero semantic 
(i.e. runtime effect) difference between:

   arrayUnion @xArray, pOtherArray

and

   union xArray with pOtherArray

The difference is purely in our brains language-processing centers - the 
abstract operation is the same.

As I've always said in the past, english-like syntax is like sugar (when 
used as a condiment) - it makes many things easier to ingest (there are 
many things which many people would not even think about wanting to 
eat/drink without it), but is something you add after something exists, 
not before it does.

On a related note, I get the feeling I might have irked Mr Wieder the 
other day with regards the android permission thing - that wasn't my 
intent - but it is a similar situation. Android and iOS permissions are 
actually really quite different - yes they have the same user-level 
effect - but internally iOS's are essentially limited and hard-coded, 
Android's are not. If we had 'raced' to implement a uniform 'mobile' 
abstraction form for them - then it would have most likely have been 
wrong or at the very least very limited. Instead, we now have a simple 
set of Android handlers (3 IIRC) which mean that an LC application can 
utilise the full power (and it is quite extensive!) of the Android 
permissions usage APIs - as if you were writing in Java (but a little 
bit easier to grok!).

The 'mobileRequestPermission' handler which would be nice - can be done 
in an LCS library - where it is easy to change / evolve and get right. 
Indeed, people can write their own variants should they have the need 
and then feed back if they want to.

If we had raced straight to C++ this wouldn't have been the case. You 
all would have been stuck with what the people who poke around in the 
engine had come up with and their understanding of that particular part 
of the Android elephant and any future changes to them would have been 
glacial.

Warmest Regards,

Mark.

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