Hello the list, I have nearly finished the ELF version of the new Objective-C ABI. It is able to pass the same tests that the previous one did in -base, with a smaller binary and better reflection metadata. The last piece left is whether to improve NSConstantString.
The new ABI includes some breaking changes, so will require a complete recompile. This gives us an opportunity to improve constant strings. I think we have three options: 1) Use the existing NSConstantString structure. 2) Simply adopt CFConstantString. 3) Do something new. I don’t think 1 is a very good idea. -base includes some horribly hacks to go and replace NSConstantString instances with NSString instances on initialisation because NSConstantString -hash requires that it be computed dynamically. Option 2 would simplify some Apple interoperability. It allows UTF-8 and UTF-16 strings (is this useful? Anyone in CJK locales want it?) but doesn’t really help with the hash issue. Option 3 would be to implement a structure something like: { id isa; const char *str; // UTF8 or UTF16 string NSUInteger hash; NSUInteger flags; } The flags would store, at a minimum: - Whether this is UTF-8 or UTF-16. - What hash algorithm the compiler used. If -base later decides to use a different hash algorithm, the implementation of -hash can then check the flags and if the compiler-provided hash is not the version being used, it can lazily set the hash ivar to something different. Another alternative is to set isa to different things for UTF8 and UTF16, so we can just provide NSUTF8ConstantString and NSUTF16ConstantString as subclasses of NSConstantString. Does anyone have any strong opinions in either direction? David _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev