Major new features in smartfrog top-of-trunk

Hi,

I have just checked in a new set of features that should significantly
improve the usability of SmartFrog, hopefully without breaking backward
compatability too much if at all. The documentation will follow in the
next few days, but in the mean time here is an overview of the changes.

All the changes are to do with links, functions and the way they react
when some of the links are LAZY. 

1) LINK Propagation: 

Up until now, if a link was LAZY it was treated as a LINK value and
other links refering to them simply resolved to these link values.
However this elads to confusion in the use of the language and lack of
abstraction in the use of templates. This had two consequencea. Either
links would be copied and then users would resolve them in the wrong
context or users would have to retro-annotate links to lazy links to
indicate that they were LAZY. Both of these lead to usability issues.
Consequently, the language now specifies that all links to LAZY links
are also to be considered as LAZY - LAZY propagates backwards through
the links. In the few cases that a link value was really required, there
is a new keyword (DATA) that can be applied to a link to indicate that
this is not to be considered as a link for resolution, but a piece of
data in the same way as an integer or string. Note that DATA does not
propagate, but a link to a DATA link simply copies the DATA link. At run
time, resolving the attribute returns the DATA link.

An earlier email from me described this (as a proposal which generated
no dissenting voices) in more detail.



2) LAZY functions:

The more significant change is that ALL functions also react to
propagated LAZY'ness. If one of the attributes used in the resolution of
the function is LAZY, the function is tagged as LAZY and will be
evaluated at run-time when the attribute value is required. This does
away with the need for components such as LazyConcat which will be
deprecated as a result.

Functions are still defined in the same way, so any user-defined
functions will be largely handled as before and will automatically
inherit the LAZY propagation capability. (Minor changes to enable
compilation may be required as a previously necessary interface is no
longer required - but in most cases this will not have been declared
explicitly, but through extension of BaseFunction which no longer does
so.)

The internal changes to enable this are significant! Firstly all
function applications are now references - a new class of reference
called an APPLY reference. These are then evaluated during link
resolution phase (as opposed to the original function phase). There is
new syntax for this reference, but visibility of this will largely be
restricted to error messages and the like. A replacement function phase,
now preceding the link resolution phase, builds the reference objects
from the original component description form or the operator syntax
supported in the .sf language.

So for example, the following would have been illegal in the original
language is now perfectly OK and behaves as expected:


Service extends Prim {
    sfClass "...";
    port 80;
    secondPort (port + 1);
    thirdPort (secondPort + 1);
}

sfConfig extends Compound {
    myService extends Service {
        port LAZY IPROPERTY myPortNumber;
    }
}

Note that a similar treatment of assertions and schemas will be
developed over the coming weeks...

Note also, that with such a deep change - although all our tests pass
(99% without modification) - there is bound to be a degree of
instability. Also, some error messages are (even) less good than before.
We will be working on them...

Feel free to post questions and comments,

Patrick


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642