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) ? >> 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]> > 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]> 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]> > 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] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
