use UnicodeProperty rather than UnicodeMap in NormalizationDataIUP?

[markusicu]

Robin pointed out in #1391 where I was deleting the unused PropNormalizationData that in some ways it looked more modern than the remaining NormalizationDataIUP because it was using constructs with UnicodeProperty like

unicodetools/unicodetools/src/main/java/org/unicode/props/PropNormalizationData.java

Line 25 in 06feb7f

UnicodeProperty canonicalProp = properties.getProperty("ccc");

rather than ones with UnicodeMap like

unicodetools/unicodetools/src/main/java/org/unicode/props/NormalizationDataIUP.java

Line 45 in 06feb7f

ccc = factory.loadInt(UcdProperty.Canonical_Combining_Class);

We should discuss which one is preferred.
Discussion 2026may12: Prefer APIs with UnicodeProperty. See comment below.

Note also that one uses a property name string and the other one uses a UcdProperty enum value.

@eggrobin @macchiati

[macchiati]

There are plusses and minuses. The enum interface is typesafe (and more compact, and comparisons of values are faster), where UnicodeProperty lacks that. On the other hand, UnicodeProperty is more uniform across properties (even tho the API is somewhat clunky). I've thought about fixing the internals of UnicodeProperty so that the internal values could be enums, etc. so that we'd have the best of both worlds, but never had the time to do that. So I think the group could go either way.

…

On Fri, May 8, 2026 at 10:16 AM Markus Scherer ***@***.***> wrote: *markusicu* created an issue (unicode-org/unicodetools#1393) <#1393> Robin pointed out in #1391 <#1391> where I was deleting the unused PropNormalizationData <https://github.com/unicode-org/unicodetools/blob/06feb7fd69965470ecf835e11ddb8783aa4f3ad9/unicodetools/src/main/java/org/unicode/props/PropNormalizationData.java> that in some ways it looked more modern than the remaining NormalizationDataIUP because it was using constructs with UnicodeProperty like https://github.com/unicode-org/unicodetools/blob/06feb7fd69965470ecf835e11ddb8783aa4f3ad9/unicodetools/src/main/java/org/unicode/props/PropNormalizationData.java#L25 rather than ones with UnicodeMap like https://github.com/unicode-org/unicodetools/blob/06feb7fd69965470ecf835e11ddb8783aa4f3ad9/unicodetools/src/main/java/org/unicode/props/NormalizationDataIUP.java#L45 We should discuss which one is preferred. Note also that one uses a property name string and the other one uses a UcdProperty enum value. @eggrobin <https://github.com/eggrobin> @macchiati <https://github.com/macchiati> — Reply to this email directly, view it on GitHub <#1393>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMCAWV3ZUUEZOZSPOQT4ZYI6JAVCNFSM6AAAAACYWJ3ZQWVHI2DSMVQWIX3LMV43ASLTON2WKOZUGQYDQMJRGY4TIMA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[eggrobin]

Related: #716.

UnicodeMap may be useful in the implementation (though it has its performance problems), but it does not handle defaults, and so cannot really be the actual API for most properties (attempting to populate <code point> in all UnicodeMaps that have this default will not end well). Knowing that this was an insoluble problem, I immediately proceeded to make it worse in #699, where UnicodeMap in the JSPs have a dummy string when the value is unchanged from some base version.

UnicodeProperty abstracts that away. In addition, it handles multivalued properties, and I added to it some abstractions to deal with those (getValues vs. getValue, etc.). I think the general direction has to be away from UnicodeMap and towards UnicodeProperty.

I agree with Mark that we should make UnicodeProperty type-safe (perhaps with some generic subclasses? Or maybe make it an interface with generic subclasses, so that the enumerated properties can benefit from more efficient data structures?).

[macchiati]

Btw, some of the problems with Unicode map performance are caused by the goal to be compact in memory. For example, it is optimized for building sequentially (code point order). When lots of semi random changes are made (like merging in another umap), it gets ugly. It would be better to not modify in place, but rather build a new one from inputs. There are a few other areas where I think relatively limited changes would make a significant difference.

…

On Fri, May 8, 2026, 21:01 Robin Leroy ***@***.***> wrote: *eggrobin* left a comment (unicode-org/unicodetools#1393) <#1393 (comment)> Related: #716 <#716>. UnicodeMap may be useful as an in the implementation (though it has its performance problems), but it does not handle defaults, and so cannot really be the actual API for most properties (attempting to populate <code point> in all UnicodeMaps that have this default will not end well). Knowing that this was an insoluble problem, I immediately proceeded to make it worse in #699 <#699>, where UnicodeMap in the JSPs have a dummy string when the value is unchanged from some base version. UnicodeProperty abstracts that away. In addition, it handles multivalued properties, and I added to it some abstractions to deal with those ( getValues vs. getValue, etc.). I think the general direction has to be away from UnicodeMap and towards UnicodeProperty. I agree with Mark that we should make UnicodeProperty type-safe (perhaps with some generic subclasses? Or maybe make it an interface with generic subclasses, so that the enumerated properties can benefit from more efficient data structures?). — Reply to this email directly, view it on GitHub <#1393 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMFWMFSAYRTXVLZHT2T4Z2UQ7AVCNFSM6AAAAACYWJ3ZQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJRGM2TQNBXGE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[markusicu]

I am sure that we can optimize many things, but I agree with Robin that creating and using an API that exposes functionality rather than data structures lets us refactor and improve more easily.

For example, and maybe this is already the case, a property API instance for a binary property could internally store a UnicodeSet rather than a UnicodeMap, and once the property is loaded, could freeze it for speed.

Our next “Unicode Tools & JSPs” meeting is this coming Tuesday. We could discuss this there.

[macchiati]

I'll try to make that

…

On Sat, May 9, 2026, 09:51 Markus Scherer ***@***.***> wrote: *markusicu* left a comment (unicode-org/unicodetools#1393) <#1393 (comment)> I am sure that we can optimize many things, but I agree with Robin that creating and using an API that exposes functionality rather than data structures lets us refactor and improve more easily. For example, and maybe this is already the case, a property API instance for a binary property could internally store a UnicodeSet rather than a UnicodeMap, and once the property is loaded, could freeze it for speed. Our next “Unicode Tools & JSPs” meeting is this coming Tuesday. We could discuss this there. — Reply to this email directly, view it on GitHub <#1393 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMC7BSB3VRXEXQQVLI34Z5OZ5AVCNFSM6AAAAACYWJ3ZQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJTGA2DANRRGM> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[markusicu]

Discussion:

• Mark: go with UnicodeProperty; it has issues, but fixable
• Robin: would like UnicodeProperty to turn into an interface; try to move from String values to enums, boolean, ...
• Robin: ToolUnicodeProperties (v2) want to go away, but that's where most of our derivation code lives; need to move derivation code elsewhere
• Robin: We have code that attempts to do versioned derivations, but that's not tested and generally doesn't work as it should -- need to get away from that