Page 1 of 1
Designing LCB libraries with open language in mind
Posted: Sat Jun 06, 2015 4:42 pm
by trevordevore
I'm experimenting with LCB libraries that act as an interface for faceless objects. (I'm assuming that when open language arrives that it will be built on top of LCB. Is that correct?) I'm converting LCS scripts that did this before. Eventually I will want to have an open language interface for these libraries. I'm working on the getters/setters for the object properties. In LCS I just had one command for setting and one function for getting:
Code: Select all
function objectGet pObjectId, pProperty
end objectGet
command objectSet pObjectId, pProperty, pValue
end objectSet
@LCMark - I'm wondering if you know enough about how open language will be designed yet to comment on what the best approach would for what I'm doing? Will it matter if I use one get/set handler in LCB or define a different handler for each property? I want to eventually be able to write things like this:
Code: Select all
set the <property> of myObject <id> to "some value"
Will this even be possible with libraries or would we need a different interface similar to widgets but without any UI?
Re: Designing LCB libraries with open language in mind
Posted: Thu Jun 11, 2015 7:09 pm
by PaulDaMacMan
I too am interested in knowing more about the future of LCB & OpenLanguage. I'm interested in wrapping some existing foreign code libraries / frameworks / APIs for use with LiveCode (specifically FluidSynth and/or Core MIDI). I've heard that LCB already supports foreign language libraries if they're written in C (and later will support C++, JAVA, etc.). I've read that CoreMIDI is actually written in C (as opposed to Apple's other frameworks - ObjC) and I have some sample code for CLI-Apps written in C that make calls and receive call-backs to/from Core MIDI.
In short, I would love to see an example of wrapping some foreign code lib written in C but there doesn't seem to be any info about it yet.
T.I.A. to anyone who can shed some light.
Re: Designing LCB libraries with open language in mind
Posted: Thu Jun 11, 2015 8:09 pm
by trevordevore
PaulDaMacMan wrote:In short, I would love to see an example of wrapping some foreign code lib written in C but there doesn't seem to be any info about it yet.
T.I.A. to anyone who can shed some light.
@PaulDaMacMan This is a different topic then what my post is about. Can you start a new thread so we don't get any responses mixed up?
Re: Designing LCB libraries with open language in mind
Posted: Thu Jun 11, 2015 11:54 pm
by PaulDaMacMan
trevordevore wrote:PaulDaMacMan wrote:In short, I would love to see an example of wrapping some foreign code lib written in C but there doesn't seem to be any info about it yet.
T.I.A. to anyone who can shed some light.
@PaulDaMacMan This is a different topic then what my post is about. Can you start a new thread so we don't get any responses mixed up?
You are designing libraries for faceless objects (GUI-less?) written in LCB for future use with Open Language and want some clarification.
I want to create wrapper(s) for pre-existing libraries for GUI-less objects with LCB for future use with Open Language and want some clarification.
Basically I'm looking for this kind of info as well:
I'm wondering if you know enough about how open language will be designed yet to comment on what the best approach
So it seemed appropriate for a thread titled "Designing LCB libraries with open language in mind", but sure I could start another thread, maybe I'm misunderstanding what you're talking about.
Re: Designing LCB libraries with open language in mind
Posted: Fri Jun 12, 2015 12:22 am
by trevordevore
I was referring to the part where you said that in short you wanted examples of wrapping foreign code in C. That seems like a different thread topic to me.
Re: Designing LCB libraries with open language in mind
Posted: Thu Jun 18, 2015 5:24 pm
by trevordevore
I've been looking at some of the .mlc files in the LC distribution. I think I can pose a more concrete question now. Based on the code I've looked at it appears that each property has a separate function. For example, <the antialias of Canvas> has the following syntax definition:
Code: Select all
syntax CanvasPropertyAntialias is prefix operator with precedence 4
"the" "antialias" "of" <mCanvas: Expression>
begin
MCCanvasGetAntialias(mCanvas, output)
MCCanvasSetAntialias(input, mCanvas)
end syntax
The only syntax I found as I glanced over the dictionary that used a variable for property names was the script object. For example, <get property Property of Object> has the following syntax definition:
Code: Select all
syntax GetPropertyOfScriptObject is statement
"get" "property" <Property: Expression> "of" <Object: Expression>
begin
MCEngineExecGetPropertyOfScriptObject(Property, Object)
end syntax
Based on this I'm guessing that unless I want to prefix all of my syntax with a keyword like <property> (once Open Language becomes generally available) then I should define a handler for each property that I want to set. Is that accurate?
Re: Designing LCB libraries with open language in mind
Posted: Mon Jun 22, 2015 10:21 am
by LCMark
@trevordevore: At the moment syntax for properties in LCB is defined by having separate handlers for setting / getting each property - we will be making this a bit less 'low-level' at some point though by adding a 'property syntax' clause (much like property clauses in widgets) and at that point we could probably give the choice between whether to call a dispatch function (taking the property name), or individual functions. However, I think that separate getters / setters should be preferred as we've found them easier to maintain in the engine (since the 7 refactor).