okay, new rule ((apologies to Bill Maher)): it’s okay to install a GObject property like this:
pspec = g_param_spec_string ("title", "Title", "The title of the item", NULL, G_PARAM_READWRITE); g_object_class_install_property (gobject_class, PROP_TITLE, pspec);
instead of the usual way you see in other GObject-based libraries, where we l33t h4x0rs dispense from the use of an explicit GParamSpec variable. this is especially true if you are trapped in 1983 and are still using an ANSI 80×25 terminal — though you should probably know that here, in 2008, 100+ columns are safe.
oh, and fill out the name and blurb fields of the property: GObject provides a little bit of introspection, but if you willfully ignore it then we can just forget about stuff like the GObject-Introspection project.
please, every time you install a property using a line like this:
g_object_class_install_property (
gobject_class, PROP_TITLE,
g_param_spec_string ("title", NULL, NULL, NULL,
G_PARAM_READABLE | G_PARAM_WRITABLE));
an unfortunate incident will involve a bucket of puppies and a belt sander.
comments saying “gobject sucks you should be using ${ZEALOTS_OWN}” will be deleted without mercy because they miss the point by a hundred and fortyseven miles
Surely the fact we are coding in C means we are indeed stuck in 1983 though.
@mallum: I’ll bite — it depends on what you’re writing. the ugly fact is that poor little else is available for writing libraries.
Damn, I’m responsible for quite a few puppies meeting their maker…
yay decemberists!
yay +1 for that. I’ve been doing in that way where I can anyway because the other way upsets Emacs’ auto-indent
-1 for saying that 100+ columns are ok though. If I have a wider a screen then I want two side-by-side 80 column windows. And long lines mess up patches in emails
@neil: I respect the fact that some prefer 80 columns — even though I’m not sold on both the window size (use a tiling window manager) or patches in email (fix your email client :-P).
what I personally find most irritating are the contorsionisms people use to get around the fact that libraries are not using function names like creat() or foo() like it was in 1972. you want to break down the lines? fine. but use a variable or two — or, god forbid, a wrapper inline function. don’t do weird shit like breaking down at parentesis or commas until you cannot distinguish between parameters, functions, macros or ternary operators anymore.
but I really think it’s time to bite the bullet, if you’re writing C code, and code for non ANSI terminals.
Here in 2008 many people uses text-based editors like vim or emacs (well – at least me) opened in 80×24 terminals.
puppies and belt sander! GENIUS! ABSOLUTE GENIUS!
/me creased over in a laughing fit!
@Uzytkownik: here’s a nickel kid, go buy yourself a better terminal emulator.
+1 for 80 columns. Because it’s standard, and it’s useful in many situations. Have you heard of printing code, for example? And myself, since I moved from xfwm4 to wmii, I haven’t been able to go back from using a two-column view with a terminal (or two stacked terminals) in the left column and a gvim session in the right column. 80 chars max indeed, I say!