Bonjour Jean Louis,

not sure what the "best way" would be, but having read the feedback so far, 
here a few thoughts:

 * 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! :)

HTH

---rony



On 07.06.2026 18:37, Jean Louis Faucher wrote:
The interpreter has direct access to utf8proc if needed, so the type of wrapper 
has no impact.

What is the best way to provide access to utf8proc from a script?
Some of the methods are REXX methods, mainly for the constants.
The remaining methods are native (20 methods).

a)
Native class UTF8Proc with class methods only.
No instances, enforced by New and Copy.
UTF8Proc.cls is included in rexx.img.
It works, but there is no similar implementation among the predefined classes.

b)
Native class UTF8Proc with instance methods.
Singleton, similar to RexxInfo.
UTF8Proc.cls is included in rexx.img.

c)
Not a native class, but a library with native methods, similar to File or 
Stream.
Singleton.
UTF8Proc.cls is included in rexx.img.

d)
Same as (c), but not included in rexx.img.
UTF8Proc.cls is located in trunk/extensions/Unicode and must be loaded by the 
user.


Illustration of the current implementation (option a):

StartClassDefinition(UTF8Proc)

AddClassMethod("New"                        , UTF8ProcClass::newRexx, A_COUNT);
AddClassMethod("Version"                    , UTF8ProcClass::version, 0);
AddClassMethod("GraphemeBreak"              , UTF8ProcClass::graphemeBreak, 1);
AddClassMethod("CodepointCategory"          , UTF8ProcClass::codepointCategory, 
1);
...

CompleteClassMethodDefinitions();

AddMethod("Copy"                            , UTF8ProcClass::copyRexx, 0);

CompleteMethodDefinitions();

CompleteClassDefinition(UTF8Proc);

EndClassDefinition(UTF8Proc);




UTF8Proc.cls
...
-- Values returned by .UTF8Proc~CodepointCategory(codepoint)
::constant CATEGORY_CN  0 /**< Other, not assigned */
::constant CATEGORY_LU  1 /**< Letter, uppercase */
::constant CATEGORY_LL  2 /**< Letter, lowercase */
::constant CATEGORY_LT  3 /**< Letter, titlecase */
::constant CATEGORY_LM  4 /**< Letter, modifier */
...
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to