mixing dialects? Encapsulation. Carl?
[1/1] 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-