Bonjour Jean Louis, I just uploaded version 0.7 of TUTOR. It includes experimental support for your version of Unicode. This is a dual version: it passes all tests under standard ooRexx, and it automatically supports utf8proc and ICU when using your version. There's a new tests/beta/ subdirectory containing a number of tests against Unicode 17 UCD files; all of these pass.
I'm subsuming most of the exposed utf8proc API using the UNICODE(arg,"Property",Propertyname) and UNICODE(arg, functionname) BIF syntax. Support for utf8Transform is minimal: it's next on my to-do list. Josep Maria Missatge de Jean Louis Faucher <[email protected]> del dia dl., 15 de juny 2026 a les 21:54: > I have a first level of Unicode support with ooRexx 5, implemented in a > GitHub clone of the ooRexx SVN. > https://github.com/jlfaucher/executor5-bulk/releases > > Ready for review and tests. > No documentation, but the examples should give a first overview. > > > On 8 Jun 2026, at 20:34, Rick McGuire <[email protected]> wrote: > > I don't really have a problem with a class object that only has class > methods. I actually find it cleaner than trying to have a singleton object > that doesn't actually hold any instance data. However, I am fine with > either approach. > > There is another factor to consider however, and that's the matter of > namespace. Every time another builtin in function or Sysutil function is > added to the language, it introduces an incompatibility that runs the risk > of breaking an existing program. The crowd that screams bloody murder every > time a change introduces an incompatibility ignores that particular fact. > Consider, for example, the recent conversation about line comments. That > change has not affected a real life program in over 30 years that Object > Rexx has existed. Avoiding name conflicts with new functions requires the > names be given over complex names to avoid the conflict, such as > UTF8PROxxx(), o rrxcalcxxx() for an existing example. > > The advantage of using a singleton or a class object, is that the only > namespace collision is the name of the class. Other than that, the methods > can be given useful names without ever causing a conflict. The one > disadvantage to including this in rexx.img other than size is a potential > conflict with the class name. By keeping it in a separate package that must > be loaded using ::REQUIRES, any program that does not use this facility is > isolated from those sorts of naming conflicts. > > Rick > > On Mon, Jun 8, 2026 at 2:07 PM Gilbert Barmwater via Oorexx-devel < > [email protected]> wrote: > >> On 6/8/2026 12:02 PM, Jean Louis Faucher wrote: >> >> Thank you for the feedback! >> >> I wanted to check whether any of these options would be unacceptable for >> ooRexx. >> So far, they all seem acceptable. >> >> For the moment, I will stick with a facade that covers a subset of the >> UTF8Proc functions. >> Most of the time, it is a one-to-one mapping between a method and a >> UTF8Proc function. >> >> >> >> Missatge de Gilbert Barmwater via Oorexx-devel < >> [email protected]> del dia dg., 7 de juny 2026 a les >> 20:12: >> >>> At first glance, I think I prefer option b). >>> >> >> I could change for b), no impact for the user. >> Out of curiousity, is there a reason to avoid a) ? >> >> For me, it is a "philosophy" or "style" issue. RexxRef says >> >> "Classes are like templates; they define the methods and variables that a >> group of similar objects have in common and store them in one place." >> >> I have also heard "classes" described as "factories". Now what we are >> creating is an "object" with a set of methods which is the ONLY member of >> its "group"; there are no other similar objects that share those methods. >> This is the definition of a Singleton AFAIK. So to use a class with class >> methods to implement such an object is a "misuse" IMO. A malicious or >> ignorant user might try to instantiate such a class causing possibly >> difficult problems to diagnose. In any case, I believe a singleton >> instance is the "correct" implementation for such an object. >> >> Gil B. >> >> The downside I see is the added size to the overall interpreter for >>> scripts that don't use Unicode. I believe that impact is not significant >>> enough that we should require specific user actions when one needs Unicode >>> in their script. >>> >> >> +1 >> OK, I'll keep utf8proc.cls included in rexx.img. >> Regarding size, embedding the utf8proc sources added roughly 350 KB to >> the Rexx library (twice that on macOS). >> >> >> >> >> On 7 Jun 2026, at 21:03, Josep Maria Blasco <[email protected]> >> <[email protected]> wrote: >> >> Do we really have to choose? I'd prefer to have a library with native >> methods >> (c), which would allow for procedural-style coding (and could be >> replicated >> by non-oo implementations of ooRexx), *and* (a or b, I don't care much) >> a oo-based implementation. >> >> Like ooSQLite. >> >> So that if one day (say) Regina implemented utf8proc, one could write >> a Rexx script that would be really portable. >> >> >> >> +1 >> OK, it's possible to add a corresponding routine in utf8proc.cls for each >> method of the UTF8Proc class. >> >> >> >> >> On 8 Jun 2026, at 14:33, Rony G. Flatscher <[email protected]> >> <[email protected]> wrote: >> >> >> - >> make the functionality available via a single BIF, maybe named >> Unicode, that uses arguments to indicate which available subfunction is >> desired; the expected default use should allow for leaving out the >> subfunction argument >> >> - Reasoning: the addition of Unicode support is really such an >> incredibly important addition to ooRexx that accessing the Unicode >> functionality via a BIF would be warranted. This would work well (as >> Josep >> Maria mentioned) for non-ooRexx programmers and would even allow it to >> be >> implemented in other Rexx interpreters like Regina. The counterargument >> would be that Rexx and ooRexx have rightfully tried to keep the number >> of >> BIFs as small as possible, which adds considerably to the usability of >> the >> language. The counter-counterargument in this particular case would be >> that >> introducing Unicode support is of paramount importance to ooRexx and >> should >> be made available as easily and directly as possible. >> >> - if making the functionality available via ooRexx classes, then >> my take would be to make them as easy accessible as possible (with the >> least number of messages), i.e., as class methods (that are marked as >> unguarded). It would not matter whether any other ooRexx classes would >> exist that define class methods only, IMHO. Ad Gil's point about size >> increase: in this case it would be probably really negligeable, given that >> even watches nowadays approach to have even GB of memory! :) >> >> >> >> >> >> >> On 8 Jun 2026, at 14:52, Josep Maria Blasco <[email protected]> >> <[email protected]> wrote: >> >> >> I would not call the routine "Unicode", as UTF8Proc is but _one_ of the >> pieces of a possible Unicode implementation. My impression is that, if one >> wants a single routine (which is not a bad idea), maybe we could use the >> RexxUtil package, and add a new SysUTF8Proc routine. >> >> >> >> UTF8Proc is a low-level library, and a facade API provides a pragmatic >> way to expose the UTF8Proc services. >> From this facade, other interfaces can be designed, as proposed by Rony, >> but that is outside the scope of my current work. >> I will clean up the current implementation and push it to executor5-bulk. >> After that, we can experiment with it and refine it. >> >> >> >> >> >> >> _______________________________________________ >> Oorexx-devel mailing >> [email protected]https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> -- >> Gil Barmwater >> >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
