On Wed, 10 Sep 2003, Martin Stecher wrote:
Though I have a little problem with the example in Figure 10:
"toDialect" is a term that is very specific for the selected
service. Does this example assume that "toDialect" is a supported
term of standard P or how could a service dynamically add new
identifiers and functions calls?
You have asked a very important question. P "as is" supports only a
few "terms" or objects methods -- those defined in Core and Services
modules. Everything else is provided by other modules that are,
essentially, extensions. When P interpreter finds an expression like
<object-of-some-other-module>.<method-name>() it passes the name of
the method to that other module/object to handle. P Core does not know
a priory whether the other object supports that method, but there is
an interface that allows modules to report unsupported errors back to
Core.
The above scheme allows P modules like Http or Smtp to evolve without
affecting P Core. I believe it can be implemented efficiently.
The same trick can probably be applied to services. Any service will
be implemented as an internal program or some kind of callout service
(via OCP, SOAP, or whatever). For OCP, we will document how to map
service.method-name(params) call to something that OCP callout service
can understand. This trick will allow services to evolve without
affecting P Core. If we find it is too much overhead/complexity to
support this marshaling, we will restrict services to a few
well-known and general-enough methods.
Hope this clarifies,
Alex.