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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
