Rename glib/ErrorG to Error?

Actually module glib/GKeyFile.d is oddly named. Inside it has a class KeyFile? which is not consistant with the naming convention used throughout gtkD. Module name should be KeyFile? to be the same as the class name it contains.

From the looks of this, these departures from consistancy are sporadic throughout the gtkD modules. We should clean up these class and module names, I think.

I guess one potential problem with renaming GError to Error is a conflict with phobos' Error? I'm not certain. Perhaps this is why it was named this way.

GError -> ErrorG -> Error is inconsistent with GObject -> ObjectG. It's likely this was a deliberate decision to avoid potential collisions with other symbols (Phobos' Error and Glib's own GObject). I do think it looks awkward, so probably a change could be implemented in some way (consistently) across gtkD. I think I actually saw some code in the wrapper to put that 'G' at the end automatically. Might have been an illusion, though, the wrapper can be a strange place.

Yes, Object and Error are both D objects... so that likely was the problem. And GObject and GError are gtk+ structs. At the very least, I hope we can find a better solution than ObjectG and ErrorG.

Replying to Pse:

I think I actually saw some code in the wrapper to put that 'G' at the end automatically. Might have been an illusion, though, the wrapper can be a strange place.

GtkDClass.d line 830 But only for Object.

The G seems to be added to all classes that would conflict with others, for consistency you could add the G to all glib classes. Might not be the best option tough.

I was actually looking for a consistant way to remove the G from the end. :)

Option #1:

Use DObject and DError, etc (the same for all other similar instances in GtkD).

Advantages: easy solution to implement; no name clashes.

Drawback: Unfortunately, this fix really doesn't look very gtk+ related, but ObjectG and ErrorG were a little over-the-top too.

---

Option #2:

Use GObject and GError directly for class/module names. You may ask "How? Doesn't this conflict with gtk+ structs of the same name?" I think we can work around this by renaming the structs in the gtk+ imports (see gtkc/glibtypes for GError) with a prepended or postpended "_" like so: struct _GError { ... } .

In the C interface, I don't think that the name is really critical for the function definitions in D imports, so much as having a struct size that matches... For some opaque types all that matters is a meaningful name for the C function declarations. Most opaque types can be passed as a void* to the C function anyway (This is not necessarily the case with GError; although GObject is defined as an empty struct in gktc which might as well be an opaque type because none of it's members are accessible or defined in the C interface). Incidentally, in the original C gobject header, GObject is actually a typedef for a struct _GObject type. So the C GObject is merely a convenience name for _GObject, making the use of this solution more valid.

Advantages: Perfect fit for GtkD; Fixes the naming concerns and prevents name clashes.

Disadvantages: The provided gtk+ names and types will have changed slightly, and those developers that want to use gtkc directly will have to use the _G* versions instead or manually rename them with a D "alias". As long as this is well documented, I think this is okay... but some may find this "just plain wrong" if they feel symbols like GObject and GError should be accessible exactly as they appear in the C gtk+ headers.

---

What do you think? Shoot these ideas down, if you need to. :)

I don't think option 2 is possible. I believe symbols from gtkc need to be resolved at link time, so their names must match those from GTK+.

Replying to Pse:

I don't think option 2 is possible. I believe symbols from gtkc need to be resolved at link time, so their names must match those from GTK+.

As far as i've seen only the functions get linked at runtime, So option 2 should be possible.

I don't really like option 1 with the Prefixed D's, option 2 seems better only GError** isn't wrapped in most places, so you end up with a lot of functions that accept a _GError**.

I've not gone through the loader, but are you sure about this Mike? Are functions exported with nothing more than void pointers?

Yep, functions are just exported as void pointers and loaded at runtime. So yeah, option 2 should be possible, my mistake.

Replying to Mike Wey:

As far as i've seen only the functions get linked at runtime, So option 2 should be possible.

I don't really like option 1 with the Prefixed D's, option 2 seems better only GError** isn't wrapped in most places, so you end up with a lot of functions that accept a _GError**.

Agreed about option 1.

Option 2 does have the drawback that _GError would appear all over the place in gtkd class code. That is, gtkd classes are not using ErrorG; instead they are using gtk+ GError directly. As long as _GError is hidden from the GtkD user, this isn't much of a problem... but if class methods are still taking GError* as a argument (or returning the struct pointer) then this really means GtkD has not wrapped gtk error functionality... and this gets ugly.

Therefore, option 2 is really not a solution until GError gets completely wrapped and ErrorG (the current class name) is used throughout gtkd. This could be a bigger undertaking than I thought. While I like the idea, it may not be a practicle one at this point.

I want to point out though, that it's a shame when a good name like GError is taken when the underlying wrapped object is using the a name that we could be using for a classes. So, at least, it's good to know we have this option.

I think this should probably be pushed back to release 1.0 or at least somewhere in between pre-release 8 and 1.0.

Agreed. Making it version 1.0 is fine.

Is this really something we want to leave as something to change for the release? Seems to me that this should be changed for RC1 (which was not a milestone when pushed to release 1.0). Thoughts?

I don't like the idea of breaking changes after in an RC.

Let me add a third option the the 2 discussed above: Prefix All the GtkD classes with an G and use the postfix option for the structs.

Mike's idea sounds good to me.

After starting to rename ErrorG to GError for the classes, I started to wonder if this (Mike's idea) is really what we want to do. I think we should review our options sometime this weekend, for both this and other tickets.

For the record, I kinda like leaving it GError for the lower level referencing, and setting DError for referencing on the D wrapper level. This would be nice to do across the board, but that's just what I like. :)

After a lengthy discussion with JJR last night, we came to the conclusion that this really doesn't need to be changed, and we can just close the ticket. If that is fine with everyone else, I'll close this prior to RC1. If anyone wants to see the conversation and how we came to this conclusion, feel free to ask and I will send it to you.

Replying to okibi:

After a lengthy discussion with JJR last night, we came to the conclusion that this really doesn't need to be changed, and we can just close the ticket. If that is fine with everyone else, I'll close this prior to RC1.

It's fine with me.

Replying to okibi:

If anyone wants to see the conversation and how we came to this conclusion, feel free to ask and I will send it to you.

It's always nice to see how the decision was made.