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