Change ImageLoader importing

[summer-alice]

This will add a .all for org.eclipse.swt.internal.image, which is then imported by the ImageLoader class.

As I've mentioned in #103 and #104, when attempting to add a new constructor to the Image class (specifically Image(Device, ImageDataProvider), I encountered a cyclic dependency between DPIUtil and JPEGFileFormat.

The main cause was in the FileFormat class which, in DWT, imports the JPEGFileFormat class, whereas SWT doesn't.

SWT uses Class.forName to dynamically create an instance of the file format. I changed DWT to use the same (after implementing the forName method), but -- since FileFormat couldn't import JPEGFileFormat -- DWT couldn't resolve the symbol.

ImageLoader is the only place where SWT imports all from the org.eclipse.swt.internal.image package, so I changed the import here to be the same. This then made everything work (locally).

Edit: (corrected cyclic dependency)
Here is the error that would occur:

object.Error@src/rt/minfo.d(371): Cyclic dependency between module constructors/destructors of org.eclipse.swt.internal.DPIUtil and org.eclipse.swt.internal.image.JPEGFileFormat
org.eclipse.swt.internal.DPIUtil* ->
org.eclipse.swt.graphics.ImageData ->
org.eclipse.swt.graphics.ImageDataLoader ->
org.eclipse.swt.graphics.ImageLoader ->
org.eclipse.swt.internal.image.FileFormat ->
org.eclipse.swt.internal.image.JPEGFileFormat* ->
org.eclipse.swt.internal.image.FileFormat ->
org.eclipse.swt.graphics.ImageData ->
org.eclipse.swt.graphics.Image ->
org.eclipse.swt.internal.DPIUtil*

[jacob-carlborg]

This will add a .all for org.eclipse.swt.internal.image

Thinking out loud: would it be better to add a package module?

I encountered a cyclic dependency between DPIUtil and JPEGFileFormat

Cyclic dependencies are caused by module constructors. I had a quick glance at the module constructor in JPEGFileFormat. I looks like the initialization can be done at CTFE instead and remove the module constructor.

[summer-alice]

This will add a .all for org.eclipse.swt.internal.image

Thinking out loud: would it be better to add a package module?

I'd be happy with that. I only chose all was because it's used elsewhere.

I encountered a cyclic dependency between DPIUtil and JPEGFileFormat

[...] I looks like the initialization can be done at CTFE instead and remove the module constructor.

Sorry, not entirely sure what you mean by this. What counts as part of the module constructor?

[jacob-carlborg]

Sorry, not entirely sure what you mean by this. What counts as part of the module constructor?

A module constructor is declared using static this. For example:

dwt/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/internal/image/JPEGFileFormat.d

Line 152 in c811a5e

static this() {

[summer-alice]

Sorry, not entirely sure what you mean by this. What counts as part of the module constructor?

A module constructor is declared using static this. For example:

dwt/org.eclipse.swt.gtk.linux.x86/src/org/eclipse/swt/internal/image/JPEGFileFormat.d

Line 152 in c811a5e

static this() {

Ah, okay. I didn't realise a static this in a class was considered a module constructor.

While I'd be (mostly) fine moving the code out, I thought the general idea was to keep the code as close to Java as possible? The local fix I have does this — the main part being that FileFormat can dynamically create instances of each supported image format, without importing the modules directly.

[jacob-carlborg]

Ah, okay. I didn't realise a static this in a class was considered a module constructor.

There's no semantic difference of placing a static this inside or outside a class, IIRC.

While I'd be (mostly) fine moving the code out, I thought the general idea was to keep the code as close to Java as possible?

Yes, but correctness first. I was thinking this issue was in the correctness category. But, of course, it can be solved in different ways.