As far as I can recall there is an open promise to turn to implementing the WSH/ActiveX functionality for the new ooRexx interpreters, "sometimes after 4.0 goes GA".
The reasons given back then (why it did not get implemented for the initial 4.0) were that no code from the 3.x line could be used due to internal hacks that were necessary to implement the WSH functionality, in addition to a principal problem of how to deal with script host supplied objects. A couple of months later there was some discussion about how one would want to implement the "implicit variables" into ooRexx in a new implementation. (Windows script hosts would be able to register objects with the script language upfront, i.e. before invoking the script, such that the invoked script has already access to OLE objects that were supplied by their hosts. The same logic, BTW, was used when modelling the Java script host facility, pointing at the MS-WSH implementation.) One possibility would be to have an entry in the environment, e.g. ".host" which serves as a directory for script host supplied objects without forcing these objects into the running script variable pool, which would be necessary to allow backward compatibility with 3.x ooRexx WSH applications. Ad WSH per se: Windows Script Host has been a quite strategic technology from Microsoft defined with their ActiveX interfaces. It allows Windows (script host) programs among other things to embed ooRexx code into HTML text and when the Internet Explorer loads such text, the ooRexx script gets run/invoked by MSIE. Such ooRexx script could do whatever JavaScript or on Windows VBS or all of the numerous Active* script languages (like ActivePerl, etc.) allow for. Also, in the past (with the WSH support available in 3.*) ooRexx Microsoft's ASPs (Active Server Pages) could be created with ooRexx code embedded rather than JS or VBS, something that ooRexx programmers used as well, judging from the questions, requests that pop up from time to time in various places. And one of the most important features (besides WSF, Windows Script File, an XML container of scripts that carry out jobs, with inter-script/language interaction) is doubtlessly WSC, the Windows Script Component. WSC allows for creating COM classes fully implemented in ooRexx. Such ooRexx-COM-classes could then be used by any programming language using the Windows COM infrastructure, in this case OLE. I know of applications that take advantage of ooRexx-WSC classes (which also means that those applications will remain restricted to ooRexx .3.x). In my current classes, introducing students to OO programming, I have been using ooRexx 3.2 to this day, because on Windows platforms the WSH support is available for ooRexx, hoping/expecting that eventually the ooRexx 4.x line will make WSH available as well. It would be *very* disappointing, if WSH/ActiveX support was not implemented for the Windows world, which would be obviously the case, if you tag WSH-bugs as "outdated" and argument with the 3.x hacks that make it impossible to carry over the code to the 4.0 line (which has always been clear, hence the expectation/hope that a new WSH/ActiveX implementation will eventually see the light of sun on ooRexx 4.x). --- The follow-on class is using Java as a huge ooRexx function/class library uses ooRexx 4.0.1. BSF4ooRexx, which enables camouflaging Java as ooRexx (and sending Java objects ooRexx messages!) is not (yet) realized as a JSR-223 implementation as long as host variables/objects and how to incorporate them systematically into ooRexx has not been decided upon and implemented by the developers. As mentioned above the JSR-223 group "learned" from the WSH/ActiveX framework the nifty ability to push host objects into the script space, which makes creating scripts that interact with the host a breeze! Or put into other words: to not tackle WSH/ActiveX does not solve the principal problem of how to deal with script hosts trying to push their objects into the scripts they invoke, such that the scripts can immediately access/interact with these objects. It is a general problem that would need a general solution (the earlier, the better). ---rony On 11.08.2010 17:27, Mark Miesfeld wrote: > All, > > As you may have noticed, I've recently been trying to clean up the > tracker bugs a little bit. > > I'm planning on closing the WSH bugs as out of date. > > No matter what, the old WSH code is not going to be used in the > future. It used undocumented, (unsafe ?) APIs that no longer exist, > and won't be re-instated. Therefore any bugs in that code are simply > not applicable any more. The bugs themselves of course remain in the > data base should someone ever want to take a look at them. They just > won't be active, open, bugs. > > I'll close them tonight unless some one objects. I would have done it > already, but it seemed a little bit of a unilateral action, so I > thought I'd get some consensus first. > > -- > Mark Miesfeld ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
