> that supporting inner classes will help a lot, not just for GUIs, but for
> a
> lot of freely reusable Java code.

Gentlemen, could you name library/libraries you want to port? Or make sense to port? Just few examples would be enough. Probably I cannot see something.

There are just no Java GUI libraries which you can port.

I even not sure about SWT port.
EPL (eclipse public license) shall be carefully studied first.
http://www.eclipse.org/legal/epl-v10.html by anyone
willing to use SWT/D port. I really don't know how to solve
all these legal collisions.

What is really make sense -  porting of various in-house
systems by their owners.  But in any case - Java has a foundation
of classes. Without these classes any Java code is almost unusable.
So you will always do some reengineering. I believe that
replacing inners with delegates will be *very* small part of the problem.

Andrew.


"Walter" <newshound@digitalmars.com> wrote in message news:d7ekq0$1iq6$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7ds35$nvf$1@digitaldaemon.com...
>> > Will this D GUI be a part of Phobos or will it only be the "official" D GUI library?
>
> Part of phobos, no. I don't see a gui as a core library. As an addon
> library, like dmdscript is, yes. Several D gui libraries are being worked
> on. Eventually, I hope it will become obvious which one is the 'right'
> one,
> and that one will become more or less official. Of course, nobody will be
> prevented from using any other D gui library, and many will prefer using
> other ones. The point of having a more or less official one is to avoid
> the
> C++ problem of there being no standardized gui library. The point of not
> putting it in Phobos is so that those who wish to use other GUIs can do
> so.
> (I.e. Phobos should avoid being dependent on a particular GUI.)
>
>> Will it be written by you (Walter),
>
> No. GUIs are not a core competency of mine <g>.
>
>> Kris, both, somebody
>> > else...? Will it be more like MinWin (very lightweight) or like DWT or
> wxD
>> > (very heavyweight)?
>
> It's whatever the programmers of it wish it to be. Whether and which one becomes the "official" one or not really depends on how the people in this group feel about it. Kris is working on one.
>
>
>> I would also ask: there are just three of them (in Java world):
>> AWT(Sun) ,SWING(Sun), SWT(IBM public license).
>> Latter one is almost done in D. First two are not free to port.
>
> If their licenses do not permit porting and free redistribution for any
> purpose, then they are a total non-starter. I don't recommend that anyone
> waste their time trying to convert such code. SWT, however, seems to have
> a
> license that will work for us.
>
>
>> Walter, what Java GUI library you have in mind?
>
> I'm not competent to judge which one. I just want to open the door as wide
> as possible for those who want to develop GUIs for D, and I hope a
> consensus
> will emerge in this group as to which one to endorse. Kris has convinced
> me
> that supporting inner classes will help a lot, not just for GUIs, but for
> a
> lot of freely reusable Java code.
>
> 

"Sean Kelly" <sean@f4.ca> wrote in message news:d7fg99$2ft0$1@digitaldaemon.com...
> In article <d7elcs$1jkk$1@digitaldaemon.com>, Walter says...
>>
>>"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7d8rp$7n1$1@digitaldaemon.com...
>>> I think that using such tool you can prepare your
>>> Java code to be converted into D without need of
>>> inners in D.
>>
>>I agree, technically it can be done. But it isn't just a matter of making the code work. We also need to leverage the existing *documentation*, because the inner classes are meant to be written in user code that drives the GUI, and that is how the documentation is written.
>
> I don't see anything strikingly wrong with having inner classes in D.
> They
> aren't as neccesary as they are in Java (because D isn't so prohibitively
> object
> oriented) but they do offer a convenient alternative for structuring code.
> And
> since adding them will allow us to leverage a significant amount of
> pre-existing
> code from Java, I really don't see anything bad about this decision (and
> I'm a
> C++ person, not a Java person).  This is great news.
>

In Java inner class instance has parent reference declared as final.

D has no const. Dot.

Imagine what will happened with inner instances in case of outer will be
declared
as auto. All sorts of problems like this.

And add here all problems related to grammar pollution:

Outer o = getSomeOuter();
Outer.Inner i = o.new Inner();

Nice, eh?

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7fmhv$2mp4$1@digitaldaemon.com...
> I even not sure about SWT port.
> EPL (eclipse public license) shall be carefully studied first.
> http://www.eclipse.org/legal/epl-v10.html by anyone
> willing to use SWT/D port. I really don't know how to solve
> all these legal collisions.

Here's the interesting part:

"a) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form."

That seems pretty clear that translations are allowed, as translations are derivative works. Nowhere in the license does it restrict anything to Java, in fact, the word Java never appears.

> What is really make sense -  porting of various in-house
> systems by their owners.  But in any case - Java has a foundation
> of classes. Without these classes any Java code is almost unusable.
> So you will always do some reengineering. I believe that
> replacing inners with delegates will be *very* small part of the problem.

The use of the foundation classes will need to be rewritten, but the capabilities of those foundation classes tend to have rough equivalents in any programming language, so the rewrite is likely to be more a matter of detail than reengineering.

"Walter" <newshound@digitalmars.com> wrote in message news:d7fr1h$2qol$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7fmhv$2mp4$1@digitaldaemon.com...
>> I even not sure about SWT port.
>> EPL (eclipse public license) shall be carefully studied first.
>> http://www.eclipse.org/legal/epl-v10.html by anyone
>> willing to use SWT/D port. I really don't know how to solve
>> all these legal collisions.
>
> Here's the interesting part:
>
> "a) Subject to the terms of this Agreement, each Contributor hereby grants
> Recipient a non-exclusive, worldwide, royalty-free copyright license to
> reproduce, prepare derivative works of, publicly display, publicly
> perform,
> distribute and sublicense the Contribution of such Contributor, if any,
> and
> such derivative works, in source code and object code form."
>
> That seems pretty clear that translations are allowed, as translations are
> derivative works. Nowhere in the license does it restrict anything to
> Java,
> in fact, the word Java never appears.

3. REQUIREMENTS
A Contributor may choose to distribute the Program in object code form under
its own license agreement, provided that:
...
b) its license agreement:
.....
iv) states that source code for the Program is available from such
Contributor, and informs licensees how to obtain it in a reasonable manner
on or through a medium customarily used for software exchange.

This is typical GPL (I guess) requirement and I don't think it will be quite
popular
among business software developers. How all this stuff will be sublicenses,
derived, etc?

>
>> What is really make sense -  porting of various in-house
>> systems by their owners.  But in any case - Java has a foundation
>> of classes. Without these classes any Java code is almost unusable.
>> So you will always do some reengineering. I believe that
>> replacing inners with delegates will be *very* small part of the problem.
>
> The use of the foundation classes will need to be rewritten, but the capabilities of those foundation classes tend to have rough equivalents in any programming language, so the rewrite is likely to be more a matter of detail than reengineering.
>

Umm... I think "is likely to be more a matter of detail than reengineering."
is a bit optimistic. Main use case of Java is JSP and on second
place is mobile platforms and there are quite few serious projects
using Java GUI on desktop.

JSP framework.... It uses many tricks specific to archtecture of bytecoded VM - hybernation, specific memory management and pretty big one: REFLECTION.

Again, inners are just top of the iceberg. Very, very small one.
If only inners would stop Java-to-D transition - everybody
will be already here.

Andrew.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7fscq$2sd9$1@digitaldaemon.com...
> > That seems pretty clear that translations are allowed, as translations
are
> > derivative works. Nowhere in the license does it restrict anything to
> > Java,
> > in fact, the word Java never appears.
>
> 3. REQUIREMENTS
> A Contributor may choose to distribute the Program in object code form
under
> its own license agreement, provided that:
> ...
> b) its license agreement:
> .....
> iv) states that source code for the Program is available from such
> Contributor, and informs licensees how to obtain it in a reasonable manner
> on or through a medium customarily used for software exchange.
>
> This is typical GPL (I guess) requirement and I don't think it will be
quite
> popular
> among business software developers. How all this stuff will be
sublicenses,
> derived, etc?

The "Program" is defined as the initial Eclipse code plus any contributions to Eclipse. I don't read it as including any other code, such as code that would simply link to the SWT library, in particular: "Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program."

So, it is not viral like the GPL in that it does not infect anything linked to it.


> Umm... I think "is likely to be more a matter of detail than
reengineering."
> is a bit optimistic. Main use case of Java is JSP and on second place is mobile platforms and there are quite few serious projects using Java GUI on desktop.
>
> JSP framework.... It uses many tricks specific to archtecture of bytecoded VM - hybernation, specific memory management and pretty big one: REFLECTION.
>
> Again, inners are just top of the iceberg. Very, very small one.
> If only inners would stop Java-to-D transition - everybody
> will be already here.

Kris says it stops the SWT GUI translation - he's in it up to his elbows. D badly needs a full featured GUI. It's worth adding inner class support even if it's only the SWT translation that benefits from it.

I agree that anything using reflection will need reengineering, although D does support some basic reflection (.classinfo, typeid's, and template partial specialization).

There isn't a whole lot of downside to implementing inner classes, if there was I'd fight it. It'll have essentially no impact on programs that don't care to use it.

I have to ask, Andrew ~ just what is your beef ?

I mean, you've made a number of entirely negative remarks within this thread, and from another thread ~ for what? Is it that you just don't like inner-classes? Is it because you somehow feel you should sanction what others spend their time working on? Is it because you somehow feel threatened? You've already clearly noted how you feel about Walter's 'priorities' in this regard ~ do you think you should dictate what he does or doesn't do?

I'll try to clarify some things for you, such that you'll perhaps reconsider spouting off yet more vague assertions:

1) The parties responsible have provided explicit written permission to port their code. It is not GPL, as you claim. That aside, almost all current D libraries & utilities make the source freely available; therefore your 'concerns' in this arena appear fickle. As do the vague and speculative assertions you make, regarding perception from the commercial sector. The term for such actions are widely known as FUD.

2) Shawn is not solely responsible for DWT, though he has put a lot of effort into it ~ you really should have given equal credit to all the others who worked just as hard.

3) A prototype converter has been operational for some time now, and it is entirely feasible to port certain types of Java software with nary an issue; results have been discussed indirectly on this NG during the past several months. The doom and gloom you predict is inane, at best. Nobody (except perhaps you?) is making claims one might whimsically port anything & everything; that would be patently ridiculous.

4) Continued assertions about inner classes not solving world-hunger are just silly ~ they just help porting in certain respects. In particular: they are imperitive to preserving any documented API that applies them. That's important to many.

5) The usage of inner-classes applies to more than trivial Listener designs. Delegates are great, but they can and do run out of steam; making sweeping judgements upon software architecture in general places you upon decidedly shaky ground. At least you had the conscience to note your limited experience with servers ~ there's more to software than UI APIs.

6) People have been doing Java conversions for quite some time. Ben and I are two examples. I understand you feel the original author should somehow be persuaded to port their code instead? Good luck!

7) You have asserted that Java "ruined everything". That's a fairly sweeping statement to make, and appears rather naiive given the total lack of substantiating evidence offered. Whatever.


Again ~ what exactly is your problem here? Regarding this thread? Why all this banal assertion? I really would like to know ...

- Intrigued




"Andrew Fedoniouk" <news@terrainformatica.com> ...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:d7fr1h$2qol$1@digitaldaemon.com...
> >
> > "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7fmhv$2mp4$1@digitaldaemon.com...
> >> I even not sure about SWT port.
> >> EPL (eclipse public license) shall be carefully studied first.
> >> http://www.eclipse.org/legal/epl-v10.html by anyone
> >> willing to use SWT/D port. I really don't know how to solve
> >> all these legal collisions.
> >
> > Here's the interesting part:
> >
> > "a) Subject to the terms of this Agreement, each Contributor hereby
grants
> > Recipient a non-exclusive, worldwide, royalty-free copyright license to
> > reproduce, prepare derivative works of, publicly display, publicly
> > perform,
> > distribute and sublicense the Contribution of such Contributor, if any,
> > and
> > such derivative works, in source code and object code form."
> >
> > That seems pretty clear that translations are allowed, as translations
are
> > derivative works. Nowhere in the license does it restrict anything to
> > Java,
> > in fact, the word Java never appears.
>
> 3. REQUIREMENTS
> A Contributor may choose to distribute the Program in object code form
under
> its own license agreement, provided that:
> ...
> b) its license agreement:
> .....
> iv) states that source code for the Program is available from such
> Contributor, and informs licensees how to obtain it in a reasonable manner
> on or through a medium customarily used for software exchange.
>
> This is typical GPL (I guess) requirement and I don't think it will be
quite
> popular
> among business software developers. How all this stuff will be
sublicenses,
> derived, etc?
>
> >
> >> What is really make sense -  porting of various in-house
> >> systems by their owners.  But in any case - Java has a foundation
> >> of classes. Without these classes any Java code is almost unusable.
> >> So you will always do some reengineering. I believe that
> >> replacing inners with delegates will be *very* small part of the
problem.
> >
> > The use of the foundation classes will need to be rewritten, but the capabilities of those foundation classes tend to have rough equivalents
in
> > any programming language, so the rewrite is likely to be more a matter
of
> > detail than reengineering.
> >
>
> Umm... I think "is likely to be more a matter of detail than
reengineering."
> is a bit optimistic. Main use case of Java is JSP and on second place is mobile platforms and there are quite few serious projects using Java GUI on desktop.
>
> JSP framework.... It uses many tricks specific to archtecture of bytecoded VM - hybernation, specific memory management and pretty big one: REFLECTION.
>
> Again, inners are just top of the iceberg. Very, very small one.
> If only inners would stop Java-to-D transition - everybody
> will be already here.
>
> Andrew.
>
>
>
>

Kris, I relly don't want to be a tory here.
Not my intention, honestly.

I am also not in position to convince anybody to
do or not to do something. What I can do is only
to discuss. Sorry if my sounds are too m.m.m.m ...
emphatic lets say so.

My point is simple - time and resource management.
There are some outstanding issues which are not
in the language yet: and you can name them by yourself.

All OOP languages has const idiom. Even Java. D has not.
Compiler itself is solid but not enough. Adding new, pretty complex,
and most doubtful feature from Java at this point of time means
to postpone version 1.0 up to half of the year.

Motivation of adding inners is not clear as main players are
silent about what they are going to port.
Only in this message SWT poped up.
SWT - good framework but for tasks of creating
IDE alike projects.
It is used primarily in Eclipse. I don't know any other major project
using it.
http://www.clientjava.com/blog/2005/03/22/1111512421510.html
So I am assuming that this feature is only
for porting Eclipse and to create IDE.

IDE without debugger is nothing. It is second thing needs to be done.
If I could decide anything here I will start from doing debugger.
To create a simple IDE after is not a rocket science at all.
Just to start from somenthing. Just to be able to debug
SWT itself. We already have few IDEs in D.
Without debugger nobody will buy D. IMHO.

And moreover core of SWT is already here.

> 2) Shawn is not solely responsible for DWT, though he has put a lot of
> effort into it ~ you really should have given equal credit to all the
> others
> who worked just as hard.

I did, I do and will do. But I didn't get your point.
What is telling you that I am not "giving equal credit to...".
If it sounded this way - terribly sorry, guys.

Again, if inners will help D somehow:
popularity, marketing features, etc. then I am
voting by both hands. But as a realist I just cannot
see how this can be achieved - java-2-D blind translation of
*real* projects - not test pieces of code.

If implementation of inners will significantly popstpone final
D version....  nobody will be happy. And I am not sure
this delay... will it be equalized by inners or not. No idea.

I have experience working with 4 Java VMs and I can tell that
pure Java code porting from VM to VM is not a trivial task.
It took us half of the year to port from MS JVM to Sun
big and real GUI project. Just differences in core libraries.

Again, guys, SWT is good. For Java and Eclipse.
I'd be happy if D will have such IDE. But real one and not
just another editor.

> 6) People have been doing Java conversions for quite some time. Ben and I are two examples. I understand you feel the original author should somehow be persuaded to port their code instead? Good luck!

I completely lost you here. What is this all about?
I am not doing any external ports, I am publishing my own stuff. Good it or
bad?
It is enough for me to think that I did it as it should be implemented.in D.

Andrew.



"Kris" <fu@bar.com> wrote in message news:d7g1dn$314a$1@digitaldaemon.com...
>I have to ask, Andrew ~ just what is your beef ?
>
> I mean, you've made a number of entirely negative remarks within this thread, and from another thread ~ for what? Is it that you just don't like inner-classes? Is it because you somehow feel you should sanction what others spend their time working on? Is it because you somehow feel threatened? You've already clearly noted how you feel about Walter's 'priorities' in this regard ~ do you think you should dictate what he does or doesn't do?
>
> I'll try to clarify some things for you, such that you'll perhaps
> reconsider
> spouting off yet more vague assertions:
>
> 1) The parties responsible have provided explicit written permission to
> port
> their code. It is not GPL, as you claim. That aside, almost all current D
> libraries & utilities make the source freely available; therefore your
> 'concerns' in this arena appear fickle. As do the vague and speculative
> assertions you make, regarding perception from the commercial sector. The
> term for such actions are widely known as FUD.
>
> 2) Shawn is not solely responsible for DWT, though he has put a lot of
> effort into it ~ you really should have given equal credit to all the
> others
> who worked just as hard.
>
> 3) A prototype converter has been operational for some time now, and it is
> entirely feasible to port certain types of Java software with nary an
> issue;
> results have been discussed indirectly on this NG during the past several
> months. The doom and gloom you predict is inane, at best. Nobody (except
> perhaps you?) is making claims one might whimsically port anything &
> everything; that would be patently ridiculous.
>
> 4) Continued assertions about inner classes not solving world-hunger are
> just silly ~ they just help porting in certain respects. In particular:
> they
> are imperitive to preserving any documented API that applies them. That's
> important to many.
>
> 5) The usage of inner-classes applies to more than trivial Listener
> designs.
> Delegates are great, but they can and do run out of steam; making sweeping
> judgements upon software architecture in general places you upon decidedly
> shaky ground. At least you had the conscience to note your limited
> experience with servers ~ there's more to software than UI APIs.
>
> 6) People have been doing Java conversions for quite some time. Ben and I are two examples. I understand you feel the original author should somehow be persuaded to port their code instead? Good luck!
>
> 7) You have asserted that Java "ruined everything". That's a fairly
> sweeping
> statement to make, and appears rather naiive given the total lack of
> substantiating evidence offered. Whatever.
>
>
> Again ~ what exactly is your problem here? Regarding this thread? Why all this banal assertion? I really would like to know ...
>
> - Intrigued
>
>
>
>
> "Andrew Fedoniouk" <news@terrainformatica.com> ...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:d7fr1h$2qol$1@digitaldaemon.com...
>> >
>> > "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7fmhv$2mp4$1@digitaldaemon.com...
>> >> I even not sure about SWT port.
>> >> EPL (eclipse public license) shall be carefully studied first.
>> >> http://www.eclipse.org/legal/epl-v10.html by anyone
>> >> willing to use SWT/D port. I really don't know how to solve
>> >> all these legal collisions.
>> >
>> > Here's the interesting part:
>> >
>> > "a) Subject to the terms of this Agreement, each Contributor hereby
> grants
>> > Recipient a non-exclusive, worldwide, royalty-free copyright license to
>> > reproduce, prepare derivative works of, publicly display, publicly
>> > perform,
>> > distribute and sublicense the Contribution of such Contributor, if any,
>> > and
>> > such derivative works, in source code and object code form."
>> >
>> > That seems pretty clear that translations are allowed, as translations
> are
>> > derivative works. Nowhere in the license does it restrict anything to
>> > Java,
>> > in fact, the word Java never appears.
>>
>> 3. REQUIREMENTS
>> A Contributor may choose to distribute the Program in object code form
> under
>> its own license agreement, provided that:
>> ...
>> b) its license agreement:
>> .....
>> iv) states that source code for the Program is available from such
>> Contributor, and informs licensees how to obtain it in a reasonable
>> manner
>> on or through a medium customarily used for software exchange.
>>
>> This is typical GPL (I guess) requirement and I don't think it will be
> quite
>> popular
>> among business software developers. How all this stuff will be
> sublicenses,
>> derived, etc?
>>
>> >
>> >> What is really make sense -  porting of various in-house
>> >> systems by their owners.  But in any case - Java has a foundation
>> >> of classes. Without these classes any Java code is almost unusable.
>> >> So you will always do some reengineering. I believe that
>> >> replacing inners with delegates will be *very* small part of the
> problem.
>> >
>> > The use of the foundation classes will need to be rewritten, but the capabilities of those foundation classes tend to have rough equivalents
> in
>> > any programming language, so the rewrite is likely to be more a matter
> of
>> > detail than reengineering.
>> >
>>
>> Umm... I think "is likely to be more a matter of detail than
> reengineering."
>> is a bit optimistic. Main use case of Java is JSP and on second place is mobile platforms and there are quite few serious projects using Java GUI on desktop.
>>
>> JSP framework.... It uses many tricks specific to archtecture of bytecoded VM - hybernation, specific memory management and pretty big one: REFLECTION.
>>
>> Again, inners are just top of the iceberg. Very, very small one.
>> If only inners would stop Java-to-D transition - everybody
>> will be already here.
>>
>> Andrew.
>>
>>
>>
>>
>
> 

"Walter" <newshound@digitalmars.com> wrote in message news:d7fupc$2ugj$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7fscq$2sd9$1@digitaldaemon.com...
>> > That seems pretty clear that translations are allowed, as translations
> are
>> > derivative works. Nowhere in the license does it restrict anything to
>> > Java,
>> > in fact, the word Java never appears.
>>
>> 3. REQUIREMENTS
>> A Contributor may choose to distribute the Program in object code form
> under
>> its own license agreement, provided that:
>> ...
>> b) its license agreement:
>> .....
>> iv) states that source code for the Program is available from such
>> Contributor, and informs licensees how to obtain it in a reasonable
>> manner
>> on or through a medium customarily used for software exchange.
>>
>> This is typical GPL (I guess) requirement and I don't think it will be
> quite
>> popular
>> among business software developers. How all this stuff will be
> sublicenses,
>> derived, etc?
>
> The "Program" is defined as the initial Eclipse code plus any
> contributions
> to Eclipse. I don't read it as including any other code, such as code that
> would simply link to the SWT library, in particular: "Contributions do not
> include additions to the Program which: (i) are separate modules of
> software
> distributed in conjunction with the Program under their own license
> agreement, and (ii) are not derivative works of the Program."
>
> So, it is not viral like the GPL in that it does not infect anything
> linked
> to it.
>
>
>> Umm... I think "is likely to be more a matter of detail than
> reengineering."
>> is a bit optimistic. Main use case of Java is JSP and on second place is mobile platforms and there are quite few serious projects using Java GUI on desktop.
>>
>> JSP framework.... It uses many tricks specific to archtecture of bytecoded VM - hybernation, specific memory management and pretty big one: REFLECTION.
>>
>> Again, inners are just top of the iceberg. Very, very small one.
>> If only inners would stop Java-to-D transition - everybody
>> will be already here.
>
> Kris says it stops the SWT GUI translation - he's in it up to his elbows.
> D
> badly needs a full featured GUI. It's worth adding inner class support
> even
> if it's only the SWT translation that benefits from it.
>
> I agree that anything using reflection will need reengineering, although D does support some basic reflection (.classinfo, typeid's, and template partial specialization).
>
> There isn't a whole lot of downside to implementing inner classes, if
> there
> was I'd fight it. It'll have essentially no impact on programs that don't
> care to use it.
>
>

I trust you Walter. If it would be possible to port some Java packages
then why not? They will be not D packages though, but who cares -
the main thing is to get job done.

Are you going to have string constants castable to String, BTW? Or any other class? That would be nice...

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d7gnec$kc0$1@digitaldaemon.com...
> I trust you Walter. If it would be possible to port some Java packages
> then why not? They will be not D packages though, but who cares -
> the main thing is to get job done.

Think of it like C++ initially living off of C code. It was many years before C++ did its own libraries and left C behind - but those early bootstrapping years were very important.

> Are you going to have string constants castable to String, BTW? Or any other class? That would be nice...

What advantage does java.lang.String have? Why does string need to be a class?

Inline,Andrew:

Andrew Fedoniouk wrote:
> Kris, I relly don't want to be a tory here.
> Not my intention, honestly.
<G> Tory? Very funny :-D

Nor my intention.


> I am also not in position to convince anybody to
> do or not to do something. What I can do is only
> to discuss. Sorry if my sounds are too m.m.m.m ...
> emphatic lets say so.

I can be overtly emphatic about certain things too. But I'm afraid I wasn't seeing anything resembling a discussion point; just what appeared to be unsubstantiated FUD. But perhaps I have blinkers on today?


> My point is simple - time and resource management.
> There are some outstanding issues which are not
> in the language yet: and you can name them by yourself.

A point! A point! <g>

I must admit to sharing similar concerns in the past. However, as much as it can be frustrating to those supporting D, I think only Walter will decide when D is 'ready'. What can one do? Argue, leave, or do something about it? My choice is to try and improve the available libraries. There's plenty of work still required in that department, though I think it's great to see more and more people contributing (such as yourself ~ I think Harmonia is a very good idea).


> All OOP languages has const idiom. Even Java. D has not.
> Compiler itself is solid but not enough.

I, too, have an axe to grind over the "read-only" issue. Walter has actually posted a few replies on this topic, though it was long ago.

> Adding new, pretty complex,
> and most doubtful feature from Java at this point of time means
> to postpone version 1.0 up to half of the year.

FUD! <g>


> Motivation of adding inners is not clear as main players are
> silent about what they are going to port.
> Only in this message SWT poped up.

You must have skipped all the times Walter mentioned it in his posts.


> SWT - good framework but for tasks of creating
> IDE alike projects.
> It is used primarily in Eclipse. I don't know any other major project
> using it.
> http://www.clientjava.com/blog/2005/03/22/1111512421510.html
> So I am assuming that this feature is only
> for porting Eclipse and to create IDE.

I don't see a question mark in there; just assertion. So lets move on:


> IDE without debugger is nothing. It is second thing needs to be done.
> If I could decide anything here I will start from doing debugger.
> To create a simple IDE after is not a rocket science at all.
> Just to start from somenthing. Just to be able to debug
> SWT itself. We already have few IDEs in D.

A point which has had much attention in various guises. One can debug D using existing tools, but I don't think anyone would assert it could not be made better. If you could get a group of folks to build a debugger (perhaps into Elephant, or one of the other promising IDE's?), or do it yourself, that would be awesome! There once was a project on dsource within this realm ...


> Without debugger nobody will buy D. IMHO.

It's currently free ... ? Jocular sarcasm aside, solid debugging would probably benefit the perception of D.


> And moreover core of SWT is already here.

Perhaps it is.


>>2) Shawn is not solely responsible for DWT, though he has put a lot of
>>effort into it ~ you really should have given equal credit to all the others
>>who worked just as hard.
> 
> 
> I did, I do and will do. But I didn't get your point.
> What is telling you that I am not "giving equal credit to...".
> If it sounded this way - terribly sorry, guys.

For the record, this is what told me:
<quote>
"I think that AWT and SWING are not free for
porting in D. And for IBM's SWT Shawn Liu
already did an excellent job."
</quote>


> Again, if inners will help D somehow:
> popularity, marketing features, etc. then I am
> voting by both hands. But as a realist I just cannot
> see how this can be achieved - java-2-D blind translation of
> *real* projects - not test pieces of code.

I'll meet your assertion, and raise you several G. Might I suggest you re-read the prior posts?


> If implementation of inners will significantly popstpone final
> D version....  nobody will be happy. And I am not sure
> this delay... will it be equalized by inners or not. No idea.

Strawman. Or perhaps someone (Regan?) will qualify how to correctly define secondary propogation of one's own FUD?


> I have experience working with 4 Java VMs and I can tell that
> pure Java code porting from VM to VM is not a trivial task.
> It took us half of the year to port from MS JVM to Sun
> big and real GUI project. Just differences in core libraries.

Doom and gloom :-)

Perhaps a better initial isolation of the GUI from the functionality might have helped? I don't know. But, again, no one is suggesting doing any such thing (except you).


> Again, guys, SWT is good. For Java and Eclipse.

I see.


> I'd be happy if D will have such IDE. But real one and not
> just another editor.

So help build one? You seem to be a capable dude, and an IntelliJ for D would be truly awesome. Probably a money spinner too.


=============================================


So, you say your concern is with respect to Walter's time-management? Why didn't you just say so in the first place? :-)

Let's move on?