Portable Objective-C framework & runtime • https://objfw.nil.im • https://github.com/ObjFW/ObjFW
clearly they haven't done an API review before release
I'm starting to think I should just keep calling it OF_STRING_ENCODING_UTF8 and say "deal with it Cocoa boys, your favorite framework is inconsistent as heck, adapt to ObjFW's consistency"
having enum variants (OF_FOO_BAR) look different than classes (OFFooBar) seems fine to me
maybe you have an idea jn 🙂
so:
thisIsAStaticLocalFunction()
thisIsAStaticLocalFunction()
of_but_global_function_look_like_this
the of prefix is really annoying here
hence maybe OFGlobalFunctionLookLikeThis?
which is what Cocoa does
but at that point the questions becomes why should enums be all uppercase when that works poorly with swift
ugh, I hate it
I'm leaning towards just changing the style and not giving anything about how Cocoa names stuff, given how inconsistent they are
maybe you could make a little overview page of the different constraints and influences?
Cocoa would call it NSISOLatin9StringEncoding, if it had it at all.
(GNUstep does call it that way)
/**
* @brief The encoding of a string.
*/
typedef enum OFStringEncoding {
/*
* UTF-8 *has* to be 0, so that if the current @ref OFLocale is `nil`,
* `[OFLocale encoding]` returns UTF-8.
*/
/** UTF-8 */
OFStringEncodingUTF8 = 0,
/** ASCII */
OFStringEncodingASCII,
/** ISO 8859-1 */
OFStringEncodingISO8859_1,
/** ISO 8859-2 */
OFStringEncodingISO8859_2,
/** ISO 8859-3 */
OFStringEncodingISO8859_3,
/** ISO 8859-15 */
OFStringEncodingISO8859_15,
/** Windows-1251 */
OFStringEncodingWindows1251,
/** Windows-1252 */
OFStringEncodingWindows1252,
/** Codepage 437 */
OFStringEncodingCodepage437,
/** Codepage 850 */
OFStringEncodingCodepage850,
/** Codepage 858 */
OFStringEncodingCodepage858,
/** Mac OS Roman */
OFStringEncodingMacRoman,
/** KOI8-R */
OFStringEncodingKOI8R,
/** KOI8-U */
OFStringEncodingKOI8U,
/** Try to automatically detect the encoding */
OFStringEncodingAutodetect = 0xFF
} OFStringEncoding;
Maybe this isn't all terrible?
or, rather, naming consistency is hard
maybe I should just say "public functions use a different convention to align with C style, deal with it"?
FOO_BAR style gives visual separation between enum variants and classes; but i don't know if that's good or bad
maybe indeed best to keep everything as is. Letterus WDYT?
hmm, would of_thisIsAnExportedFunction be so bad?
maybe that is what I should use
to solve the entire inconsistency between local and public
just don‘t make anything uppercase and underscore that is going to be part of a class instance (methods and properties)
2 replies
oh, and write down the rules somewhere so libs can comply to it as well 😉
[ObjFW] New ticket [32a54a363f4903ec|32a54a363f] Support for hardware SHA on x86. (link (https://objfw.nil.im/info/680e0607fa1399940d92023892bd94d57a0955555f9431155f5fb081285e7276))
yesterday I tried about 2h to get any UI done using Glade and I‘m beginning to understand why elementary recommends doing UI by code. While Gorm of GNUstep really represents the intuitive simplicity of Cocoa/IB, you can‘t say the same about Glade. If gobject was influenced by objc they missed the crucial parts about UI it seems 😅
I take into account I may not yet have been able to understand how it works correctly by now. So digging deeper now...
1 reply
js: Gnome Builder creates projects utilizing Meson build system. Will I be able to integrate ObjFW with Meson or should I use your build system and link against glib et al?
https://blog.gtk.org/2021/03/30/gtk-4-2-0/ Portability
Seems it’s going the way of go and Rust, and hating packagers. Sad to see.
1 reply