Talk:Forth Lesson 21
Unintegrated, re my gobject project:
(09:05:21 PM) cscott-olpc: from my brief read of neon, i'm pretty sure that's not how i was going to implement the gobject bindings; i was going to use vocabularies as in http://wiki.laptop.org/go/Forth_Lesson_21 (09:06:16 PM) MitchBradley_: OFW device nodes are implemented as a pair of vocabularies, one for the properties and one for the methods (09:07:40 PM) MitchBradley_: which is why you see device names when you say "order" after e.g. "dev /wlan" (09:09:36 PM) MitchBradley_: Hmm, I guess I pretty much already said that in lesson 21 (09:10:40 PM) cscott-olpc: would it make sense to make gobject bindings part of the device tree to reuse that machinery? (09:11:11 PM) MitchBradley_: I couldn't say without looking at gobject in more detail. (09:12:27 PM) MitchBradley_: My best guess is that it's probably best to just use the vocabulary mechanism directly. The device tree machinery probably has enough specialized elaborations to get in the way. (09:12:29 PM) cscott-olpc: i've lost a lot of state, but the key transform is taking a c-method like gtk_window_open(GtkWindow *window, ...) and wrapping the GtkWindow struct such that you can say something like window.open() in your target language (09:13:35 PM) cscott-olpc: 'window open' in forth might work if 'window' pushed an appropriate vocabulary on the stack (09:13:43 PM) MitchBradley_: The multiple-code-field stuff that is in the Forth layer underneath OFW might be more appropriate. (09:14:58 PM) MitchBradley_: basically the way that works is that you define a set of operator functions that apply to a data structure, then define a word to make an instance of that data structure. (09:15:54 PM) MitchBradley_: the instance is named, and you chose the operaition with "operator-name instance-name". (09:16:09 PM) MitchBradley_: E.g. "to foo" (09:16:23 PM) MitchBradley_: where "to" is the operator name. (09:16:38 PM) MitchBradley_: there is also a postfix way to invoke it.
CScott 02:18, 9 February 2013 (UTC)
