> 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?

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
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 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
(even
> 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)
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.

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. :)

Followup: There appears to be wxWindows wrappers for Python, Eiffel, etc. Perhaps it won't be so hard to do a D version.

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
>very
>> 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
>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 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
>(even
>> 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)
>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.
>
>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. :)
>
>

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

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

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

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

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

"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
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).

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
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.

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> 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
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.

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.