Why should I accept this kind of strange development method
other than the Object Oriented method ?
Application systems using Process Oriented Interface (POI) are much more easier to learn and to use. And it's more flexible. I believe this method is a useful supplement to Object Oriented. At least it is a useful tool to integrate different languages. You do not need to learn JNI and ATL any more. And you can do much more with POI and Regular Statement String in fact. I think it is like Service Oriented Architecture (SOA) in a sense.
Everyone know substance is composed of particles. But in another aspect, substance is composed of wave. So only OO is not enough, you can find my detailed explanation in RSS documents.
Many people told me that they do like to write programs in this style.
I think you confuse the conception of an interface and an object in OO design. An object is an instance of a class, but an interface is only a abstract profile of a class or real object. Developers won't have to know the whole complicated class, they can only know a special interface to do something. So it should not be too difficult if they use OO.
Yes, an OO interface is easier than a complex class. We usually face
OO interfaces, not OO implementation classes. But the OO interface is not as expressive
as POI. And it's not flexible. One time if you want to upgrade an OO interface,
you have to write a new interface to inherit the old one. If 100 developers do
that or you want to upgrade the interface for 100 times, you will get too many
interfaces. With POI, what you
have to do is to add new keys and values.
Your Actions seems good, but I think the methods of an OO interface can do the same work.
I don't think so. Sometimes POI and RSS is better for following 4 reasons:
What's the weakness of Regular Statement String?
Why not provide a pure Java based RSS ?
You know Microsoft invent a lot of calling conventions, such as "__cdecl",
"__stdcall", "__fastcall", and so on. I think RSS is more like a new style
calling convention. So performance is most important. It's very easy to
migrate RSS to any Java compliant platforms.
This library seems to me like a combination of hash management and the rudiments of a state machine. It has become fashionable to create your own "programming paradigm", but it would be nice if those who do so would come up with more than just a new way of stringing together old libraries. This model, for example can easily be followed to the logical conclusion of being an expert system. While that model of programming may have fallen out of favor, I think it would be good for the author to look over languages such as CLIPS and Prolog and systems such as make before continuing with a half-way effort at re-implementing some of their features.
From outside view, my project is likely a combination of special enhanced hash management and a simple state machine. However it is really capable of building an easy-to-use and language-neutral interface in only one step.
I would not want to invent new languages or new types as Prolog and CLIPS do. My purpose is to find a way to develop "simplest" libraries with simple interfaces for independent systems. One junior developer may learn that interface from the corresponding manual within a few minutes. And he (she) does not need to know the whole picture of the component models of the system architecture.
This method is as easy as ANSI C, but more expressive, more flexible,
and no naming conflict problem.
You do realize that you "reinvented" so-called "named parameters", right? These are available (or at least easily simulated) in quite some programming languages (Ada, Lisp, Perl, Python ...). Reasons why not to use them everywhere: * loss of type checking by the compiler; * usually slower than positional parameters. In your case: * way too verbose syntax; * way slower execution; * compiler cannot do some optimizations, cannot dispatch on these parameters for overloaded functions, etc.
"Named parameters" is only one feature of Regular Statement String. Regular Statement String is a quite different method from OO. For example, I will not care about objects when I write Regular Statement String client applications. I only care about states of RSS interface. For example, I use an RSS "Action" named "open" to open a room; I don't consider there is a room object related with current instance. I only consider that now there's a more room ID that I can use in the RSS application. All resource management is by RSS server program.
The other issue is performance. I know this kind of development method may be slower, but not always slower. There are 2 targets for a developer to choose an API. One target is to use the API to build up a high speed service system. (For example, he wants to build a HTTP server with SOCKS API.) The other target is to use the API to do a few particular job in an independent system. (For example, he wants to search something in a GIS.) The latter is suitable for RSS because the developer only need to tell RSS server what he want. The RSS server program or library will find a best and maybe fastest way to do the job.
The other strongpoint of RSS is expressiveness, language neutral, and
encapsulation. The RSS server program may be upgraded or even change to
another independent system. (For example, the user chooses another GIS.) The
user do
not need to change anything of the client program because RSS client application
development is only related with the RSS API manual and decoupled with
the implementation.
What will be your focus of development of "Regular Statement String" ?
I hope at least I could do the following two interesting things with Regular Statement String in the future: