Add .self property to all classes that are children of gtk.widget.Widget

[dejlek]

One of the frustrating things about D is that it does not (yet) allow initialisation in the with statement, so we have to do

Window win = new Window();
with (win) {
  setTitle("Example");
  setDefaultSize(200, 200);
  setChild(mainBox);
}
// Do something with the Window

What we can't do in D, that would be ideal is: with (Window win = new Window) {

However, what we can do, and what I propose here is to generate a property called self for all classes that are children of gtk.widget.Widget. self just returns this.

With this, our code from above becomes:

auto application = Application("com.example.gid.Application);
with (new Window()) {
  setTitle("Example");
  setDefaultSize(200, 200);
  setChild(mainBox);
  
  // Do something with the Window, using .self
  application.addWindow(self);  // self being a property of Window!
}

I would actually go even further and add this to gidgen as an instruction:

//!genself gtk.widget.Widget

Of course, assuming this is doable. Question for @elementgreen is - is this doable?

[dejlek]

Someone on IRC suggested:

if (auto win = new Window) with(win) {
  setTitle("Example");
}

frankly I would rather live with what I currently do: auto win = new Window; with (win) {}

[elementgreen]

I see what you are trying to do, but in the case of auto win = new Window; with (win) {} can't you just refer to the window as win? Having a self property seems like a weird hack to me. One thing I noticed with the Rust Gtk API, is that it allows for chaining of setters, by returning this. That could potentially be an option as well for removing the need to continually refer to an instance. I'm still on the fence on whether I would like it or not, but it could look something like this:

application.addWindow((new Window).setTitle("Example").setDfeaultSize(200, 200).setChild(mainBox));

[dejlek]

I want to avoid the auto win = new Window; line before with (win) {} statement. Fluent APIs like you described are invented because languages do not have the with statement. - That is why you will see fluent APIs a lot in the Java world.

D unfortunately does not (yet) give means to get reference to the object in the with statement...

The IDEAL solution ofcourse would be if D could give us reference to the object itself. So the following works:

auto application = Application("com.example.gid.Application);
with (new Window()) {
  setTitle("Example");
  setDefaultSize(200, 200);
  setChild(mainBox);
  
  application.addWindow(withReference);  // withReference is a Window reference. D does not have this unfortunately.
}

[elementgreen]

Thinking about things more.. It doesn't seem all that big of deal to add a self property to objects in gidgen. One thing I'm currently working on is restructuring the object hierarchy. I'm thinking of adding a base Wrap object which would be a base type used by Boxed and potentially also ObjectG. It would provide some basic methods for getting/setting the C instance, duplicating it, and freeing it. For ObjectG the latter would be just ref/unref calls. I'm working on simplifying the gidgen logic by having template primitives which can be used for all of the transformations between D and C of the various data types, which will vastly simplify the gidgen binding generation logic.

In the meantime, I could just add the self property pretty easily.

[elementgreen]

Just pushed support for this to gidgen and gid.

I'm considering only generating packages on master on each release. The reason is because even just minor changes at this point result in rather large change sets. What do you think? It would just require that the packages are rebuilt after pulling gidgen and/or gid.

[dejlek]

AMAZING! It was easier than I thought!! :)

With regards to generating packages - it certainly makes sense. If people need package updates, they should do it themselves.

Maybe we should actually remove packages directory from repo, and generate them only during the release process?

[elementgreen]

The release process is just a tag, so the packages need to be there in master in order to be used by dub. They could only get updated just before tagging though. Just means anyone using master needs to know that they have to generate the packages with gidgen before using them or they will be out of date. That is usually always the case for me. This would help tremendously to cut down on the size of the change set, especially as more packages are added. I'm concerned the repository is going to become bloated very quickly.

[dejlek]

Gotcha. Makes sense. Does this mean that we do not push changes in the packages in our PRs, right? Just changes in the def files, docs, etc?

[elementgreen]

👍 Correct.

[dejlek]

AMAZING! It was easier than I thought!