Been away from code for quite a long time, hence trying to readjust.
Skimming over Jean Louis' GitHub presence is now very funny (it starts with a Rexx related cartoon),
but (as in the past) also *very* helpful, as it has the links to his projects. All projects have a
_diary.txt that explains the work done for each commit of the project, but also explains concepts,
options, and thoughts, *extremely instructive*.
In the context of Unicode, it may be interesting for developers to check out
<https://github.com/jlfaucher/icu4oorexx> and look through the implementations. The explanations and
comments in the _diary.txt and code files are very helpful, IMHO.
Also, <https://github.com/jlfaucher/builder> may be worth checking out, as it allows one to easily
create ooRexx and Regina for different platforms in a unified, simple manner.
And lastly, if you peek around, you may find funny and interesting cartoons featuring Rexx, ooRexx,
NetRexx, CRexx...
The information and knowledge available are very impressive, and so is the service for downloading
the current ooRexx 5.3.0 version with the (at this point) experimental implementation of Unicode for
ooRexx: that is the link that Jean Louis has provided below
(https://github.com/jlfaucher/executor5-bulk/releases). After reading the page, click the "Assets"
dropdown at the bottom, and you'll see links to portable versions for Windows and macOS. This way,
you merely need to download, de-quarantine, and unzip the files, run "setup" and are able to test
the version by prepending "rxenv rexx" to the ooRexx programs you want to test.
This is very simple, easy, and therefore very productive!
If you just want to check out the current version of Unicode support for ooRexx 5.3beta, get and run
the portable binary package for your operating system.
---rony
On 15.06.2026 21:53, Jean Louis Faucher wrote:
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]>
<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
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]>
<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]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
