Struct vs. Class

brad · Posted: Sun Mar 28, 2004 2:34 pm Post subject: Struct vs. Class

Steve Roy and I have been talking about what to do about some of the SWT classes for Unicode and such. I'll give an example:

For LogFonts, there are three files in org.eclipse.swt.internal.win32:
LOGFONT.java
LOGFONTA.java
LOGFONTW.java

Each of them are basically acting like structs, but are separate classes (A and W inherit from the top one and add size to the struct).

Andy Friesen did some work and made:

dwt.internal.win32.logfont.d - with 3 structs inside.

Our question is, to keep up with what will inevitably be updates to SWT, should we have three different files, all classes, that inherit? Just to remain somewhat in sync with Java, even though D has the struct capability?

Thoughts?
_________________
I really like the vest!

Guest · Posted: Sun Mar 28, 2004 2:59 pm Post subject: Re: Struct vs. Class

BenHinkle · Joined: 27 Mar 2004 Posts: 76

brad · Posted: Sun Mar 28, 2004 3:47 pm Post subject:

Both SWT and DWT talk natively. I think this specific example of LOGFONT is a higher-level abstraction because another platform needed it. These are just structs that we're discussing, and the native calls are elsewhere. (maybe I mis-interpreted you Ben)

The dwt.internal.xxx modules (xxx= win32 or gtk) are where the native calls are found. org.eclipse.swt.internal.xxx is also where the JNI calls are found, so you can tell that Java was going native as well, wherever possible. That is the main reason I want to see a port of SWT. Ben just recapped them nicely.

Subversion has a web interface, albeit limited. See the code I'm talking about in a browser here:
http://svn.dsource.org/svn/projects/dwt/src/dwt/internal/win32/os.d

Look towards the bottom and I think you'll see your native interface calls.
_________________
I really like the vest!

evetsyor · Joined: 27 Mar 2004 Posts: 12

SWT is a combination of classes and a native API wrapper written in C. for the D port we dont need the wrapper, we can call the native one directly.

So the port itself is more a port of the classes. which is what the SWT is really a classes framework.

- Steve

JJR · Joined: 22 Feb 2004 Posts: 1104

Steve has the idea.

The purpose of porting SWT to D was to take advantage of a class design. It saves a lot of work. Also most of the native interface to separate OSes are already developed and easily translated to D calls. This simplifies the work of porting it to multiple platforms.

Unfortunately there are some issues. After examining the java code and doing some conversion, I have to disagree with the "Guest" above. Tracking the SWT closely may be very hard to do. I predict that DWT will have to become it's own library separate from SWT once it reaches satisfactory functionality. There is too much unnecessary baggage from Java SWT that would be best dropped from the D port. That and the fact that we may augment the event system to support D delegates too. You just have to look at the code to see that their are a lot of things that we shouldn't need in D. SWT, therefore, lends mostly to a structural base on which to improve an independent D GUI interface.

Thus, my opinion is that we should NOT track SWT too closely. It may make for an even more complicated project.

Opinions? I may be the only one that believes this way....shoot me down if I'm out of order. I just think heavy modifications will be necessary to make things smooth and palatable to D programmers and trying to integrate SWT updates concurrently will be messy.

Later,

John

kris · Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific

JJR · Joined: 22 Feb 2004 Posts: 1104

Oops... (Guest == Kris)

I see your perspective. I mistakenly got the context wrong.

Ant · Joined: 06 Mar 2004 Posts: 306 Location: Canada

evetsyor · Joined: 27 Mar 2004 Posts: 12

I personaly prefer the use of struct. but in the current state of the project, i think its better idea to leave thing that can work as is. and change only thing that cant.

Traceability is very important unless we plan to have a team of 40 man to keep the code up-to-date and working, when it stop working everytime a os change (aka Redhat habit). when IBM have a huge team already fixing it in the java SWT. that we just have to port the fix after. imho

- Steve

JJR · Joined: 22 Feb 2004 Posts: 1104

After looking at the logfont code, I guess I have to agree with Steve and Kris. Better to leave it as is for now for consistancy. We can "pretty" things up (or fowl it up) later once things are actually working properly. This is much the same as we've been doing with most of the other SWT features anyway. We've basically been adopting what works in D whether it's preferable or not (String, SWT_error, etc.).

It's kind of ugly to have to "inherit" things like logfont(a,w) from the SWT code but... oh well.

andy · Joined: 15 Mar 2004 Posts: 71

evetsyor · Joined: 27 Mar 2004 Posts: 12

In those case:

LOGFONT.java
LOGFONTA.java
LOGFONTW.java

We should use struct, cuz those struct are passed to Win32 API, java version use class then thru the wrapper .c files are sorta converted. in D we will use the API directly.

Actuly those struct should come from std.c.windows.* and not supply them in dwt.

- Steve