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] > <mailto:[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] >>>> <mailto:[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]> >>>> <mailto:[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]> >>>> <mailto:[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]> >>>> <mailto:[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 list >>> [email protected] >>> <mailto:[email protected]> >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> -- >> Gil Barmwater >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> <mailto:[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
