RE: OO and scripting

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

HI Paul.

<Long post....>

this is an interesting view.

It seems that now an object (code + data) is transmitted with two documents:
a) the data
b) the interpretation script.
the former being the XML document, the latter the style script. The former
the data, the latter do something on the data (transform it into something
that could be rendered)

In fact more and more I look at the actual architecture and more and more I
think that a lot of internet technologies are based on the interpreter
pattern (gamma & al.)

I am actually working on XScript and during this work,  I found that in most
style languages or SGML/XML manipulation languages. Most of them are pattern
match language (dsssl, xsl, CSS, omnimark, Balise) or event driven
languages. (Some implementation like for instance CSS could be more like
filling a style struct for each element, but it can be seen or implemented
as an event driven language)

Pattern match language have an interesting characteristic. On one side you
have a tool that either build a tree or trigger an event for each element.
On the other side, a procedure or rule attached to this element. For C/C++
programmers (or in most procedural languages) this looks like a big switch
or case construct. There is, in fact, a certain analogy between XML/SGML
transformation/style languages and GUI frameworks. GUI frameworks are event
driven too.

I did a funny experiment. I created a COM and a CORBA object (the former
created with ILU). This object exposes functions. Or in the component world,
this object is an event sink or implement an event interface. Thus, this
object reacts to the world. Usually, in the component world, this world is a
mouse movement, a button click, a key pressed. Millions of developers
implements such objects that react to GUI events. So, these COM and CORBA
objects (event sink) when hooked to a parser (event source) can process
events and these events are elements encountered in the XML document. For
example the C++ object created with a IDL is like:

interface MyStyle
{
	On_News()
	On_News_Today()
	On_News_Today_Header()
}

This event handler reacts to the following XML document (of course
simplified for this text):

<News>
   <Today>
	<Header>OO is dead, Hurray for the interpreters</Header>
   </Today>
</News>

Of course, these objects where compiled and would be hardly transmitted over
the web without security concerns. However, for server side transform it is
vvvvery ffffffast.

So on one side, you have the parser (event source) that trigger event or
call event handlers. An event is triggered by an element.


The point here is that, it seems that we all got the same approach (event
driven or pattern match or rule driven). This is very different from other
patterns. For instance the model, view, control pattern do not put the data
or model as an event generator. In this case the data is transformed by the
controls and show its state in the view. SGML and XML processing languages
brought a pattern where the data triggers event. The data is then the event
source. An element is an event source and a style or transformation language
rule or procedure is an event sink. The pattern could be simplified by
saying that the document is scanned for elements and each element triggers
an event. The associated event handler do what has to be done with the
event. Most of the transformation languages also provide a way to query the
original document transformed into an internal model like a GROVE or a DOM.

I seems that we have different approaches in this document centric world:
a) procedural event handler or block languages like Omnimark, Balise and
XScript
b) lisp based like DSSSL
c) tag based like XSL.
d) description rules based like CSS

but all share the same characteristic:  they react to the document.

What's funny is that none of these languages can create themselves (like C,
C++, python, Java, Perl, etc...) this is because they are event handlers,
they react to the original document like GUI event handlers react to the
user's actions. These languages cannot live without the document like GUI
event handlers cannot live without the GUI. So Alan would find it funny to
see the data as an event generator. In fact, when we think a bit more, this
is the paradigm shift :-)

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list