|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
D - The importance of component programming (properties, signals and slots, etc)
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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?
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
;) )
↑ ↓ ← → "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
↑ ↓ ← → "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 ?
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → 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.
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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.
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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!
↑ ↓ ← → "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.
↑ ↓ ← → "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>
↑ ↓ ← → "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 ...
↑ ↓ ← → "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>.
↑ ↓ ← → "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 ...
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → "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!
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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?
↑ ↓ ← → 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....
↑ ↓ ← → "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. :)
↑ ↓ ← → 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. :)
↑ ↓ ← → 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.
↑ ↓ ← → "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
↑ ↓ ← → 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
+----------------------------------------------------------------------+
↑ ↓ ← → "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?)
|
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next