[REBOL] mixing dialects? Encapsulation. Carl?
From: petr::krenzelok::trz::cz at: 24-Sep-2000 7:06
Hi,
so, Allen moved the "discussion" to ally list, but noone answered there.
However - I would like to ask once again :-)
As you surely know, we have dialecting capabilities in REBOL, based upon
parse-block capability. It's very cool, really (although some improvements
to parse wouldn't hurt :-). But - have anyone thought about larger-extent
project? Once looking under the hood, at sources, one can see even Carl has
little problems with dialects versatility from time to time (expressed by
various commented lines in sources of scripts ....).
Carl, you are building /Express, part of which is, if I am not wrong,
product called /Author, so I would like to hear some comment here, if you
will find a little bit of free time to respond ...
I remember one interview some few years ago, where Carl expressed his idea
about REBOL, and compared it to CPU industry. You always use the smallest
bits of technology, and by combining them, you get new product. Noone gets
the whole CPU, molds 100 of them inside and makes new CPU. While we can see
this aproach in REBOL, and it's very good, sometimes questions like
encapsulation
arise in my mind.
We've got VID dialect and its really nice. We have various styles available,
with plug-ins for feelings (you can choose from system/view/vid/vid-feel).
Let's call them gadgets. But - sometimes, there really is need of
higher-level stuff, components, let's call them widgets(?). OK, we now have
few by default (various request funcs). The question is - should they be
opened to be touched from outside world? Should certain changes in the
outside world influence them? Shouldn't they just expose some part of its
inteface? Huh, talking upcoming modules here? :-)
And now my main question - aren't such controls (widgets) internally domains
specific issues worth of own dialect? Let's take menu for e.g.
We can build it from vid-styles and vid-feels, but at the end, it will start
to be complex, and it shouldn't be ... When we are building menu for e.g.,
we think in terms of menu, not this face here, this overthere, etc. So:
main "File" #"F"
"Print-setup" #"P"
"Something" #"o" sub "ble"
sub "Ble"
etc stuff ...
Hmm, we can build menu specific (domain of usage specific) dialect here.
But - are we left with using raw faces here? Is there an asy way to use VID
too? Hmm, or just during parse we should build VID representation of it?
But, how to plug it inside of existing layout? e.g.
view main: layout [
menu 0x0 200x20 [menu dialect here]
]
How should we learn layout to know about 'menu?
btw: VID system structure is starting to be a little bit messy
=== system/view/VID ===
0 > PARENT
1 > verbose false
2 > warn false
3 > vid-colors
4 > vid-face
5 > vid-words [at space pad across below origin guide return tab
...
6 > vid-styles
7 > track func [blk][if verbose [print blk]]
8 > error func [msg spot][print [msg either series? :spot [m
...
9 > warning func [blk][print blk]
10 > facet-words
11 > fw-with
12 > fw-feel
13 > spot none
14 > image-cache []
15 > expand-specs
16 > grow-facets
17 > do-facets
18 > next-tab
19 > choice-face
20 > vid-feel
21 > set-edge
22 > icon-image
23 > radio.bmp
24 > radio-on.bmp
25 > req-funcs
26 > parse-url
27 > req-file
99 > EXIT
from above we can see something more complex is not solved - we have
categories for styles, feelings, words etc belonging to VID itself, but
there is not upper category for more complex stuff like discussed above, and
controls like request-date, etc are subpart of VID, placed in 25, while e.g.
req-file object structure is inside VID level itself (27). What about
encapsulation? my-reqeust-file: inherit(make, copy)
system/view/widgets/request-file etc. stuff?
Thanks for your time spent reading this message :-)
-pekr-