On 2015-10-24 23:25, Richard Gaskin wrote:
I've worked with OS APIs in Pascal, C, and two xTalks, Tookbook's OpenTalk scripting language which provides that built-in, and CompileIt for HyperTalk.
This is true - they did. However, they come from a time when almost all OS APIs were procedural, and quite simple.
(Also, due to the limitations of what one can represent in 'stringy' languages - of which LiveCode Script is one - such a facility is incredibly fiddly, error prone and difficult to build nice abstractions around).
The one thing I've learned from that is that the language you're using isn't all that important, because no matter what you're writing in the OS you're talking to expects C: it uses C data types and structures, provides tons of great sample source but all in C, and requires that you think like a C programmer, understanding and managing data in ways a good xTalk normally insulates from even having to think about - the difference between a pointer and a handle isn't interesting to most xTalkers, but can be essential in C.
This isn't true. Most of Android's APIs are Java. Most of iOS / Mac's APIs are Objective-C. A lot of Windows functionality is provided through COM - which is an object-based API. Oh, and in the browser (HTML5) world the APIs are JavaScript (another object-based language).
By the time you become fluent enough in C to understand OS APIs well enough to use them, you've already learned enough to write in it as well.
This is simply not the case - there's a huge chasm between being able to understand C-style APIs and data-structures enough to use them and being able to write C (at least to any degree of use / proficiency).
Indeed, given that we are talking about (in many cases) very well defined APIs, which have been (ignoring Win32 and MacClassic ;)) very well designed - you actually don't need to understand much C to use them.
All you need to understand is what the values they take and return are, and how they can be appropriately marshalled. Indeed, the goal is that LiveCode Builder will do most of the marshalling for you - so as long as you have enough of an understanding to read the API definitions and map them to LCB forms, you can then use a language which is a great deal more familiar to use them (to be fair we still have a fair bit more work to do on the marshalling front...).
Monte's done an amazing job showing off what the externals SDK can do for extending LC. It would be great to see more people jump on board with it.
Externals don't really go away with LCB - they just get renamed. All that happens is that LCIDLC which is used to simplify the interface between Engine and External goes away and is replaced by an LCB file containing nothing but foreign handler declarations. Of course, you then get the benefit of being able to mix you LCB and C in any way you choose.
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
