Comments on: Next stage. Dialects vs functions. Graphics API... more.
The next stage of the host kit are the graphics-related interfaces -- those implemented as the draw, richtext, and effect dialects.
Because these sources are to be part of the host kit, they need to be isolated in the same way that we isolate extension functions. Therefore, they need to be implemented similar to extensions. This was, in fact, part of the plan while building the extension architecture.
In order to make this work, the command! datatype requires extensions for optional-args-by-datatype. So, it turns out, this greatly parallels the action of delect.
Therefore, in the name of simplification, I don't want both. So, delect will be modified to work with command! blocks, and commands will be improved to provide similar capabilities.
I should mention that the motivation for this change comes from more than just this specific situation related to graphics. It's a bit of an admission that for many interfaces, functional forms are adequate - full grammars are not required in such cases.
The roots of this theory and discussion go far back in REBOL history to private debates comparing Rugby (RPC-like) and REBOL/Services (dialect based). Although dialects are generally more powerful, the simple and regular form of functions has benefits too.
Some of this "discovery" comes through what I've learned in implementing many distributed system architectures. This includes not just R/S, but IOS, AltME, DevBase, and RebDev (Chat).
During the refactoring stages of RebDev Chat, its communication grammars collapsed into a functional form, with just a few small additions (optional args, repeated args, default values, and binding of the functions into context.) It occurred to me that these features were nearly identical to what dialects like draw were implementing via delect. In fact, if you probe system/dialects/draw you'll see the dialect grammar is nearly functional.
So, in conclusion, it's best not to support both. Adding more power to the command! datatype for better support of extensions will obsolete the the object format used by delect. It's best to bite the bullet now and make the change rather than let it extend past this alpha test stage.
More info soon. I really hope this can be done quickly, and we can move into full support for graphics development and porting it to other systems like OS X, X11, etc.
This is also the method to be used with REBOL/Services 3.0.
Sounds like making Extensions even more flexible? If so, then I am first to applaud it :-)|
Interesting comparison on Rugby and R/S, and yes, I agree with you.
my question regarding RItch text is:
Is it better to have a better set of low level functions in draw and a valid font / draw text relation which will lead us obviously to make our own custom ritch text widgets.
Or is it wiser to have a black box widget doing ritch text in an imposed way using borring things like caret-to-offset for text motion/selection.
Plus you will have 3 buffers :
* first buffer the raw document from file
* second buffer the Makedoc version of the document
* third buffer the internal draw representation of the
Is that the proper way to handle the task?
I observe a clear pattern with xRatio's posts. He doesn't understand and then criticize:
- Lots of datatypes
- Code = data
- Contexts and bindings
There's a clear pattern here. Clear as day. I won't tell what it is, because he wouldn't understand it, but I know everyone else would.
Guys, what are we doing wrong in explaining things? :-)
Post a Comment:
You can post a comment here. Keep it on-topic.