To Rev or not to Rev + OOP TAOO tech

[MisterX]

> [x'ed]
>  You are free to define "words" 
> that implement an OO environment if you choose.  You could 
> even create Rev using this as the lower level "P code", or an 
> operating system for that matter.
> 
> Dennis

I like your way of saying it... 

That's exactly what I've done with xtalk in TAOO, XOS, ObjX, 
the Referencer stacks,... all these years!

As Richard said, Object based... Do i need polymorphism? Nope,
i can handle it myself much better! Do i need inheritance? I
can force it anytime, anyway i want. Do I need object structures?
I got cards with the most complex and visual structures you 
could ever ask for from a textual IDE! 

If you really want to dwelve into OOPs, there's a huge field
of CS advanced books on the matter from language design to
process architecture to compiler stuff, etc... I tried it
all and none, really, none was the bible except maybe all in
part. You name the language, i checked it out. Even scriptX.

Great stuff, but can it be faster for development?

In the real world, you have to process objects for clients. 

FileMaker is the best for most business purposes - all in one.
The hell, the finder/Explorer + any text editor will do too! 

It's a matter of seeing the "objects"... Filemaker will make
the sums and reports while in the hell you do it yourself!

Realistically, RunRev, can do it without any intervention in
the best cases. Filemaker will cough, cough... OK, Applescripts
can help. But it's not a totally Filemaker only thing then...

Single points of failures are to be minimized!
And RunRev can do it all... 
But does it scale up? Not unless you have a real strategy or
optimum "fixed" object structure/code... That's always true
and that's when objects are less important...

If speed or graphics were not a problem sometimes, RunRev could
do it all actually... 

But thanks to externals that's quickly bridged between any
low-end or new-to-come APIs of the OS, anything is 
possible! And Chipp is one the best examples here I might add.

Was it done it OPP? Does it matter? In the end, it's it does it
business on it's objects the right way. Can I access it's 
objects? Can I modify them? :) Objects...

90% thinking, 10% scripting - that's how I see it!
Remember that 90% thinking = 1/1000 the 10% scripting in time!

So now im coming to the conclusion of the TAOO environment and
got a really really sweet set of tools. The OOP in it is like 
you said: a question of wording... After you get the hang of 
the wording (nothing hard!), and your libraries work with it, 
you'll see that things start to work by themselves! Usually 
with just a one-liner ;)

So if you are interested in an object called TAOO with a frame-
work of objects in objects without any need of fancy object.obj
notation... Let me know, i got it down to a science/slang now ;)

We all know there's always a trade off ;)

No joke. What can it do for you? Choose a [meaninful] verb...
It will find the object and function for it. It's programming
language/ide/file format independent too and anything you add to it becomes
part of the whole! So you see, after 15 years (or more) it's been gathering
quite a lot of skills... And any GUI is possible in terms of objects...

More importantly, and in relation to "a picture is worth a 1000 words",
visual objects in TAOO have a wording to them that makes them "aware"
(Jean-Claude Van Dam style ;)... That's the key to making the system work
not just as a oop-library but also as a "live" visual oop environment. 

So the Visual Object language is another place where I've put in a lot of
"evolution" - which someone mistook for "bug-fixing". I did and got a lots
more in return than expected and each version is less bugs all across the
TAOO script-nation! The language works with the controls via all types of
front/back or stackinuse scripts depending on the "object" layers. 

Now running on both Rev and MC too including all N2O tools ;)

The event Hierarchy is managed both locally and globally. The hierarchical
layers are like objects in objects. Or templates in objects, and vice versa.
There's no limits that I know of others than IDE over-loading. It works for
my new GM (called GIM - Graphical Interface Manager). There's always an
easier solution when it comes down to that like object-layer masters
(frontscript or backscript), managers(backscript or stackinuse), agents
(palette or stackinuse), etc.... 

For example, take a TAOO object "contact" which is just a group with a bunch
fields as Contact databases contain. It could be data from a file, db, sql,
or in cards, it doesn't matter. This Contact object, can be copy-pasted into
any other stack's object background and add "contact" features to the said
application! That's the relativism and relationalism of objects in the Art
of Objects - there isn't any - it's all there is!

I've released a part of it in a secret place of MonsieurX
Those interested... You know what to do.

And it's proudly made in RunRev! ;)

Cheers
Xavier
--
http://MonsieurX.com/TAOO