IS REBOL object oriented?

Chris

AFAIK yes. well, i have an IOS-evaluation-account, and start reading. IOS is like an everywhere mirrored file-system. messages are done by changing a file, telling ios its changed. on the other side tell ios to watch a file, reread on change. then ios mirrors. if the other side is offline, it gets the file next time when connecting. thats enough to do Reblets for instant messengers. with log. for edited normal files the dektop-icon turns red when changed locally. one has to re-publish after changes by hand when thinking "finished". theres a version-control for undo too. for collaboration partners talk like "hmm, ok, i change it" - "ok, uploaded" with the messenger and can see the same file a moment later. files are files, so they are easily with external tools. like listing all files which are changed locally. of course scripts can run on the server too, for coordination. but while each user can script its client, server-scripts need admin.rights.

hmm. rebol and oops.. marketing needs short descriptions sometimes :) IMHO, well, yes, oops works pretty well in rebol. so well, one seldom sees it. think of a script itself as the main-class. the pre-written objects are well choosen and well reusable. most of the time one does not need to define big extra classes. also, there are dialects. they are more the rebol-way. conventional oops declares related objects with methods. and tells you how to use them. Container, addListener, Event, .. rebol uses a compiler-compiler. "parse". its great. writing a special language can be done in some lines. they create and connect objects for you. and can always include/move real rebol. for key featureare dialects like "layout" view layout[title "helloworld" button "quit" [alert "bye" quit] ] like scripting a gui-builder. returns a very complex object. the rebol-code [alert "bye" quit] is plugged somewhere deep in the appropriate place. view it with "view". press the button. writing dialects is comparable in size to the oops declarations. using them much simpler. but access to the metal (screen-faces) if needed. parse itself is inbuild, but the usage is like a dialect. a little language. parsers are short because they parse rebol-blocks. these are pre-parsed source. simple stuff is already identified and put in an object. like %my-file or dates, 127.0.0.1, http://somewhere or [me--my-server--org] . so the basic syntax of the parser is inbuild. and standardized. every little language understands them. including rebol-code, which can be seen (and handled) as a dialect. a pretty complex one, compared to the others. nearly as complex as programming-languages ;) this basic syntax is used too to store data. similar to xml. which you write to a file. telling ios its changed. somewhere someone will listen. sooner or later. :)

greetings -volker

best design and programming paradigm. :) A dialecting approach is much easier after all. Andrew Martin Speaking in many Rebolios tongues... ICQ: 26227169 http://valley.150m.com/

Sure. foo: make object! [ . . . ] That'll create an object. It works much like an object in a "real" OO language -- it can have data members, methods, etc. The big thing it misses compared to, say, C++ is you can't overload operators; it also only features single inheritance, but that's not so uncommon.

AFAIK, yes, using /Pro or /Command, you can run arbitrary "native" programs from REBOL, either from a script or the console. With /Core or /View, no, you cannot.

===overloading if one codes like /view does, it works. that means implement vtables by hand (easy), and call the super-method by name. like (pseudocode) my-class: make super-class[ vtable: make vtable[ a-nice-tool: func[self arg1 arg2][ super-class/a-nice-tool self arg1 arg2 my-stuff self/var1 .. ] ] var1: var2: none ] my-object: make my-class[init-stuff] my-object/vtable/a-nice-tool my-object ;pass self by hand looks a bit ugly, but there are some kinds of semantic sugar possible. mostly becuase it hides quick in dialects :) ===multiple inheritance proto1: context[a1: b1: none] proto2: context[a2: b2: none] my-object: make make proto1 proto2 [my-var: none] probe my-object make object! [ a1: none b1: none a2: none b2: none my-var: none ]

-volker

no, i do netcologne.. ;)

Right, and you can use other tricks to do it indirectly, too, I'm sure, but not as directly as the operator/function overloading in, say, C++.

Huh. Never thought of that. Nifty-cool, though.

this is no trick, its a pattern ;) c++ methods are hardwired. one can overload them, yes. but not redefine them dynamic. so use one class for data and another class with the method and switch the reference. modern frameworks use a handmade "vtable", exactly this way. like squeak/smalltalk with morph/player, java with one-method/no data listener classes, c++ with, well i forgot it. overloading is deprecated in ComponentPascal (heavy skilled unknown framework-builders), they choose the [ super-class/a-nice-tool self arg1 arg2 ] style. so why should rebol implement a more and more deprecated feature? ;)

I wasn't saying it should, just that it might be a difference that someone whose expectations were formed by C++.