www.digitalmars.com         C & C++   DMDScript  

D - The importance of component programming (properties, signals and slots, etc)

reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
I found an article about component programming that I completely agree with.
Here it is:

http://www.artima.com/intv/simplexity.html

First class support for properties, delegates, signals and slots will open a
brave new world for D...it will make it competitive with C# which quickly
becomes the most preferred programming language around the globe.
Sep 05 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
I see all this talk of signals and slots, cant these things be implemented
really easily ?  Im not sure I see any merit it making it part of the
language.

Charles
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bjb5df$2o5p$1 digitaldaemon.com...
 I found an article about component programming that I completely agree

 Here it is:

 http://www.artima.com/intv/simplexity.html

 First class support for properties, delegates, signals and slots will open

 brave new world for D...it will make it competitive with C# which quickly
 becomes the most preferred programming language around the globe.

Sep 05 2003
parent reply Jotham <jotham ourbrisbane.com> writes:
Charles Sanders wrote:
 I see all this talk of signals and slots, cant these things be implemented
 really easily ?  Im not sure I see any merit it making it part of the
 language.

If something is "implemented really easily", the fact that you can do so should not need to be phrased as a question. I think the article makes some excellent points. Simplicity for me is not when its easy for me to do, but when its easy for someone else to understand and use straight away.
Sep 06 2003
parent Andy Friesen <andy ikagames.com> writes:
Jotham wrote:

 Charles Sanders wrote:
 
 I see all this talk of signals and slots, cant these things be 
 implemented
 really easily ?  Im not sure I see any merit it making it part of the
 language.

If something is "implemented really easily", the fact that you can do so should not need to be phrased as a question. I think the article makes some excellent points. Simplicity for me is not when its easy for me to do, but when its easy for someone else to understand and use straight away.

Sounds like all we need is for a slot template to be added to Phobos. -- andy
Sep 06 2003
prev sibling next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Achilleas Margaritis" <axilmar b-online.gr> escreveu na mensagem
news:bjb5df$2o5p$1 digitaldaemon.com...
 I found an article about component programming that I completely agree

 Here it is:

 http://www.artima.com/intv/simplexity.html

 First class support for properties, delegates, signals and slots will open

 brave new world for D...it will make it competitive with C# which quickly
 becomes the most preferred programming language around the globe.

Using your example (from other thread) I don't see why signals and slots should be part of the language, but I see why implicit template instantiation is desirable. Your example was:
 class Window {
     public signal onMouseMove(Event &event);
 }

 class Button {
     public slot mouseMoved(Event &event);
 }

 Button btn;
 btn.onMouseMove += mouseMoved;

With implicit template instantiation you could write: class Window { public Signal onMouseMove = ...; } class Button { public Slot mouseMoved = ...; } Button btn; btn.onMouseMove ~= mouseMoved; and everything should work ok (I use ~= instead of += because it's D way of appending to a data structure). Today with explicit template instantiation we need some more keywords: class Window { private alias instance TSignal(Event).Signal Signal; public Signal onMouseMove; } class Button { private alias instance TSlot(Event).Slot Slot; public Slot mouseMoved; } Button btn; btn.onMouseMove ~= mouseMoved; With implicit instatiation the compiler should be able to figure out the template parameter "Event" on the body of the "onMouseMove" and "mouseMoved" declarations (essentially delegates). Best regards, Daniel Yokomiso. "Daddy, why doesn't this magnet pick up this floppy disk?" --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 29/8/2003
Sep 06 2003
prev sibling next sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 ...it will make it competitive with C# which quickly
 becomes the most preferred programming language around the globe.

I tend to disagree here. What is the basis for this statement?
Sep 06 2003
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bjclpp$1vvr$1 digitaldaemon.com...
 ...it will make it competitive with C# which quickly
 becomes the most preferred programming language around the globe.

I tend to disagree here. What is the basis for this statement?

The amount of articles and internet "noise" around the subject. From reading newsgroups, message boards and articles I highly get the impression that that C# is quickly becoming very popular. Of course, I don't have statistics in my hand, nor I imply that it is the most used development environment.
Sep 08 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Achilleas Margaritis wrote:
 The amount of articles and internet "noise" around the subject. From reading
 newsgroups, message boards and articles I highly get the impression that
 that C# is quickly becoming very popular. Of course, I don't have statistics
 in my hand, nor I imply that it is the most used development environment.

Just look at MONO and DOTNET - this projets got a boost hardly comparable with any other compiler development effort out there! Besides, i see people leaving from D to C#, but not yet the other way around... The fact is, we cannot close our eyes. C# is a real rival to D, probably to a further extent than C++ and certainly more than Java. -eye
Sep 08 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 The fact is, we cannot close our eyes. C# is a real rival to D, probably
 to a further extent than C++ and certainly more than Java.

I agree with this. No-one really kids themselves that Java's efficient on Win32. And few C++ people (myself included) think that D is a rival. I see D as being primarily a better .NET, though not 100%. Probably its "market" is 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of course. ;) )
Sep 08 2003
parent reply "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its "market"

 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

With properties (including static ones, of course), constructors and destructors being called by their name ("constructor" and "destructor") instead of the C++ way, plus an IDE and a standard library, D may even attract current Delphi users... (...and with a little tomato ketchup on it, it may even be a threat to McDonald's... :-) ) Ric
Sep 09 2003
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bjjv11$f8b$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its "market"

 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

With properties (including static ones, of course), constructors and destructors being called by their name ("constructor" and "destructor") instead of the C++ way, plus an IDE and a standard library, D may even attract current Delphi users... (...and with a little tomato ketchup on it, it may even be a threat to McDonald's... :-) ) Ric

D will make it on the available libraries. .NET is an attractive proposition because of its vast arrays of libraries. Especially for the GUI. The same situation is with Java, plus the fact "write once, run everywhere". What good does a super programming library like D makes, if there is no standard libraries to work with ?
Sep 09 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:bjk4i8$nbk$1 digitaldaemon.com...
 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bjjv11$f8b$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its



 is
 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

With properties (including static ones, of course), constructors and destructors being called by their name ("constructor" and "destructor") instead of the C++ way, plus an IDE and a standard library, D may even attract current Delphi users... (...and with a little tomato ketchup on it, it may even be a threat to McDonald's... :-) ) Ric

D will make it on the available libraries. .NET is an attractive

 because of its vast arrays of libraries. Especially for the GUI. The same
 situation is with Java, plus the fact "write once, run everywhere".

 What good does a super programming library like D makes, if there is no
 standard libraries to work with ?

Well none, but the implied suggestion in your question, i.e. that none will be forthcoming, is erroneous.
Sep 09 2003
parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjkoth$1kek$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> wrote in message
 news:bjk4i8$nbk$1 digitaldaemon.com...
 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bjjv11$f8b$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its



 is
 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

With properties (including static ones, of course), constructors and destructors being called by their name ("constructor" and



 instead of the C++ way, plus an IDE and a standard library, D may even
 attract current Delphi users...

 (...and with a little tomato ketchup on it, it may even be a threat to
 McDonald's... :-) )

 Ric

D will make it on the available libraries. .NET is an attractive

 because of its vast arrays of libraries. Especially for the GUI. The


 situation is with Java, plus the fact "write once, run everywhere".

 What good does a super programming library like D makes, if there is no
 standard libraries to work with ?

Well none, but the implied suggestion in your question, i.e. that none

 be forthcoming, is erroneous.

questions are: 1) when ? C# and Java are ready now. D is light years behind. We all know how difficult is to get rid of a legacy language, with millions of lines of source code behind them. 2) how good will they be ? Will the open source community have the resources to pull this off ? is the open source community a match for the big workforce of companies like Microsoft or Sun ? especially in a limited time period from one release to another ? 3) will they be cross platform ? Most companies would like their apps to run both in the Windows and Linux environment. Java is preferrable for this reason by a large percentage.
Sep 09 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 D will make it on the available libraries. .NET is an attractive

 because of its vast arrays of libraries. Especially for the GUI. The


 situation is with Java, plus the fact "write once, run everywhere".

 What good does a super programming library like D makes, if there is



 standard libraries to work with ?

Well none, but the implied suggestion in your question, i.e. that none

 be forthcoming, is erroneous.


 questions are:

 1) when ?

     C# and Java are ready now. D is light years behind. We all know how
 difficult is to get rid of a legacy language, with millions of lines of
 source code behind them.

D has the advantage of being able to talk directly to C. Of course, .NET and Java have enormous (though often badly designed) libraries. D has a big hill to climb, there's no denying that.
 2) how good will they be ?

     Will the open source community have the resources to pull this off ?

 the open source community a match for the big workforce of companies like
 Microsoft or Sun ? especially in a limited time period from one release to
 another ?

Dunno. I have this same concern myself. We desperately need some kind of libraries group to ensure it all does not become a wild-woman's knitting. I think it can be done - we recently had a good debate about exceptions/errors, which ended with a pretty good concensus. IMO D needs to provide a small set of essential libraries, all well designed, which can act as the basis for, and examples to, the development of third-party libraries, in much the same way that Java packages by 3rd-party vendors have become de-facto standard (e.g. those of Apache).
 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

I think D can do well here. There's nothing stopping things being cross-platform, but it's also good to be able to have platform-specific code, which Java does not (apart from costly JNI calls) But your basic thesis is correct. There's a huge amount of work waiting to happen. We need some early libraries to set the examples.
Sep 09 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
news:bjkrm2$1og0$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjkoth$1kek$1 digitaldaemon.com...

[snip]
 Well none, but the implied suggestion in your question, i.e. that none

 be forthcoming, is erroneous.


 questions are:

 1) when ?

Real Soon Now ;)
     C# and Java are ready now. D is light years behind. We all know how
 difficult is to get rid of a legacy language, with millions of lines of
 source code behind them.

When Java started people said that about C++. Java won.
 2) how good will they be ?

Probably better than Java. At least we have DbC in the language so the operation's contracts won't be just some fancy documentation.
     Will the open source community have the resources to pull this off ?

 the open source community a match for the big workforce of companies like
 Microsoft or Sun ? especially in a limited time period from one release to
 another ?

People said the same about GNU/Linux, *BSD, etc. Time proved that the community can beat companies. Also Sun and Microsoft have very large release schedules, usually more than one year, while the Open Source is release early, release often.
 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

That will depend on three things: conforming compilers, reliance on embedded asm and linked libraries. I would bet that the portability problems will be few, specially when we can create contract layers around plataform dependent, so a new release will be tested in the available plataforms and most bugs will appear on the test builds. <rant> People should stop posting about lack of libraries in D and start coding them. It's been almost a year since I released DTL 0.0.1, and I know there's no excuse for my lack of work in the library, but since then nobody come with another such library, just discussed about how they should look. </rant> Best regards, Daniel Yokomiso. "(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))" --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003
Sep 09 2003
next sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjlr65$4fg$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
 news:bjkrm2$1og0$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjkoth$1kek$1 digitaldaemon.com...

[snip]
 Well none, but the implied suggestion in your question, i.e. that none

 be forthcoming, is erroneous.


 questions are:

 1) when ?

Real Soon Now ;)

One year ? two years ? already late!!!
     C# and Java are ready now. D is light years behind. We all know how
 difficult is to get rid of a legacy language, with millions of lines of
 source code behind them.

When Java started people said that about C++. Java won.

But C++ did not have standard libraries like Swing that work in any platform.
 2) how good will they be ?

Probably better than Java. At least we have DbC in the language so the operation's contracts won't be just some fancy documentation.
     Will the open source community have the resources to pull this off ?

 the open source community a match for the big workforce of companies


 Microsoft or Sun ? especially in a limited time period from one release


 another ?

People said the same about GNU/Linux, *BSD, etc. Time proved that the community can beat companies. Also Sun and Microsoft have very large

 schedules, usually more than one year, while the Open Source is release
 early, release often.

But OSS people have a motive to code for Linux and BSD. And it took 11 years for Linux to reach the current status. And it lacks several things Windows has, especially on the usability front.
 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

That will depend on three things: conforming compilers, reliance on

 asm and linked libraries. I would bet that the portability problems will

 few, specially when we can create contract layers around plataform
 dependent, so a new release will be tested in the available plataforms and
 most bugs will appear on the test builds.

The important compatibility is at source code level, not at binary level.
 <rant>
 People should stop posting about lack of libraries in D and start coding
 them. It's been almost a year since I released DTL 0.0.1, and I know

 no excuse for my lack of work in the library, but since then nobody come
 with another such library, just discussed about how they should look.
 </rant>

Most definitely they should. I am available. We need to form a group, a coordinator...we need a virtual meeting room where we can discuss ideas...there is a lot of things to be done on the organizational front that I don't know anything about (and I am not willing to do).
     Best regards,
     Daniel Yokomiso.

 "(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))"


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

Sep 10 2003
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Achilleas Margaritis wrote:

 Most definitely they should. I am available. We need to form a group, a
 coordinator...we need a virtual meeting room where we can discuss
 ideas...there is a lot of things to be done on the organizational front that
 I don't know anything about (and I am not willing to do).

Would you also be available to help write a C header -> D import converter? BTW, we really need a sourceforge-like community website! Wasn't there anyone who just promised to get one running a few weeks ago? -eye.
Sep 10 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
In article <bjnjdk$2iqc$1 digitaldaemon.com>, Ilya Minkov says...
Achilleas Margaritis wrote:

 Most definitely they should. I am available. We need to form a group, a
 coordinator...we need a virtual meeting room where we can discuss
 ideas...there is a lot of things to be done on the organizational front that
 I don't know anything about (and I am not willing to do).

Would you also be available to help write a C header -> D import converter? BTW, we really need a sourceforge-like community website! Wasn't there anyone who just promised to get one running a few weeks ago?

The D Repository website is very close to being finished. I just posted another thread with more details about completion dates and testing schedules and stuff like that, but I didn't mention much about features in that other thread, so I should mention here that each project in the new site will have its own: - source code repository - download area - (for binary files, docs, archives, and for people without a subversion repository client) - bug tracking database - customizable web area at http://projectname.xxxxxxx.com or http://xxxxxxx.com/project/projectname (I'm not telling anyone the main site domain yet; that's why I used xxxxxxx) - discussion forum The software that will be in use at the new site will be the G-Forge code. It's an open-source branch of the SourceForge code. You can read more about it at http://gforge.org . I'm making a few customizations to the code (so that it can connect to svn rather than cvs) but nothing major. I'll also be changing the template, so that our site will have its own look-and-feel. Over time, I may add other features to the code, by popular demand. For now, the features will be exactly the same as what's offered in the default gforge installation.
Sep 10 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
Benji Smith wrote:
 The D Repository website is very close to being finished.

Thanks!
 For now, the features will be exactly the same as what's offered in
 the default gforge installation.

Frankly, i cannot think out anything else to wish. :) I'm not of any help with software, but i could do design or something... Never mind if you're ready with that. :) -eye
Sep 10 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
----- Original Message ----- 
From: "Achilleas Margaritis" <axilmar in.gr>
Newsgroups: D
Sent: Wednesday, September 10, 2003 4:48 AM
Subject: Re: The importance of component programming (properties, signals
and slots, etc)


 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bjlr65$4fg$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
 news:bjkrm2$1og0$1 digitaldaemon.com...


[snip]
 1) when ?

Real Soon Now ;)

One year ? two years ? already late!!!

So, what's your point? We're doomed, destined to failure ;)
     C# and Java are ready now. D is light years behind. We all know



 difficult is to get rid of a legacy language, with millions of lines



 source code behind them.

When Java started people said that about C++. Java won.

But C++ did not have standard libraries like Swing that work in any platform.

It's true, but there were "millions of lines of source code behind them" written in C++. People moved on no matter what. Also C++ has several GUI libraries, so I don't bite this "holy grail of Swing". [snip]
     Will the open source community have the resources to pull this off



 is
 the open source community a match for the big workforce of companies


 Microsoft or Sun ? especially in a limited time period from one



 to
 another ?

People said the same about GNU/Linux, *BSD, etc. Time proved that the community can beat companies. Also Sun and Microsoft have very large

 schedules, usually more than one year, while the Open Source is release
 early, release often.

But OSS people have a motive to code for Linux and BSD. And it took 11

 for Linux to reach the current status. And it lacks several things Windows
 has, especially on the usability front.

Again, what's your point?
 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows



 Linux environment. Java is preferrable for this reason by a large
 percentage.

That will depend on three things: conforming compilers, reliance on

 asm and linked libraries. I would bet that the portability problems will

 few, specially when we can create contract layers around plataform
 dependent, so a new release will be tested in the available plataforms


 most bugs will appear on the test builds.

The important compatibility is at source code level, not at binary level.

I don't understand what are you trying to say here. What is "source code level"? Conforming compilers? Platform dependent APIs?
 <rant>
 People should stop posting about lack of libraries in D and start coding
 them. It's been almost a year since I released DTL 0.0.1, and I know

 no excuse for my lack of work in the library, but since then nobody come
 with another such library, just discussed about how they should look.
 </rant>

Most definitely they should. I am available. We need to form a group, a coordinator...we need a virtual meeting room where we can discuss ideas...there is a lot of things to be done on the organizational front

 I don't know anything about (and I am not willing to do).

The open source developement model has lots of projects with maintainers and contributors. Period. We don't need no "coordinator", nor "a virtual meeting room". We have IRC and CVS (or whatever). Now we need people interested in writing code in D. People code, publish the CVS tree, contributors submit patches and maintainers either accept or reject. Someday we'll need to integrate two projects and then people will talk (IRC, email, usenet). Everything else is crap. Code matters. Working, tested, reliable code. And documentation. Note that I'm not in rant mode. If Walter waited to form this newsgroup then listened to everyone talking and discussing on how D should be then formed working groups to come with proposals then waited for voting then published a spec then started implementing, I (and most of the people here, if not all, including Walter) would be elsewhere, doing something else. Instead he banged out a compiler, released it, formed a newsgroup, listened to people (ignored most of them ;), modified and patched, and rinse and recycle. It works, people are happy with D. But it is still an infant (pre 1.0 yet, thank god for Walter not rushing it), so we won't have a large user base. What we need is to test it, try it, complain about something (templates anyone? ;) and see the changes. We need code and binaries to make it happen (or else we couldn't test), the same thing with libraries. We need working libraries to see what is good and what is crap, else we'll over-engineer it. Java libraries are over-engineered, they wrote all of them before someone used it in projects, and we don't need to follow that model. Best regards, Daniel Yokomiso. "If you want to be happy be." --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003
Sep 11 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 We need code and binaries to make it happen (or else we couldn't test),

 same thing with libraries. We need working libraries to see what is good

 what is crap, else we'll over-engineer it. Java libraries are
 over-engineered, they wrote all of them before someone used it in

 and we don't need to follow that model.

Heartily agreed
Sep 11 2003
prev sibling next sibling parent reply "Achilleas Margaritis" <axilmar in.gr> writes:
I disagree with you. Read on:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjpjs7$2bsh$1 digitaldaemon.com...
 ----- Original Message -----
 From: "Achilleas Margaritis" <axilmar in.gr>
 Newsgroups: D
 Sent: Wednesday, September 10, 2003 4:48 AM
 Subject: Re: The importance of component programming (properties, signals
 and slots, etc)


 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bjlr65$4fg$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
 news:bjkrm2$1og0$1 digitaldaemon.com...


[snip]
 1) when ?

Real Soon Now ;)

One year ? two years ? already late!!!

So, what's your point? We're doomed, destined to failure ;)

Basically, yes. Except if libraries are available real soon. (that's my opinion, please respect it. I don't want a flame war).
     C# and Java are ready now. D is light years behind. We all know



 difficult is to get rid of a legacy language, with millions of lines



 source code behind them.

When Java started people said that about C++. Java won.

But C++ did not have standard libraries like Swing that work in any platform.

It's true, but there were "millions of lines of source code behind them" written in C++. People moved on no matter what. Also C++ has several GUI libraries, so I don't bite this "holy grail of Swing".

C++ does not have any open source cross platform GUI library. The only cross platform library that I know of is Qt. WxWindows is not a trustworthy solution yet.
 [snip]

     Will the open source community have the resources to pull this




 ?
 is
 the open source community a match for the big workforce of companies


 Microsoft or Sun ? especially in a limited time period from one



 to
 another ?

People said the same about GNU/Linux, *BSD, etc. Time proved that the community can beat companies. Also Sun and Microsoft have very large

 schedules, usually more than one year, while the Open Source is



 early, release often.

But OSS people have a motive to code for Linux and BSD. And it took 11

 for Linux to reach the current status. And it lacks several things


 has, especially on the usability front.

Again, what's your point?

My point is that if there are no cross-platform standard libraries for GUI and other stuff, D won't succeed.
 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows



 Linux environment. Java is preferrable for this reason by a large
 percentage.

That will depend on three things: conforming compilers, reliance on

 asm and linked libraries. I would bet that the portability problems



 be
 few, specially when we can create contract layers around plataform
 dependent, so a new release will be tested in the available plataforms


 most bugs will appear on the test builds.

The important compatibility is at source code level, not at binary


 I don't understand what are you trying to say here. What is "source code
 level"? Conforming compilers? Platform dependent APIs?

Source code-level compatibility is when I take the source code from one O/S, then compile it under another O/S and it runs the same without modification. The underlying implementation may be totally different though.
 <rant>
 People should stop posting about lack of libraries in D and start



 them. It's been almost a year since I released DTL 0.0.1, and I know

 no excuse for my lack of work in the library, but since then nobody



 with another such library, just discussed about how they should look.
 </rant>

Most definitely they should. I am available. We need to form a group, a coordinator...we need a virtual meeting room where we can discuss ideas...there is a lot of things to be done on the organizational front

 I don't know anything about (and I am not willing to do).

The open source developement model has lots of projects with maintainers

 contributors. Period. We don't need no "coordinator", nor "a virtual

 room". We have IRC and CVS (or whatever). Now we need people interested in
 writing code in D. People code, publish the CVS tree, contributors submit
 patches and maintainers either accept or reject. Someday we'll need to
 integrate two projects and then people will talk (IRC, email, usenet).
 Everything else is crap. Code matters. Working, tested, reliable code. And
 documentation. Note that I'm not in rant mode.

Don't be so absolute. We don't just need code. We need a plan. For example, if I start to write a GUI, and you start to write to right your own GUI, a dichotomy will be created...much like KDE vs GNOME. This should be avoided. Of course, I am talking about D being really successful, not just endorsed by open source. Mostly about adopted by corporate environments.
 If Walter waited to form this newsgroup then listened to everyone talking
 and discussing on how D should be then formed working groups to come with
 proposals then waited for voting then published a spec then started
 implementing, I (and most of the people here, if not all, including

 would be elsewhere, doing something else. Instead he banged out a

 released it, formed a newsgroup, listened to people (ignored most of them
 ;), modified and patched, and rinse and recycle. It works, people are

 with D. But it is still an infant (pre 1.0 yet, thank god for Walter not
 rushing it), so we won't have a large user base. What we need is to test

 try it, complain about something (templates anyone? ;) and see the

 We need code and binaries to make it happen (or else we couldn't test),

 same thing with libraries. We need working libraries to see what is good

 what is crap, else we'll over-engineer it. Java libraries are
 over-engineered, they wrote all of them before someone used it in

 and we don't need to follow that model.

But D is the base of our trials. Writing a compiler may be hard to do, but that amounts of %1 of work needed for a modern app to develop. If you ever tried to code a GUI library, you will see that to do it properly you would have to code hundends of thousands of lines of code. A GUI, properly written, is no small task. And then, there are other things that matter: databases, networking, math, etc. GUI is the most important though. Without a GUI, a language goes nowhere. Especially nowadays that C# and Java have a GUI. And when I say it goes nowhere, I am talking about adoption by software development companies (and the big corporations that dish out the contracts). Let me give you an example: I work for a company that makes apps for THALES (ex Thomson). Our apps are defense applications, i.e. military stuff like radar consoles, message interfaces, radar kernels, etc. Up until recently, C++ and ADA was the preferred language. But they had a problem with GUI, because either language lacks a decent cross-platform GUI. So now they are using Java instead. The result is that applications run everywhere (so I can take, let's say, the tactical system main MMI and test it on a PC), but in expense of processing power. It needs a twice as fast PowerPC processor to run the Java-based MMI. C++ has many other deficiencies as a language, which D nicely fixes. If D had all the libraries, it would be preferred over Java and Ada, especially since it supports 'programming-by-contract' (because military apps are strictly tested with every kind of test imaginable, including unit testing). D has a chance of combining speed, programmability and speed of development. All it needs is some decent cross platform libraries.
     Best regards,
     Daniel Yokomiso.

 "If you want to be happy be."


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

Sep 11 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
news:bjq2js$2vn1$1 digitaldaemon.com...
 I disagree with you. Read on:

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bjpjs7$2bsh$1 digitaldaemon.com...

[snip]
 So, what's your point? We're doomed, destined to failure ;)

Basically, yes. Except if libraries are available real soon. (that's my opinion, please respect it. I don't want a flame war).

So, what are you doing here? You believe D is destined to failure, because libraries will take time to be written, and offer no solutions. There's nothing for you here. Seriously. [snip]
 Again, what's your point?

My point is that if there are no cross-platform standard libraries for GUI and other stuff, D won't succeed.

So what, we're supposed to stop working and move on with Java and C#? GUI isn't everything in the world. [snip]
 The open source developement model has lots of projects with maintainers

 contributors. Period. We don't need no "coordinator", nor "a virtual

 room". We have IRC and CVS (or whatever). Now we need people interested


 writing code in D. People code, publish the CVS tree, contributors


 patches and maintainers either accept or reject. Someday we'll need to
 integrate two projects and then people will talk (IRC, email, usenet).
 Everything else is crap. Code matters. Working, tested, reliable code.


 documentation. Note that I'm not in rant mode.

Don't be so absolute. We don't just need code. We need a plan. For

 if I start to write a GUI, and you start to write to right your own GUI, a
 dichotomy will be created...much like KDE vs GNOME. This should be

 Of course, I am talking about D being really successful, not just endorsed
 by open source. Mostly about adopted by corporate environments.

So what, we'll have two, three, ten different gui libraries. Today we have thousands of different languages, the mainstream has at least five, GUIs are written using different libraries (MFC, GTK, QT, Swing, SWT, Fox, WxWindows). Competition is good. If we spend all our time trying to reach a consensus on what is the best way to write a library we'll become a comitee and spend months to decide if a widget should be named ListBox or ListControl. Even if people decide to form a D library group someone will write a different independent GUI library (I have some ideas) and some people may like it better. Like Java with Swing and SWT. [snip] Best regards, Daniel Yokomiso. "In emptiness there is good but no evil. Wisdom exists, logic exists, the Way exists, mind is empty." - Miyamoto Musashi --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003
Sep 13 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjv01i$pqt$1 digitaldaemon.com...
 So what, we'll have two, three, ten different gui libraries. Today we have
 thousands of different languages, the mainstream has at least five, GUIs

 written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
 WxWindows). Competition is good. If we spend all our time trying to reach

 consensus on what is the best way to write a library we'll become a

 and spend months to decide if a widget should be named ListBox or
 ListControl. Even if people decide to form a D library group someone will
 write a different independent GUI library (I have some ideas) and some
 people may like it better. Like Java with Swing and SWT.

Frankly, the best way I believe to do a GUI library for D is to take the best C++ one and simply translate it to D. (Assuming of course the license to it allows that.) It won't achieve perfection that way, but it should get closer to it than starting over from 0.
Sep 17 2003
next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjv01i$pqt$1 digitaldaemon.com...
 So what, we'll have two, three, ten different gui libraries. Today we have
 thousands of different languages, the mainstream has at least five, GUIs

 written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
 WxWindows). Competition is good. If we spend all our time trying to reach

 consensus on what is the best way to write a library we'll become a

 and spend months to decide if a widget should be named ListBox or
 ListControl. Even if people decide to form a D library group someone will
 write a different independent GUI library (I have some ideas) and some
 people may like it better. Like Java with Swing and SWT.

Frankly, the best way I believe to do a GUI library for D is to take the best C++ one and simply translate it to D.

an open license). I think it is a mistake to create a Windows only GUI.
Sep 17 2003
parent "Walter" <walter digitalmars.com> writes:
"Mark T" <Mark_member pathlink.com> wrote in message
news:bkaji9$b7s$1 digitaldaemon.com...
 In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjv01i$pqt$1 digitaldaemon.com...
 So what, we'll have two, three, ten different gui libraries. Today we



 thousands of different languages, the mainstream has at least five,



are
 written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
 WxWindows). Competition is good. If we spend all our time trying to



a
 consensus on what is the best way to write a library we'll become a

 and spend months to decide if a widget should be named ListBox or
 ListControl. Even if people decide to form a D library group someone



 write a different independent GUI library (I have some ideas) and some
 people may like it better. Like Java with Swing and SWT.

Frankly, the best way I believe to do a GUI library for D is to take the best C++ one and simply translate it to D.


 an open license).  I think it is a mistake to create a Windows only GUI.

Yes, of course, a cross platform one. I haven't used the various ones, though, so I am not in a position to judge their relative merits.
Sep 17 2003
prev sibling parent reply Benji Smith <dlanguage xxagg.com> writes:
In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D. (Assuming of course the license
to it allows that.) It won't achieve perfection that way, but it should get
closer to it than starting over from 0.

I agree 100%. Personally, I think somebody should be working on rewriting wxWindows in D. The object hierarchy has already been fleshed out. They've already mapped out workable parallelism between win32 and gtk and mac os x. There are already visual desginers for it. It's a mature project, and we could translate it into D. Yes, it's a huge project. And, yes it would take lots of work. But it will take _even_more_work_ to design and build an entire GUI library from scratch to replace it. --Benji
Sep 17 2003
parent reply Ant <Ant_member pathlink.com> writes:
In article <bkanum$hcq$1 digitaldaemon.com>, Benji Smith says...
In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D. (Assuming of course the license
to it allows that.) It won't achieve perfection that way, but it should get
closer to it than starting over from 0.

I agree 100%. Personally, I think somebody should be working on rewriting wxWindows in D. The object hierarchy has already been fleshed out. They've already mapped out workable parallelism between win32 and gtk and mac os x. There are already visual desginers for it. It's a mature project, and we could translate it into D. Yes, it's a huge project. And, yes it would take lots of work. But it will take _even_more_work_ to design and build an entire GUI library from scratch to replace it. --Benji

Maybe it's time to make a conversion tool. It would help a lot on this project and be very usefull for others. wxWindows GTK only has 194301 lines in .cpp files alone (DUI and tests is now with 43000 in .d files). I don't advice any single person to look at 200000 lines of code. I saw at some page from the D links a description of an .h to .d processor, but I didn't see any download link... Did any one start such a tool? That looks like a one person project. (hey, don't look at me, I have 2 other projects to finish) I did made a small .h to .d to convert the OpenGL headers (quick and dirty) but they use just a small set of c and pre-processor directives. Ant
Sep 17 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bkaqhf$l6t$1 digitaldaemon.com...
 Maybe it's time to make a conversion tool.
 It would help a lot on this project and be very usefull
 for others.

 wxWindows GTK only has 194301 lines in .cpp files alone
 (DUI and tests is now with 43000 in .d files).
 I don't advice any single person to look at 200000 lines of code.

I wonder if it all needs to be converted for a first pass. After all, D can easilly interface to C code. Can much of wxWindows be wrapped in C? Is there a usable subset of wxWindows?
 I saw at some page from the D links a description of an .h to .d
 processor, but I didn't see any download link...

 Did any one start such a tool?
 That looks like a one person project.
 (hey, don't look at me, I have 2 other projects to finish)

Doing C headers to D is one thing, but doing C++ is another.
 I did made a small .h to .d to convert the OpenGL headers
 (quick and dirty)
 but they use just a small set of c and pre-processor directives.

 Ant

Sep 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
Followup: There appears to be wxWindows wrappers for Python, Eiffel, etc.
Perhaps it won't be so hard to do a D version.
Sep 18 2003
parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:
 Followup: There appears to be wxWindows wrappers for Python, Eiffel, etc.
 Perhaps it won't be so hard to do a D version.

! wxWindows uses SWIG to generate all those other language bindings. It would probably be worthwhile to look into getting SWIG to make D bindings as well. -- andy
Sep 18 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
In article <bkcbf8$2r06$1 digitaldaemon.com>, Andy Friesen says...
wxWindows uses SWIG to generate all those other language bindings.  It 
would probably be worthwhile to look into getting SWIG to make D 
bindings as well.

I've just spent the last 20 minutes or so reading up about swig ( http://www.swig.org ) and I'm impressed. Since there are already language bindings connecting C/C++ to Java, C#, Perl, Python, PHP, OCaml (and a few other languages), it shouldn't be too difficult to use those implementations as a reference for creating a D SWIG extension. In my opinion, this is the most important project for D in the upcoming year. Because if we can assemble a general purpose method for creating bindings between C++ and D, we'll open up access to lots of existing libraries that we can't use now. As soon as I've got the repository site up and running, this is one of the projects I'g going to create. --Benji Smith
Sep 18 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bkcgu9$1d2$1 digitaldaemon.com>, Benji Smith says...
In article <bkcbf8$2r06$1 digitaldaemon.com>, Andy Friesen says...
wxWindows uses SWIG to generate all those other language bindings.  It 
would probably be worthwhile to look into getting SWIG to make D 
bindings as well.

I've just spent the last 20 minutes or so reading up about swig ( http://www.swig.org ) and I'm impressed. Since there are already language bindings connecting C/C++ to Java, C#, Perl, Python, PHP, OCaml (and a few other languages), it shouldn't be too difficult to use those implementations as a reference for creating a D SWIG extension. In my opinion, this is the most important project for D in the upcoming year.

You're probably right. It might be the second most important ever for D (after the creation of the compiler) now, why the upcoming year? maybe with SWIG a D GUI lib can be created faster then finishing DUI... Some body dismissed SWIG as usable for some other D project. Why? (just insanity or is there some reason?) Ant
Sep 18 2003
parent reply BenjiSmith <dlanguage xxagg.com> writes:
In article <bkcjko$5cd$1 digitaldaemon.com>, Ant says...
now, why the upcoming year?

1) Because I'm not up to the job myself. I'm not a competent enough C/C++ programmer to build the bridge between SWIG and D. And even if I was competent enough, I'm incredibly busy. Everybody else seems to be incredibly busy, too, so I don't know who has big chunks of free time. 2) I don't know how difficult it would be. How many lines of code would it take to build the SWIG extension for D? 1,000? 10,000? I honestly have no idea. (Though I could probably get a pretty good idea if I downloaded the C# and Java SWIG Extension source code). 3) [I think this is the most important reason] The language isn't finished yet. There are still significant semantic changes being made to the D language spec. I don't know how much (if any) impact those semantic changes would have on the creation of a SWIG extension, but I'd certainly want to know that I wasn't going to waste time reworking a SWIG extension following a significant language change. --Benji
Sep 18 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bkckt2$79l$1 digitaldaemon.com>, BenjiSmith says...
In article <bkcjko$5cd$1 digitaldaemon.com>, Ant says...
now, why the upcoming year?

1) Because I'm not up to the job myself. I'm not a competent enough C/C++ programmer to build the bridge between SWIG and D. And even if I was competent enough, I'm incredibly busy. Everybody else seems to be incredibly busy, too, so I don't know who has big chunks of free time. 2) I don't know how difficult it would be. How many lines of code would it take to build the SWIG extension for D? 1,000? 10,000? I honestly have no idea. (Though I could probably get a pretty good idea if I downloaded the C# and Java SWIG Extension source code). 3) [I think this is the most important reason] The language isn't finished yet. There are still significant semantic changes being made to the D language spec. I don't know how much (if any) impact those semantic changes would have on the creation of a SWIG extension, but I'd certainly want to know that I wasn't going to waste time reworking a SWIG extension following a significant language change. --Benji

3 very good reasons! but not good enough :) I wasn't implying that you should start it sooner, sorry if it looks like that. I was just stating the obvious that nobody should feel any constraint by the "upcoming year" thing... Ant
Sep 18 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
Holy cow. I just downloaded the SWIG sources and I've been looking around at
what it would take to write a SWIG extension for D. And this is the answer:

NOT VERY MUCH

In order to customize SWIG for any given language, there is only one source file
that needs to be created. For Java, it's a file called "java.cxx" for C#, it's a
file called "csharp.cxx". Each of these files is moderately complex. The java
file, with all of the comments and newlines stripped out, is about 1400 lines of
code (in C++). The csharp file is about 1600 lines.

That's not very much code.

Plus, I'm guessing that much of the code for the D extension would look an awful
lot like the code for the Java and C# extensions, so we could borrow heavily
from the existing implementation.

However, this project is not for the faint of heart. Even if it only requires
writing 1500 or so lines of code, the author will have to have a pretty good
command of C++ (I'm already out of the running) and an excellent understanding
of D semantics (that eliminately most of us).

But, on the upside, once it's done we'll have access to millions of lines of C++
code to use as imports and libraries for our own projects. I'm just giddy at the
notion that we could suddenly have access to the entire wxWindows library, after
writing only 1500 lines of code.

--Benji Smith
Sep 18 2003
parent "Walter" <walter digitalmars.com> writes:
Cool! Also, let's start a new thread on this!

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bkctb3$j5j$1 digitaldaemon.com...
 Holy cow. I just downloaded the SWIG sources and I've been looking around

 what it would take to write a SWIG extension for D. And this is the

 NOT VERY MUCH

 In order to customize SWIG for any given language, there is only one

 that needs to be created. For Java, it's a file called "java.cxx" for C#,

 file called "csharp.cxx". Each of these files is moderately complex. The

 file, with all of the comments and newlines stripped out, is about 1400

 code (in C++). The csharp file is about 1600 lines.

 That's not very much code.

 Plus, I'm guessing that much of the code for the D extension would look an

 lot like the code for the Java and C# extensions, so we could borrow

 from the existing implementation.

 However, this project is not for the faint of heart. Even if it only

 writing 1500 or so lines of code, the author will have to have a pretty

 command of C++ (I'm already out of the running) and an excellent

 of D semantics (that eliminately most of us).

 But, on the upside, once it's done we'll have access to millions of lines

 code to use as imports and libraries for our own projects. I'm just giddy

 notion that we could suddenly have access to the entire wxWindows library,

 writing only 1500 lines of code.

 --Benji Smith

Sep 18 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"BenjiSmith" <dlanguage xxagg.com> wrote in message
news:bkckt2$79l$1 digitaldaemon.com...
 2) I don't know how difficult it would be. How many lines of code would it

 to build the SWIG extension for D? 1,000? 10,000? I honestly have no idea.
 (Though I could probably get a pretty good idea if I downloaded the C# and

 SWIG Extension source code).

I agree that the C# and Java versions would be excellent guides for making a D version.
 3) [I think this is the most important reason] The language isn't finished

 There are still significant semantic changes being made to the D language

 I don't know how much (if any) impact those semantic changes would have on

 creation of a SWIG extension, but I'd certainly want to know that I wasn't

 to waste time reworking a SWIG extension following a significant language
 change.

I'm very careful not to change the language in any fundamental way, exactly because of this problem. There may be a bit of tweaking required (things like changing the names of the operator overload functions), but I seriously doubt anything more than that. I can't think of anything that would require a rewrite.
Sep 18 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
In article <bkcp02$d2r$1 digitaldaemon.com>, Walter says...
I'm very careful not to change the language in any fundamental way, exactly
because of this problem. There may be a bit of tweaking required (things
like changing the names of the operator overload functions), but I seriously
doubt anything more than that. I can't think of anything that would require
a rewrite.

I'm glad to hear that the language is stable enough for this type of work to commence. Apparantly, the swig wrapper generators are based on the notion of creating typemaps between the type systems of the two different languages. I'm not sure how much of that typemapping is implementation dependent, but I'm curious to hear your opinion. If another compiler vendor makes different implementation decisions about type sizes and whatnot, how do you think that might affect the mapping of types between D and C++? I've just written an email to the guy who wrote the Java and C# language libraries for the swig project, asking him some questions about the current state of the modules and for advice about any implementation hurdles that could get in the way of a D implementation. I'll post more information when I get his reply. --Benji Smith
Sep 18 2003
next sibling parent Benij Smith <dlanguage xxagg.com> writes:
In article <bkd3bl$rdh$1 digitaldaemon.com>, Benji Smith says...
I've just written an email to the guy who wrote the Java and C# language
libraries for the swig project, asking him some questions about the current
state of the modules and for advice about any implementation hurdles that could
get in the way of a D implementation. I'll post more information when I get his
reply.

I got a reply (already!) to the email that I sent to this guy. According to him... <quote> If D is very similar to C# you might have something up and running in a day or two. To begin with don't change the source code in csharp.cxx (or a new d.cxx), just modify the typemaps in csharp.swg. (What are you going to call it? d.cxx, class D and d.swg is rediculously short!) I suspect that after 2 weeks it will be in a fairly reasonable shape. A month later quite polished. It will probably never be perfect! </quote> So, there's the possibility of having some swig compatibility very shortly. If anyone is interested in working on this project, let me know (through the ng, not email), and I'll forward you the rest of the above email, which has quite a few more helpful hints and suggestions for creating the D swig implementation. --Benji
Sep 18 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bkd3bl$rdh$1 digitaldaemon.com...
 Apparantly, the swig wrapper generators are based on the notion of

 typemaps between the type systems of the two different languages. I'm not

 how much of that typemapping is implementation dependent, but I'm curious

 hear your opinion. If another compiler vendor makes different

 decisions about type sizes and whatnot, how do you think that might affect

 mapping of types between D and C++?

D specifies the sizes of all the types except real. So that shouldn't be a problem.
 I've just written an email to the guy who wrote the Java and C# language
 libraries for the swig project, asking him some questions about the

 state of the modules and for advice about any implementation hurdles that

 get in the way of a D implementation. I'll post more information when I

 reply.

Thanks!
Sep 18 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bkcgu9$1d2$1 digitaldaemon.com...
 In article <bkcbf8$2r06$1 digitaldaemon.com>, Andy Friesen says...
wxWindows uses SWIG to generate all those other language bindings.  It
would probably be worthwhile to look into getting SWIG to make D
bindings as well.

I've just spent the last 20 minutes or so reading up about swig ( http://www.swig.org ) and I'm impressed. Since there are already language bindings connecting C/C++ to Java, C#, Perl, Python, PHP, OCaml (and a few

 languages), it shouldn't be too difficult to use those implementations as

 reference for creating a D SWIG extension.

 In my opinion, this is the most important project for D in the upcoming

 Because if we can assemble a general purpose method for creating bindings
 between C++ and D, we'll open up access to lots of existing libraries that

 can't use now.

I agree. A D binding for SWIG looks like it'll be a very valuable project. Since SWIG already works on wxWindows, doing SWIG for D seems to be a better first step.
Sep 18 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjpjs7$2bsh$1 digitaldaemon.com...
 If Walter waited to form this newsgroup then listened to everyone talking
 and discussing on how D should be then formed working groups to come with
 proposals then waited for voting then published a spec then started
 implementing, I (and most of the people here, if not all, including

 would be elsewhere, doing something else. Instead he banged out a

 released it, formed a newsgroup, listened to people (ignored most of them
 ;), modified and patched, and rinse and recycle. It works, people are

 with D. But it is still an infant (pre 1.0 yet, thank god for Walter not
 rushing it), so we won't have a large user base. What we need is to test

 try it, complain about something (templates anyone? ;) and see the

 We need code and binaries to make it happen (or else we couldn't test),

 same thing with libraries. We need working libraries to see what is good

 what is crap, else we'll over-engineer it. Java libraries are
 over-engineered, they wrote all of them before someone used it in

 and we don't need to follow that model.

One amusing thing about D is about everyone tells me I'm going to fail with it. Of course, I've been told that about every single successful project I've worked on. The irony is that the projects people have told me were sure things have been the failures <g>. Anyhow, D has already been a dramatic success. That's easy to see given the activity in the D newsgroup and the high quality of discussion here and the high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even a rubber axe can chop down an oak tree if you keep on swinging, and that is certainly what I intend to do. The language is steadilly improving, it's just received a foreach, I'm working on fleshing out the operator overloading, and I have several ideas and suggestions from you guys for improving templates percolating around. We'll keep plugging away, and things will only get better. For those concerned about the libraries - sure, D's libraries are woefully inadequate right now. But don't worry about writing library code that is less than perfect, just write it. Evolve it over time into perfection. Look at how C++ libraries changed over time. How many times has iostream been re-engineered from scratch? <g>
Sep 17 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 For those concerned about the libraries - sure, D's libraries are woefully
 inadequate right now. But don't worry about writing library code that is
 less than perfect, just write it. Evolve it over time into perfection.

 at how C++ libraries changed over time. How many times has iostream been
 re-engineered from scratch? <g>

There should only ever have been one reworking of the iostreams, and I think you know what that would have been ...
Sep 17 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkaipi$a1i$2 digitaldaemon.com...
 For those concerned about the libraries - sure, D's libraries are


 inadequate right now. But don't worry about writing library code that is
 less than perfect, just write it. Evolve it over time into perfection.

 at how C++ libraries changed over time. How many times has iostream been
 re-engineered from scratch? <g>


 you know what that would have been ...

There have been at least three reengineerings of it. That's why DMC++ has <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.
Sep 17 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkaipi$a1i$2 digitaldaemon.com...
 For those concerned about the libraries - sure, D's libraries are


 inadequate right now. But don't worry about writing library code that



 less than perfect, just write it. Evolve it over time into perfection.

 at how C++ libraries changed over time. How many times has iostream



 re-engineered from scratch? <g>


 you know what that would have been ...

There have been at least three reengineerings of it. That's why DMC++ has <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

The iostream include I would be looking for would involve no characters at all ...
Sep 17 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
----- Original Message ----- 
From: "Matthew Wilson" <matthew stlsoft.org>
Newsgroups: D
Sent: Wednesday, September 17, 2003 4:26 PM
Subject: Re: The importance of component programming (properties, signals
and slots, etc)
 at how C++ libraries changed over time. How many times has iostream



 re-engineered from scratch? <g>


 you know what that would have been ...

There have been at least three reengineerings of it. That's why DMC++


 <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

The iostream include I would be looking for would involve no characters at all ...

What don't you like about it? The overloading abuse or the layering and buffering? Or the naming scheme for member functions? Or the clutter that allocators and traits bring to the debug info? Surely it can be done better, but it's not a horrible piece of engineering. Input and output iterators aren't such a bad idea. They can let you use some of the generic data handling mechanisms in STL to manipulate file data. for instance this probably works (though I haven't tried it, it does at least compile): #include <fstream> #include <functional> #include <algorithm> using namespace std; void print_int_after_first_int_in_this_file_thats_at_least(ostream& so, istream& si, int at_least) { typedef istream_iterator<int> it; it found = find_if(it(si),it(),bind2nd(less<int>(),at_least)); if (!(found == it())) *ostream_iterator<int>(so) = *found; } That's a lot of power, speed be damned. Surely it could look prettier or be friendlier or easier to use, but this is certainly a step in the right direction. You can actually implement your own ostream and istream above and hook this function up to any data pipe you can imagine. Pass in any function you can build for the test as unary_function<int,bool>. There are all kinds of algorithms too, stuff like copy_if and replace_if, that are useful for moving and filtering data. Check out the notes on the operator* and operator= in the std::ostream_iterator class. ;) Sean
Sep 19 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Anyhow, D has already been a dramatic success. That's easy to see given

 activity in the D newsgroup and the high quality of discussion here and

 high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even a
 rubber axe can chop down an oak tree if you keep on swinging, and that is
 certainly what I intend to do. The language is steadilly improving, it's
 just received a foreach, I'm working on fleshing out the operator
 overloading, and I have several ideas and suggestions from you guys for
 improving templates percolating around. We'll keep plugging away, and

 will only get better.

Any chance of you updating the SynSoft link to mention the Performance, String Tokenisation and Registry libraries? :) Also, have you had a look at the reg stuff yet? I started work on some reg-writing code (porting a set of C++ utility fns of my own, that have served almost all my needs over the last 5 yrs) last night - when I should be writing my article; deadline today!! - and that all went really easily. I plan to implement a synsoft.win32.regutil module, on which the synsoft.win32.reg will be implemented. That way, if the class-based registry stuff falls short in some esoteric way, the user can get whatever they want from the free function API, rather than trying to write the catch-all API.
Sep 17 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkakce$cb8$1 digitaldaemon.com...
 Any chance of you updating the SynSoft link to mention the Performance,
 String Tokenisation and Registry libraries? :)

Write me a brief text, and I'll update it with that text. And that goes for all! I try to keep up with the dlinks, but if the descriptions fall short, need updating, or are missing, please provide the text for me and I'll fix it.
 Also, have you had a look at the reg stuff yet? I started work on some
 reg-writing code (porting a set of C++ utility fns of my own, that have
 served almost all my needs over the last 5 yrs) last night - when I should
 be writing my article; deadline today!! - and that all went really easily.

 plan to implement a synsoft.win32.regutil module, on which the
 synsoft.win32.reg will be implemented. That way, if the class-based

 stuff falls short in some esoteric way, the user can get whatever they

 from the free function API, rather than trying to write the catch-all API.

I looked at the reg stuff. It needs write capability, and after looking at it, it really does need properties to look its best!
Sep 17 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
Well, that'll teach me! I thought I was writing an email.

Good job I didn't say anything rude!! <blush>

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkakce$cb8$1 digitaldaemon.com...
 Anyhow, D has already been a dramatic success. That's easy to see given

 activity in the D newsgroup and the high quality of discussion here and

 high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even


 rubber axe can chop down an oak tree if you keep on swinging, and that


 certainly what I intend to do. The language is steadilly improving, it's
 just received a foreach, I'm working on fleshing out the operator
 overloading, and I have several ideas and suggestions from you guys for
 improving templates percolating around. We'll keep plugging away, and

 will only get better.

Any chance of you updating the SynSoft link to mention the Performance, String Tokenisation and Registry libraries? :) Also, have you had a look at the reg stuff yet? I started work on some reg-writing code (porting a set of C++ utility fns of my own, that have served almost all my needs over the last 5 yrs) last night - when I should be writing my article; deadline today!! - and that all went really easily.

 plan to implement a synsoft.win32.regutil module, on which the
 synsoft.win32.reg will be implemented. That way, if the class-based

 stuff falls short in some esoteric way, the user can get whatever they

 from the free function API, rather than trying to write the catch-all API.

Sep 17 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:bkac7h$6c$1 digitaldaemon.com...

 Even a rubber axe can chop down an oak tree if you keep on swinging, and
 that is certainly what I intend to do.

But can you do it... with... a herring? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 17 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bkaqbj$kpl$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:bkac7h$6c$1 digitaldaemon.com...

 Even a rubber axe can chop down an oak tree if you keep on swinging, and
 that is certainly what I intend to do.

But can you do it... with... a herring?

Monty Python?
Sep 17 2003
next sibling parent reply Felix <Felix_member pathlink.com> writes:
Hi,

I do not remember this topic's thread very well, but I think the title is very
interesting. So, to bring the discussion back where it belongs, what about
component programming?

Could somebody put some ActiveX programmed controls, by example? I think is the
widest spreaded component interface. I know it is possible to program ActiveX
controls/forms in D but I found no real example. As a beginner, I would need
that.


Further, I know that D classes are compatible with this kind of components (even
ActiveX). But, there is a real internal support for that? I mean, are the
classes conceived as components? Are they really supporting (internally) events,
properties and methods? I do not like very much to imagine first the entire
application's class tree and to implement each class afterward as an extention
of the (same) ancestor. Reusing components, aggregating and connecting them is
simpler, I think. You can easily change the message trajectories at the
run-time, by example. Anyway, just an opinion.

Please be kind with me....
Sep 17 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Hi,

 I do not remember this topic's thread very well, but I think the title is

 interesting. So, to bring the discussion back where it belongs, what about
 component programming?

There is a good, though not great, basis in the language for component programming. There are (AFAIK) no libraries yet for doing it.
 Could somebody put some ActiveX programmed controls, by example? I think

 widest spreaded component interface. I know it is possible to program

 controls/forms in D but I found no real example. As a beginner, I would

 that.

My plans, once the Registry library is complete, and ensconced in Phobos, is to implement a COM library. (Since COM relies so heavily on the registry, we need a registry API first.) I hope to get something that is as small and flexible as ATL, but without its flaws, and without all that macro gunk. I've written my own COM libraries, and have used ATL and MFC's COM extensively, so hopefully I can do something that combines the good and leaves out the bad. (Famous last words ... ???) As to what form it will actually take, however, it's all just meandering around in my subconsious at the moment, I'm afraid.
 Further, I know that D classes are compatible with this kind of components

 ActiveX). But, there is a real internal support for that?

Don't know what you mean. :(
 I mean, are the
 classes conceived as components? Are they really supporting (internally)

 properties and methods? I do not like very much to imagine first the

 application's class tree and to implement each class afterward as an

 of the (same) ancestor.

Sorry, I don't follow.
 Reusing components, aggregating and connecting them is
 simpler, I think. You can easily change the message trajectories at the
 run-time, by example. Anyway, just an opinion.

 Please be kind with me....

Of course. :)
Sep 18 2003
parent Felix <Felix_member pathlink.com> writes:
Thanks for answers. Forget the last issues in my message. Maybe I am too old ;)
already ;)




In article <bkbq7a$23lj$1 digitaldaemon.com>, Matthew Wilson says...
 Hi,

 I do not remember this topic's thread very well, but I think the title is

 interesting. So, to bring the discussion back where it belongs, what about
 component programming?

There is a good, though not great, basis in the language for component programming. There are (AFAIK) no libraries yet for doing it.
 Could somebody put some ActiveX programmed controls, by example? I think

 widest spreaded component interface. I know it is possible to program

 controls/forms in D but I found no real example. As a beginner, I would

 that.

My plans, once the Registry library is complete, and ensconced in Phobos, is to implement a COM library. (Since COM relies so heavily on the registry, we need a registry API first.) I hope to get something that is as small and flexible as ATL, but without its flaws, and without all that macro gunk. I've written my own COM libraries, and have used ATL and MFC's COM extensively, so hopefully I can do something that combines the good and leaves out the bad. (Famous last words ... ???) As to what form it will actually take, however, it's all just meandering around in my subconsious at the moment, I'm afraid.
 Further, I know that D classes are compatible with this kind of components

 ActiveX). But, there is a real internal support for that?

Don't know what you mean. :(
 I mean, are the
 classes conceived as components? Are they really supporting (internally)

 properties and methods? I do not like very much to imagine first the

 application's class tree and to implement each class afterward as an

 of the (same) ancestor.

Sorry, I don't follow.
 Reusing components, aggregating and connecting them is
 simpler, I think. You can easily change the message trajectories at the
 run-time, by example. Anyway, just an opinion.

 Please be kind with me....

Of course. :)

Sep 18 2003
prev sibling parent Mike Wynn <mike l8night.co.uk> writes:
Felix wrote:
 Hi,
 
 I do not remember this topic's thread very well, but I think the title is very
 interesting. So, to bring the discussion back where it belongs, what about
 component programming?
 
 Could somebody put some ActiveX programmed controls, by example? I think is the
 widest spreaded component interface. I know it is possible to program ActiveX
 controls/forms in D but I found no real example. As a beginner, I would need
 that.
 

my code for imbedding an instance of MSIE in a D window (using my win32 wrapper classes) can be found on http://www.geocities.com/one_mad_alien/dcom_not_dcom.html you may have to tweek it a bit it is all 0.68 not 0.7x and my windows machine has blown up so I'm only using linux at present.
Sep 18 2003
prev sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Walter" <walter digitalmars.com> escreveu na mensagem
news:bkb2mm$10cd$1 digitaldaemon.com...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bkaqbj$kpl$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:bkac7h$6c$1 digitaldaemon.com...

 Even a rubber axe can chop down an oak tree if you keep on swinging,



 that is certainly what I intend to do.

But can you do it... with... a herring?

Monty Python?

Yes. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
Sep 18 2003
prev sibling parent Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:
Daniel Yokomiso wrote:

     Best regards,
     Daniel Yokomiso.
 
 "(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))"

I like your sig :-) -- +----------------------------------------------------------------------+ I Dr. Olaf Rogalsky Institut f. Theo. Physik I I I Tel.: 09131 8528440 Univ. Erlangen-Nuernberg I I Fax.: 09131 8528444 Staudtstrasse 7 B3 I I rogalsky theorie1.physik.uni-erlangen.de D-91058 Erlangen I +----------------------------------------------------------------------+
Oct 02 2003
prev sibling parent "Jeroen van Bemmel" <someone somewhere.com> writes:
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bjb5df$2o5p$1 digitaldaemon.com...
 I found an article about component programming that I completely agree

 Here it is:

 http://www.artima.com/intv/simplexity.html

BTW, the fact that delegation does not break overloading to me makes it look more like syntactic sugar that is really an interface. I wonder how they can claim to resolve such overloads at compile time. For example, given some method m ( X someObject ) { delegate d = someObject.func; } and a class Y : X { void func() { ... } // overloads X.func } how can they know in advance that d will be pointing toY.func() when m(y) is called? Y could be compiled separately. Perhaps the virtual table needs only be walked once (at the point where d is assigned) and then calling the delegate becomes a simple call instruction. But to me it needs to be resolved at run time. And moreover, you lose the information that the object being called was 'y' (or not? do they store the reference too?)
Sep 06 2003