www.digitalmars.com         C & C++   DMDScript  

D - Dynamic Capabilities of D

reply Barry Carr <barrycarr ixian-software.com> writes:
Hi,

I was looking at the language comparison chart for D and I was wondering
how dynamic was the language at runtime? 

One of the things that I don't like about C++ is its lack of virtual 
constructors, or any other mechanism within the language to be able to 
instantiate an object without compile time knowledge of its type. Java and 
C# get around this through reflection - not ideal but it works. Delphi has 
a datatype design to hold class references that make dynamic instantiation 
very easy. Does D have a similar facility? If not, could you explain why 
this feature wasn't included as it strikes me as being an absolutely vital 
feature of any OO language. I also notice that someone else asked a similar 
question in this newsgroup in Feb 2001; Has any progress been made in this 
area since then?

Cheers,

Barry Carr

Ixian Software Components Ltd
Blairgowrie
Perthshire
Scotland
www.Ixian-Software.com
Dec 28 2003
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
dunno why this should be vital at all.. D is not a scripting language, and not
written in runtime.. why should it be able to create objects of unknown type at
runtime? there are simply no unkown types anymore at runtime.

and creating a factory in D is ridiculous easy.. so no problem.

In article <Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61>, Barry Carr
says...
Hi,

I was looking at the language comparison chart for D and I was wondering
how dynamic was the language at runtime? 

One of the things that I don't like about C++ is its lack of virtual 
constructors, or any other mechanism within the language to be able to 
instantiate an object without compile time knowledge of its type. Java and 
C# get around this through reflection - not ideal but it works. Delphi has 
a datatype design to hold class references that make dynamic instantiation 
very easy. Does D have a similar facility? If not, could you explain why 
this feature wasn't included as it strikes me as being an absolutely vital 
feature of any OO language. I also notice that someone else asked a similar 
question in this newsgroup in Feb 2001; Has any progress been made in this 
area since then?

Cheers,

Barry Carr

Ixian Software Components Ltd
Blairgowrie
Perthshire
Scotland
www.Ixian-Software.com

Dec 28 2003
next sibling parent Mathias Becker <Mathias_member pathlink.com> writes:
In article <bsmu5g$1m96$1 digitaldaemon.com>, davepermen says...
dunno why this should be vital at all.. D is not a scripting language, and not
written in runtime.. why should it be able to create objects of unknown type at
runtime? there are simply no unkown types anymore at runtime.

and creating a factory in D is ridiculous easy.. so no problem.

In article <Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61>, Barry Carr
says...
Hi,

I was looking at the language comparison chart for D and I was wondering
how dynamic was the language at runtime? 

One of the things that I don't like about C++ is its lack of virtual 
constructors, or any other mechanism within the language to be able to 
instantiate an object without compile time knowledge of its type. Java and 
C# get around this through reflection - not ideal but it works. Delphi has 
a datatype design to hold class references that make dynamic instantiation 
very easy. Does D have a similar facility? If not, could you explain why 
this feature wasn't included as it strikes me as being an absolutely vital 
feature of any OO language. I also notice that someone else asked a similar 
question in this newsgroup in Feb 2001; Has any progress been made in this 
area since then?

Cheers,

Barry Carr

Ixian Software Components Ltd
Blairgowrie
Perthshire
Scotland
www.Ixian-Software.com


Dec 28 2003
prev sibling parent reply Barry Carr <barrycarr ixian-software.com> writes:
davepermen <davepermen_member pathlink.com> wrote in
news:bsmu5g$1m96$1 digitaldaemon.com: 

 dunno why this should be vital at all.. D is not a scripting language,
 and not written in runtime.. why should it be able to create objects
 of unknown type at runtime? there are simply no unkown types anymore
 at runtime. 
 
 and creating a factory in D is ridiculous easy.. so no problem.

It is vital because an application should be a network of autonomous objects able to react to new situations (within reason) and work with derived classes without any trouble - as Liskov states. For instance: loading plugins at runtime (dlls are not adquate for this purpose as they don't allow access to objects unless you use COM); streaming in and creating objects etc. esp. if you're using an OODBMS; any form of data driven application is extremly difficult to construct without this facility. Having the ability to create instances dynamically adds an extra dimension of flexibility to your software at NO extra cost if the feature is support by the language. I can never understand why the C++ community cannot see this - instead they bang on about how you don't need it. Why does the C++ community defend this position when they could be petitioning for this feature to be added? If the facility is there you are not compelled to use it, but with out it all other options are kludges and workarounds (IMHO). An OO language should support the ability to create objects anonimously. When I used to use C++ the lack of this feature caused me no end of problems, it was one of the main reasons why I ditched it. Factories are NOT the answer, as adding new classes to the app means making changes to the factory. Factories are not orthogonal. And I didn't say D was a scripting language and non of the example languages I cited were scripting languages either. It is possible to have this feature in an efficent compiled language with no cost to runtime performance; esp. in garbage collected language because the gc is going to take up more time then any extra runtime info will do. I'm not here to start a language war - I just want to understand why the C++ community does think this is an important feature, esp when it has every other feature under the sun crammed in there? And why D, as an improvement to C++ (which it certainly looks likes), hasn't added this feature either. Cheers Barry Carr Ixian Software Components Ltd
Dec 28 2003
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Ok, I'll bite, being predominantly a C++ person.

I am prepared to be compelled, so please supply a compelling example.

:)


-- 
Matthew Wilson

STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"If I'm curt with you it's because time is a factor. I think fast, I talk
fast, and I need you guys to act fast" -- Mr Wolf

----------------------------------------------------------------------------
---

"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns945FD4AE1AF7Fbarrycarrixiansoftwa 63.105.9.61...
 davepermen <davepermen_member pathlink.com> wrote in
 news:bsmu5g$1m96$1 digitaldaemon.com:

 dunno why this should be vital at all.. D is not a scripting language,
 and not written in runtime.. why should it be able to create objects
 of unknown type at runtime? there are simply no unkown types anymore
 at runtime.

 and creating a factory in D is ridiculous easy.. so no problem.

It is vital because an application should be a network of autonomous objects able to react to new situations (within reason) and work with derived classes without any trouble - as Liskov states. For instance: loading plugins at runtime (dlls are not adquate for this purpose as they don't allow access to objects unless you use COM); streaming in and creating objects etc. esp. if you're using an OODBMS; any form of data driven application is extremly difficult to construct without this facility. Having the ability to create instances dynamically adds an extra dimension of flexibility to your software at NO extra cost if the feature is support by the language. I can never understand why the C++ community cannot see this - instead they bang on about how you don't need it. Why does the C++ community defend this position when they could be petitioning for this feature to be added? If the facility is there you are not compelled to use it, but with out it all other options are kludges and workarounds (IMHO). An OO language should support the ability to create objects anonimously. When I used to use C++ the lack of this feature caused me no end of problems, it was one of the main reasons why I ditched it. Factories are NOT the answer, as adding new classes to the app means making changes to the factory. Factories are not orthogonal. And I didn't say D was a scripting language and non of the example languages I cited were scripting languages either. It is possible to have this feature in an efficent compiled language with no cost to runtime performance; esp. in garbage collected language because the gc is going to take up more time then any extra runtime info will do. I'm not here to start a language war - I just want to understand why the C++ community does think this is an important feature, esp when it has every other feature under the sun crammed in there? And why D, as an improvement to C++ (which it certainly looks likes), hasn't added this feature either. Cheers Barry Carr Ixian Software Components Ltd

Dec 28 2003
prev sibling next sibling parent "Charles" <sanders-consulting comcast.net> writes:
I've never had a problem with it, then again I've never used it, can you
give an example in a compiled language that has this ability ( reflection
its called ? ).  I must say it looks very cool , though I'm not sure how a
'compiled' language would implement it.

C

"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns945FD4AE1AF7Fbarrycarrixiansoftwa 63.105.9.61...
 davepermen <davepermen_member pathlink.com> wrote in
 news:bsmu5g$1m96$1 digitaldaemon.com:

 dunno why this should be vital at all.. D is not a scripting language,
 and not written in runtime.. why should it be able to create objects
 of unknown type at runtime? there are simply no unkown types anymore
 at runtime.

 and creating a factory in D is ridiculous easy.. so no problem.

It is vital because an application should be a network of autonomous objects able to react to new situations (within reason) and work with derived classes without any trouble - as Liskov states. For instance: loading plugins at runtime (dlls are not adquate for this purpose as they don't allow access to objects unless you use COM); streaming in and creating objects etc. esp. if you're using an OODBMS; any form of data driven application is extremly difficult to construct without this facility. Having the ability to create instances dynamically adds an extra dimension of flexibility to your software at NO extra cost if the feature is support by the language. I can never understand why the C++ community cannot see this - instead they bang on about how you don't need it. Why does the C++ community defend this position when they could be petitioning for this feature to be added? If the facility is there you are not compelled to use it, but with out it all other options are kludges and workarounds (IMHO). An OO language should support the ability to create objects anonimously. When I used to use C++ the lack of this feature caused me no end of problems, it was one of the main reasons why I ditched it. Factories are NOT the answer, as adding new classes to the app means making changes to the factory. Factories are not orthogonal. And I didn't say D was a scripting language and non of the example languages I cited were scripting languages either. It is possible to have this feature in an efficent compiled language with no cost to runtime performance; esp. in garbage collected language because the gc is going to take up more time then any extra runtime info will do. I'm not here to start a language war - I just want to understand why the C++ community does think this is an important feature, esp when it has every other feature under the sun crammed in there? And why D, as an improvement to C++ (which it certainly looks likes), hasn't added this feature either. Cheers Barry Carr Ixian Software Components Ltd

Dec 28 2003
prev sibling next sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Barry Carr wrote:

davepermen <davepermen_member pathlink.com> wrote in
news:bsmu5g$1m96$1 digitaldaemon.com: 

  

dunno why this should be vital at all.. D is not a scripting language,
and not written in runtime.. why should it be able to create objects
of unknown type at runtime? there are simply no unkown types anymore
at runtime. 

and creating a factory in D is ridiculous easy.. so no problem.
    

It is vital because an application should be a network of autonomous objects able to react to new situations (within reason) and work with derived classes without any trouble - as Liskov states. For instance: loading plugins at runtime (dlls are not adquate for this purpose as they don't allow access to objects unless you use COM); streaming in and creating objects etc. esp. if you're using an OODBMS; any form of data driven application is extremly difficult to construct without this facility. Having the ability to create instances dynamically adds an extra dimension of flexibility to your software at NO extra cost if the feature is support by the language. I can never understand why the C++ community cannot see this - instead they bang on about how you don't need it. Why does the C++ community defend this position when they could be petitioning for this feature to be added? If the facility is there you are not compelled to use it, but with out it all other options are kludges and workarounds (IMHO). An OO language should support the ability to create objects anonimously. When I used to use C++ the lack of this feature caused me no end of problems, it was one of the main reasons why I ditched it. Factories are NOT the answer, as adding new classes to the app means making changes to the factory. Factories are not orthogonal. And I didn't say D was a scripting language and non of the example languages I cited were scripting languages either. It is possible to have this feature in an efficent compiled language with no cost to runtime performance; esp. in garbage collected language because the gc is going to take up more time then any extra runtime info will do. I'm not here to start a language war - I just want to understand why the C++ community does think this is an important feature, esp when it has every other feature under the sun crammed in there? And why D, as an improvement to C++ (which it certainly looks likes), hasn't added this feature either. Cheers Barry Carr Ixian Software Components Ltd

I would like a feature like this in D. I made a game engine last year in C++ that would automaticly detect new objects and make them available to the editor and scripting engines. For example, if I wanted to make a new type of weapon, I'd simply derive the weapons class and fill out all the weapons particular info. It would be compiled as a DLL, and the program would automaticly detect it and make the weapon available to the editor. Then you'd be able to place the weapon in a shop, somewhere in the world or in one of the creatures (players and monsters). It was vary useful as you didn't have to touch the engine at all and made things easy to maintain. Users could easily customise the game into anything they wanted without touching the engine. The workaround required in C++ to do this was more effort then I would have hoped for. Is that what your talking about? Anderson
Dec 28 2003
next sibling parent reply Barry Carr <barrycarr ixian-software.com> writes:
J Anderson <REMOVEanderson badmama.com.au> wrote in
news:bsok83$16s2$1 digitaldaemon.com: 
 I would like a feature like this in D. I made a game engine 

 in C++ that would automaticly detect new objects and make 

 available to the editor and scripting engines. For example, 

 wanted to make a new type of weapon, I'd simply derive the 

 class and fill out all the weapons particular info. It would 

 compiled as a DLL, and the program would automaticly detect 

 make the weapon available to the editor. Then you'd be able 

 the weapon in a shop, somewhere in the world or in one of the
 creatures (players and monsters).  It was vary useful as you 

 have to touch the engine at all and made things easy to 

 Users could easily customise the game into anything they 

 without touching the engine. 
 
 The workaround required in C++ to do this was more effort 

 have hoped for.
 
 Is that what your talking about?
 
 Anderson

That is exactly what I am talking about. Cheers Barry Carr Ixian Software Components Ltd
Dec 29 2003
parent J Anderson <REMOVEanderson badmama.com.au> writes:
inline

Barry Carr wrote:

J Anderson <REMOVEanderson badmama.com.au> wrote in
news:bsok83$16s2$1 digitaldaemon.com: 
  

I would like a feature like this in D. I made a game engine 
    

in C++ that would automaticly detect new objects and make 
    

available to the editor and scripting engines. For example, 
    

wanted to make a new type of weapon, I'd simply derive the 
    

class and fill out all the weapons particular info. It would 
    

compiled as a DLL, and the program would automaticly detect 
    

make the weapon available to the editor. Then you'd be able 
    

the weapon in a shop, somewhere in the world or in one of the
creatures (players and monsters).  It was vary useful as you 
    

have to touch the engine at all and made things easy to 
    

Users could easily customise the game into anything they 
    

without touching the engine. 

The workaround required in C++ to do this was more effort 
    

have hoped for.

Is that what your talking about?

Anderson
    

That is exactly what I am talking about. Cheers Barry Carr Ixian Software Components Ltd

I should probably add that there was support for dynamic methods and properties, but that was sent through fixed methods (ie setProperty(int index, type value), type getProperty(int index), char* getPropertyName(int index), ect...). That way if some third party added a new class and you wanted to use some particular method unknown to the engine, you could still use it from your plugin. However, it would be nice if this was directly supported, so you could add methods remotely and detect them using dynamic reflection (or RTTI). -Anderson
Dec 29 2003
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bsok83$16s2$1 digitaldaemon.com>, J Anderson says...
I would like a feature like this in D. I made a game engine last year in 

the editor and scripting engines. For example, if I wanted to make a new type of weapon, I'd simply derive the weapons class and fill out all the weapons particular info. It would be compiled as a DLL, and the program would automaticly detect it and make the weapon available to the editor. Then you'd be able to place the weapon in a shop, somewhere in the world or in one of the creatures (players and monsters). It was vary useful as you didn't have to touch the engine at all and made things easy to maintain. Users could easily customise the game into anything they wanted without touching the engine. The workaround required in C++ to do this was more effort then I would have hoped for.

Is this what Mark Brudnak suggested on "3) Native support for plugin modules" D/19555 if so Walter said: "That seems like it would be a library feature. Would you care to write one?" and Matthew Wilson added "Most definitely" to the first part, not that he cares to write one ;) So how to we go about to do that? leds could use a pluggin system... (nothing new there but leds is at http://leds.sourceforge.net ) Ant
Dec 29 2003
parent "Mark Brudnak" <malibrud provide.net> writes:
"Ant" <Ant_member pathlink.com> wrote

<snip>

 Is this what Mark Brudnak suggested on
 "3) Native support for plugin modules"  
 D/19555

Basically, yes. <snip>
Dec 30 2003
prev sibling next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
It is vital because an application should be a network of autonomous 
objects able to react to new situations (within reason) and work with 
derived classes without any trouble - as Liskov states. For instance: 
loading plugins at runtime (dlls are not adquate for this purpose as they 
don't allow access to objects unless you use COM); streaming in and 
creating objects etc. esp. if you're using an OODBMS; any form of data 
driven application is extremly difficult to construct without this 
facility. Having the ability to create instances dynamically adds an 
extra dimension of flexibility to your software at NO extra cost if the 
feature is support by the language. 

sounds so poethic. but is rather nonsence imho. i had never problems adding objects with dll's and all. you "think" too much oo. in the end, its all just binary code to execute. creating objects is just calling a function doing that. creating them by name only needs a factory wich can get runtime edited. and that both is very doable and nothing fancy. (but your topic is not really about that..)
I can never understand why the C++ community cannot see this - instead 
they bang on about how you don't need it. Why does the C++ community  
defend this position when they could be petitioning for this feature to 
be added? If the facility is there you are not compelled to use it, but 
with out it all other options are kludges and workarounds (IMHO). An OO 
language should support the ability to create objects anonimously. 

why we don't see it? because there is not yet a good example showing us that we DO need it. there isn't much use in what you described (but thats not what you want, as it looks like..)
When I used to use C++ the lack of this feature caused me no end of 
problems, it was one of the main reasons why I ditched it. Factories are 
NOT the answer, as adding new classes to the app means making changes to 
the factory. Factories are not orthogonal.

what problems?
And I didn't say D was a scripting language and non of the example 
languages I cited were scripting languages either. It is possible to have 
this feature in an efficent compiled language with no cost to runtime 
performance; esp. in garbage collected language because the gc is going 
to take up more time then any extra runtime info will do.

if you want at runtime instantiation of at compile time known objects (and compile time can be splitted if you create dll's for example), then all you need is a method to add to a global factory. that is simple doable, there is no problem with that. if you DONT want that, you NEED some sort of runtime compilation, a.k.a. SCRIPTING. and you know what? D (or should i say DMD?) is capable of doing that. redistributing dmd lets you runtime generate new dll's wich you can load (and register your new objects with complete new behaviour in the factory:D) tested, and worked so far so good. issues with the gc exist, yes..
I'm not here to start a language war - I just want to understand why the 
C++ community does think this is an important feature, esp when it has 
every other feature under the sun crammed in there? And why D, as an 
improvement to C++ (which it certainly looks likes), hasn't added this 
feature either.

show us its a needed feature.. show us your purpose of it. show us your use of it. what do you think you want to use it for? we simply don't see it. i'd like to see it, though. but i see nothing special in it, nor anything that useful in it. i can run later-added code. oo is just a paradigm. so yes, i can run later-added oo-code, too. and you do see that all the languages that have it run in virtual machines? they are actually scripted then. dunno if you see what you really request. because its not juse about Object createObject(char[] name); if it would be that, easy. its not that. you want scripting (wether you call it that, or not. you want runtime compilation). oh, and, COM works great.. just to say that. and finally that statement again:
It is possible to have 
this feature in an efficent compiled language with no cost to runtime 
performance; esp. in garbage collected language because the gc is going 
to take up more time then any extra runtime info will do.

show us how. don't request, but propose. and you don't try to diss the gc, do you? i hope not. because then you're very wrong.. no war intended. just... a battle:D greetings, davepermen
Dec 28 2003
parent reply Barry Carr <barrycarr ixian-software.com> writes:
Hi Dave, Antti

It is vital because an application should be a network of autonomous 
objects able to react to new situations (within reason) and work with 
derived classes without any trouble - as Liskov states. For instance: 
loading plugins at runtime (dlls are not adquate for this purpose as
they don't allow access to objects unless you use COM); streaming in
and creating objects etc. esp. if you're using an OODBMS; any form of
data driven application is extremly difficult to construct without
this facility. Having the ability to create instances dynamically adds
an extra dimension of flexibility to your software at NO extra cost if
the feature is support by the language. 

sounds so poethic. but is rather nonsence imho. i had never problems adding objects with dll's and all. you "think" too much oo. in the end, its all just binary code to execute. creating objects is just calling a function doing that. creating them by name only needs a factory wich can get runtime edited.

Thats the first time I ever heard it to be a bad thing to be too "OO". Alan Kay (the creator of Smalltalk) was right when he said (more or less): "I invented the term 'Object Oriented' and C++ wasn't what I had in mind". In my not so humble opinion, procedural code is degenerate, and closed for extension. How can being too "OO" be a bad thing?
 and that both is very doable and nothing fancy. (but your topic is not
 really about that..)
 
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community  
defend this position when they could be petitioning for this feature
to be added? If the facility is there you are not compelled to use it,
but with out it all other options are kludges and workarounds (IMHO).
An OO language should support the ability to create objects
anonimously. 

why we don't see it? because there is not yet a good example showing us that we DO need it. there isn't much use in what you described (but thats not what you want, as it looks like..)

Here are two examples for then need to be able to create object of unknown type at runtime: 1. Delphi and C++ Builder need and use this facility when creating forms and dialogs at runtime (amongst other objects like DB connections). The "description" of the form and its consituent components are stored as a resource within the .exe. The runtime streams in the resource at runtime to (re)create the form. It is not possible to us a factory in this situation as the runtime will need to create the components provided out of the box along with 3rd party component and any user created components that may be being used - class details a factory could never know. BTW, C++ Builder relies on compiler extensions and the Delphi runtime to make this work for C++ Builder apps. 2. Several years ago I wrote an accounts package for the Legal sector in England (Scottish law is different). A legal accounts package is much the same as any double entry book keeping system, except that certain monies have to be seen to be kept seperate to stop fraud. To cut a long story short, I tried to make this application as dynamic as possible and I acheived this by making the app data-driven where possible. To this end, most of the rules about where and how to post money were held in data- table. Amongst this data was the name of class that represented the form needed to get the data from the user. Where specialised posting instructions were needed I employed the strategy pattern, the strategy classes needed for a transaction were listed in a data-table and created and iterated through to complete the task. The advantage of this approach was that I (we) could add transaction types with minium effort and in one place (orthoganality) knowing it would work. It meant that one point in the code could create the classes needed to complete a transaction and still work as more transactions types were added to the application or extended.
When I used to use C++ the lack of this feature caused me no end of 
problems, it was one of the main reasons why I ditched it. Factories
are NOT the answer, as adding new classes to the app means making
changes to the factory. Factories are not orthogonal.

what problems?

All the examples I've seen of factories in C++, and I've looked at a few of them like Scott Meyer's in Effective C++ and Bjarne's in the wave book, and they are all closed. You have to keep coming back to them as you add more classes to your app - this means that they are never stable as they are always open to change. Now, its been a while since I've checked this out, things may have moved on since them. Can you point me to, or show me a contempory factory implementation?
And I didn't say D was a scripting language and non of the example 
languages I cited were scripting languages either. It is possible to
have this feature in an efficent compiled language with no cost to
runtime performance; esp. in garbage collected language because the gc
is going to take up more time then any extra runtime info will do.

if you want at runtime instantiation of at compile time known objects (and compile time can be splitted if you create dll's for example), then all you need is a method to add to a global factory. that is simple doable, there is no problem with that.

But the whole point is that you DON'T know at runtime what a class is. A class could have been added after the main application was compiled and shipped.
 
 if you DONT want that, you NEED some sort of runtime compilation,
 a.k.a. SCRIPTING. and you know what? D (or should i say DMD?) is
 capable of doing that. redistributing dmd lets you runtime generate
 new dll's wich you can load (and register your new objects with
 complete new behaviour in the factory:D)

I am not talking about runtime compilation and you don't need runtime compilation, except on very rare occasions. If I wanted apps that could write themselves I'd use Lisp, Scheme or Smalltalk. I'm talking about not trying to second guess what I will need to create at runtime and allow some room for future extensions. Fine, if DMD will allow dynamic compilation then you show me an example of how you do this and why you would need it. (BTW, .NET will do this too, via the emit facility).
 
 tested, and worked so far so good. issues with the gc exist, yes..
 
I'm not here to start a language war - I just want to understand why
the C++ community does think this is an important feature, esp when it
has every other feature under the sun crammed in there? And why D, as
an improvement to C++ (which it certainly looks likes), hasn't added
this feature either.

show us its a needed feature.. show us your purpose of it. show us your use of it. what do you think you want to use it for? we simply don't see it. i'd like to see it, though. but i see nothing special in it, nor anything that useful in it. i can run later-added code. oo is just a paradigm. so yes, i can run later-added oo-code, too.

me examples of how you can do it without this feature, 'cos I'd love to know.
 and you do see that all the languages that have it run in virtual
 machines? they are actually scripted then. 

Sorry, I'm not really following this. Are you saying that all languages with a VM are scripting languages?
 dunno if you see what you
 really request. because its not juse about
 
 Object createObject(char[] name);
 
 if it would be that, easy. its not that. you want scripting (wether
 you call it that, or not. you want runtime compilation).

I think you are missing the point here
 oh, and, COM works great.. just to say that.

And .NET works even better, Although it galls me to say it.
 
 
 
 
 and finally that statement again:
 
It is possible to have 
this feature in an efficent compiled language with no cost to runtime 
performance; esp. in garbage collected language because the gc is
going to take up more time then any extra runtime info will do.

show us how. don't request, but propose.

Delphi is a perfect example. It is fast and efficent language that is truly compiled. And made more powerful for having this feature of being able to anonimously create objects at runtime. In fact Delphi and C++ Bulder share the same compiler, they just have different front-end parsers. To answer Antti question from another posting. Delphi carries some runtime information for a class. Delphi has an extra visibility option called Published - this has the same symantics as Public but it tells the compiler to generate RTTI for all definitions declared in this section. Delphi uses this RTTI to display and edit properties in its object inspector, part of the forms designer. The extra RTTI informtion is stream out to disk between desing session and compiled into that app as resource. However, you don't need to have Published members in your class to be able to create classes anonimously at runtime. Delphi has a data type called a class reference that will will hold a class, a class reference is also compatible with any of its decendants classes. Essenstially what this means is that Delphi has some runtime understanding of the classes in an app. They are not as Bertram Meyer says (again, more or less): "A Compile time notion of a runtime entity" as a Delphi application has some awareness of the classes it comprises of and use that information if needed. In all other respects, Delphi is as static as C++. Hopefully this brief and contrived example will illustrate how class references work: type TMyClass = class ... public constructor create; virtual; destructor destroy; override; end; TMyClassReference = class of TMyClass // Declare Class refence type TMyDerivedClass = class TMyClass ... public constructor create; override; destructor destroy; override; end; ... var ClassRef : TMyClassReference; // Class ref var myClass : TMyClass; begin ClassRef := TMyDerivedClass; myClass := ClassRef.create; /* As constructor is virtual, the correct constructor is called and myClass will hold a reference to an instance of TMyDerivedClass. The line above it equivallent to this line below. As there are ways of "calculating" the value of class reference it is possible to therefore dynamically create an instance without knowing its class at runtime */ myClass := TMyDerivedClass.create; end; And BTW, I'm not trying to say that Delphi is better than C++ or D for that matter.
 and you don't try to diss the gc, do you? i hope not. because then
 you're very wrong..
 

and nessesary thing. I was merely pointing out that any overhead incured by having extra runtime info included with a class would be far outweighed by sweeps of the GC, no matter how effiecent the GC was.
 
 
 no war intended. just... a battle:D
 
 greetings,
 davepermen

Cheers Barry Carr Ixian Software Components Ltd.
Dec 29 2003
next sibling parent Andy Friesen <andy ikagames.com> writes:
Barry Carr wrote:
  1. Delphi and C++ Builder need and use this facility when creating forms    
 and dialogs at runtime (amongst other objects like DB connections). The 
 "description" of the form and its consituent components are stored as a 
 resource within the .exe. The runtime streams in the resource at runtime 
 to (re)create the form. It is not possible to us a factory in this 
 situation as the runtime will need to create the components provided out 
 of the box along with 3rd party component and any user created components 
 that may be being used - class details a factory could never know. BTW, 
 C++ Builder relies on compiler extensions and the Delphi runtime to make 
 this work for C++ Builder apps.

How about the pluggable factory pattern? That's what I use for situations like this. A three-line factory implementation per class and it's ready to go.
 Hopefully this brief and contrived example will illustrate 
 how class references work:
 
 type
   TMyClass = class
     ...
   public
     constructor create; virtual;
     destructor destroy; override;	
   end;
 
   TMyClassReference = class of TMyClass // Declare Class refence type
 
   TMyDerivedClass = class TMyClass
     ...
   public
     constructor create; override;
     destructor destroy; override;
   end;
 ...
 
 var
   ClassRef : TMyClassReference; // Class ref var
   myClass  : TMyClass; 
 
 begin
   ClassRef := TMyDerivedClass;
 
   myClass := ClassRef.create; 
   /* As constructor is virtual, the correct constructor is called and    
 myClass will hold a reference to an instance of TMyDerivedClass. The line 
 above it equivallent to this line below. As there are ways of 
 "calculating" the value of class reference it is possible to therefore 
 dynamically create an instance without knowing its class at runtime */
   myClass := TMyDerivedClass.create;
 end;

Interesting. Python allows the exact same thing, though it's merely emergent behaviour. (types are themselves objects, so you can deal with them as such) I don't think it would be very difficult to add this to D. ClassInfo would simply need to grow a create() or constructor() method that calls the constructor. -- andy
Dec 29 2003
prev sibling next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
and the battle goes on.. and gets rather big for this much too small textbox..

anyways.. lets go!

Thats the first time I ever heard it to be a bad thing to be too "OO". 
Alan Kay (the creator of Smalltalk) was right when he said (more or 
less): "I invented the term 'Object Oriented' and C++ wasn't what I had 
in mind". In my not so humble opinion, procedural code is degenerate, and 
closed for extension. How can being too "OO" be a bad thing?

if thats the first time you hear that, you have a lot to learn... very lot. algorithms are independent of objects, and they are the actual major part of every program. oo is just one paradigm you have to follow, or not, to code. it solves some tasks nice, others not at all. thats why we have c++, or D, wich allows for different paradigms.. (generics are hip today, thats why oo-only languages like c# and java now fake to implement it, too)
Here are two examples for then need to be able to create object of 
unknown type at runtime:

hm.. i'm interested to see them
 1. Delphi and C++ Builder need and use this facility when creating forms    
and dialogs at runtime (amongst other objects like DB connections). The 
"description" of the form and its consituent components are stored as a 
resource within the .exe. The runtime streams in the resource at runtime 
to (re)create the form. It is not possible to us a factory in this 
situation as the runtime will need to create the components provided out 
of the box along with 3rd party component and any user created components 
that may be being used - class details a factory could never know. BTW, 
C++ Builder relies on compiler extensions and the Delphi runtime to make 
this work for C++ Builder apps.

and.. i don't get it.. whats the use of it? what class details are needed at runtime? wich aren't there else? you code and compile. and it runs then with everything known yet. this worked even in c days. win32 is a c-api, and delphi/c++ builder in the end run on top of it. i don't really see what you gain from it. never had problems creating apps till now "the normal way". i'm interested, but i don't see really the added value. possibly a small demo app could help
 2. Several years ago I wrote an accounts package for the Legal sector in 
England (Scottish law is different). A legal accounts package is much the 
same as any double entry book keeping system, except that certain monies 
have to be seen to be kept seperate to stop fraud. To cut a long story 
short, I tried to make this application as dynamic as possible and I 
acheived this by making the app data-driven where possible. To this end, 
most of the rules about where and how to post money were held in data-
table. Amongst this data was the name of class that represented the form 
needed to get the data from the user. Where specialised posting 
instructions were needed I employed the strategy pattern, the strategy 
classes needed for a transaction were listed in a data-table and created 
and iterated through to complete the task. The advantage of this approach 
was that I (we) could add transaction types with minium effort and in one 
place (orthoganality) knowing it would work. It meant that one point in 
the code could create the classes needed to complete a transaction and 
still work as more transactions types were added to the application or 
extended.

so your app was never really finished, and just needed to be partially rewritable/extendable later.. so it is, in that case, scripting. for this, i'd use some scripting language. but i don't say some capabilities to do that directly in D would not be nice:D
All the examples I've seen of factories in C++, and I've looked at a few 
of them like Scott Meyer's in Effective C++ and Bjarne's in the wave 
book, and they are all closed. You have to keep coming back to them as 
you add more classes to your app - this means that they are never stable 
as they are always open to change. Now, its been a while since I've 
checked this out, things may have moved on since them. Can you point me 
to, or show me a contempory factory implementation?

uhm? you can load dll's, can't you? if you can, then you have it dynamic. just loop trough all existing dll's, request the function you need, and share the factory to it.. it will register itself. with nice template facilities hidden, this is about one statement in the Dll code (or two.. unregistering on unload? wait no, thats RAII for:D), and its one loop + one statement (the factory instantiation) in the executable. thats how i did plugins all the time. worked great so far. and is very simple.. there is the fact that you only get interface access (com like) to your objects you create. you can't query its methods and all (except you implement it to be queriable.. every compiler creates the "reflection" info for you if you need it, even in c++.. but its complicated to work with.. mangled c++ names aren't fun:D).. but then again.. what for? how can your static compiled app call a method on an object it doesn't know the name of the method nor the calling rule, nor the parameters, nor their types.. how can your app call it? it can't. it _HAS_ to know it. and then, why don't you just use a real interface to it?
But the whole point is that you DON'T know at runtime what a class is. A 
class could have been added after the main application was compiled and 
shipped.

if you don't know it, how can your app use it? the part of your app that USES it HAS to know it. except its the USER itself wich uses it. and then, he sort of scripts realtime.
I am not talking about runtime compilation and you don't need runtime 
compilation, except on very rare occasions. If I wanted apps that could 
write themselves I'd use Lisp, Scheme or Smalltalk. I'm talking about not 
trying to second guess what I will need to create at runtime and allow 
some room for future extensions.

then what DO you need? if you only detect your classes at runtime, but your code is compile time, how shall your code use it?
Fine, if DMD will allow dynamic compilation then you show me an example 
of how you do this and why you would need it. (BTW, .NET will do this 
too, via the emit facility). 

i've read the "holy reflection, look at .NET, with emit and all" and read the example. this example was simple bullshit, sorry. in the end, all the stuff generated at runtime WAS KNOWN AT COMPILE TIME. why not simply... CODE IT?!. if you have scripting, you laught about reflection.. and if you have both scripting, and compile time coded, and all the runtime reflection, and all, in D, then you don't give a fuzz about reflection. and you know what? i DO have all that.. perfect for coding "own games with given game engine". the trick is to know your tools.. JIT with D (with DMD) is very possible.. compile only at the moment you know what you need..
My two examples above should show you why you need this feature. You show 
me examples of how you can do it without this feature, 'cos I'd love to 
know.

sorry.. i don't see the examples really.. can't imagine the problem 1 just from the text, and problem 2 can be done with my "dynamic plugin facility you've never seen before (a.k.a. dll loader:D)", or if needed, with "JIT D"
 and you do see that all the languages that have it run in virtual
 machines? they are actually scripted then. 

Sorry, I'm not really following this. Are you saying that all languages with a VM are scripting languages?

scripted, JIT, what ever.. its all the same end. JIT is just a bit before the moment scripting languages get compiled.. just a bit:D all languages with VM can do runtime compilations, and have the full power of the compile time available at runtime, if needed. (well, the asm part:D). and yes, .NET and the java virtual machine are sort of script engines... very powerful ones, though. even lua does jit today.. and this is a "well known scripting language".. its just smaller
I think you are missing the point here

i said thats not the point, but wanted to clarify i don't see more in your request, so you missed to show your real problem
And .NET works even better, Although it galls me to say it.

Delphi is a perfect example. It is fast and efficent language that is 
truly compiled. And made more powerful for having this feature of being 
able to anonimously create objects at runtime. In fact Delphi and C++ 
Bulder share the same compiler, they just have different front-end 
parsers. 

To answer Antti question from another posting. Delphi carries some 
runtime information for a class. Delphi has an extra visibility option 
called Published - this has the same symantics as Public but it tells the 
compiler to generate RTTI for all definitions declared in this section. 
Delphi uses this RTTI to display and edit properties in its object 
inspector, part of the forms designer. The extra RTTI informtion is 
stream out to disk between desing session and compiled into that app as 
resource. However, you don't need to have Published members in your class 
to be able to create classes anonimously at runtime. Delphi has a data 
type called a class reference that will will hold a class, a class 
reference is also compatible with any of its decendants classes. 
Essenstially what this means is that Delphi has some runtime 
understanding of the classes in an app. They are not as Bertram Meyer 
says (again, more or less): "A Compile time notion of a runtime entity" 
as a Delphi application has some awareness of the classes it comprises of 
and use that information if needed. In all other respects, Delphi is as 
static as C++. Hopefully this brief and contrived example will illustrate 
how class references work:

type
  TMyClass = class
    ...
  public
    constructor create; virtual;
    destructor destroy; override;	
  end;

  TMyClassReference = class of TMyClass // Declare Class refence type

  TMyDerivedClass = class TMyClass
    ...
  public
    constructor create; override;
    destructor destroy; override;
  end;
...

var
  ClassRef : TMyClassReference; // Class ref var
  myClass  : TMyClass; 

begin
  ClassRef := TMyDerivedClass;

  myClass := ClassRef.create; 
  /* As constructor is virtual, the correct constructor is called and    
myClass will hold a reference to an instance of TMyDerivedClass. The line 
above it equivallent to this line below. As there are ways of 
"calculating" the value of class reference it is possible to therefore 
dynamically create an instance without knowing its class at runtime */
  myClass := TMyDerivedClass.create;
end;

well.. and .. what now? you a) know how to use your class, and then its just an implicit factory.. syntax sugar at best b) you don't know how to use your class.. so you sit around with an instance called myClass, and .. how do you want to use it now at compile time? without knowing anything about it.. if i create an object of an unknown type, what shall i do with it? if its a window, i can maximize it.. if its mario, i can give it a mushroom, if its a virus, i can format my hd. but how should i know? i'm programming and compiling at COMPILE TIME. at least I should know how to use it then, not? explain me that..
And BTW, I'm not trying to say that Delphi is better than C++ or D for 
that matter.

hehe.. couldn't resist:D
 and you don't try to diss the gc, do you? i hope not. because then
 you're very wrong..
 

and nessesary thing. I was merely pointing out that any overhead incured by having extra runtime info included with a class would be far outweighed by sweeps of the GC, no matter how effiecent the GC was.

in short: what use has a runtime created unknown class if you can only use it before compile time? with a scripting system, you can then use it at runtime. without, you simply have no clue. if you _HAVE_ at compiletime a clue on how you want to use your class, then you don't have an unknown class type at runtime eighter. possibly the creation of an object of your type failed (because the created class has another type, unrelated to your requested one), and then its simply an error. but that doesn't need complex reflection. and actually, its a very stupid situation anyways.. i'd never use a facility that creates objects for me where i'm not sure if they are the objects i need.. as if CreateWindow would return a FILE* occasionally. explain me what i miss here.. or what you believe you have wich you actually don't need.. dunno:D runtime scripting is cool and useful. but anything between, dunno.. greetings, davepermen
Dec 30 2003
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bsrlgc$2kcv$1 digitaldaemon.com>, davepermen says...
and the battle goes on.. and gets rather big for this much too small textbox..

One of us didn't understand the issue. (it's probably me, don't worry;) I thought it was about extending/adapting an application through external and independent modules that would conform to some rules - let's say trought an implementation of an interface. The example of weapons and mosters is easy to understand. Another example is an IDE where all non core functionalities are provided externally (CVS access, code browser, what ever) Another example is an OS kernel that would load specific modules for different tasks/environments. how is D able to do that? (of course we can always start two processes with an ad-hoc "smart pluggin abstraction" layer between them and send messages across. But I guess that what J Anderson calls a work around) BTW what were Walter and Matthew talking about when replying to Mark's post? Maybe we can extend this concept and the core application becomes just the pluggin loader... I bet I could get a pattent on that ;) how is D able to do that? Ant
Dec 30 2003
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bss7ll$ded$1 digitaldaemon.com...
 In article <bsrlgc$2kcv$1 digitaldaemon.com>, davepermen says...
and the battle goes on.. and gets rather big for this much too small


 One of us didn't understand the issue.
 (it's probably me, don't worry;)

 I thought it was about extending/adapting an application
 through external and independent modules that would conform
 to some rules - let's say trought an implementation of an interface.
 The example of weapons and mosters is easy to understand.
 Another example is an IDE where all non core functionalities
 are provided externally (CVS access, code browser, what ever)
 Another example is an OS kernel that would load specific modules
 for different tasks/environments.

 how is D able to do that?
 (of course we can always start two processes
 with an ad-hoc "smart pluggin abstraction" layer between them
 and send messages across. But I guess that what
 J Anderson calls a work around)

 BTW what were Walter and Matthew talking about when replying to Mark's

Can't remember the post or the reply. I was probably talking out of my arse, as usual. Can you remind?
Jan 29 2004
prev sibling next sibling parent reply Barry Carr <barrycarr ixian-software.com> writes:
Dave,

I'm going to cut through all this BS. My position is this:

C++ is too static. There are times (and I've cited two good examples) 
where  you need some runtime dynamicism to reduce coding, improve 
reliability and allow an application to adapt to new *SOME* new 
situations without falling flat on its face. This is not scripting, IMO, 
but the ability keep an application "Closed for modification, but open 
for extension" as Robert Martin states. Factories always require 
modification and thus break this rule. If you know different then show me 
an example factory as proof. If DMD has similar facilities or better, I'd 
like to see these too. 

I have work long enough with languages with dynamic facilities to know 
that a completely static languages are very restrictive and don't 
facilitate eligant, workable solutions - you end up having to code round 
situations to half get what you want. In my experience, the more dynamic 
a language is the more power the developer has at his or her disposal and 
the quicker they can get the job done. There is big role for compile-time 
facilities such as templates or generics as these can improve runtime 
performance and type safety, but these are still closed solutions. 

Furthermore, there is no reason to use procedural code anymore - OO 
technologies provide a much richer way of modeling problems and provide 
robust, extensible solutions to them. Objects implement algorithms to 
provide these solutions, not the other way round. 

Virtual Machines are not uber-scripting languages, they are proper, 
complete languages in there own right and a realisation in the industry 
that a more dynamic runtime environment is required to provide timely, 
robust solutions. 

Now, if you don't agree with any of this, which you clearly don't - 
explain your counter arguments and cite examples.

And I still want to know what if D has any dynamic facilities.

Cheers

Barry Carr
Ixian Software Components Ltd.
Dec 30 2003
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
just a quick question before i go to bed:

my exe scans the folder for all .plugin files, wich are renamed .dll files, wich
get loaded, and each has a "describe" function in, wich returns name and
function pointer to a creator function of the type in there (wich is derived
from a base interface, a.k.a. IPlugin

then i can just code new plugins, compile as dll, and add to the folder of the
exe.. and voilą, the exe can create objects of it..

i've made that way "app wizards", wich could create different types of editors
(leds could use it for different project types, for example).

no need to change the factory in the exe at all. this is what i stated several
times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<




and about oo.. how does max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is a different part.. programming happens on different layers. oo is one. procedural is another. generic another. patterns fit onto a top layer above them. only if you know to use all, you are really good at creating reusable code, that is dynamic even while static compiled. every c++ programer knows this. only brainwashed java/.NET programmers still think you always have to create a class around a static method. do i really have to code that up? well then.. if i have time, tomorrow at work.. else.. next year:D or is that still too static? and you haven't answered my question: if you know the type at code time (or a base of it, like IPlugin), then you can code with it. but then you don't need runtime object creation of unknown type, factory is enough. if you don't know the type at code time, then how do you code with it? eighter with some script at runtime, or.. how? you haven't answered that basic question. wich is the whole "why do i want to create an object of unknown type?". i simply don't understand what i should be able to use it for? and sorry for being that ignorant btw.. i simply don't get it. and i want to get it. but i don't know how yet.. you have to help me.. some applications showing how it adds really would be useful. and vm's are simply basecode to run scripts. binary scripts, but still scripts.
Dec 30 2003
next sibling parent reply qw <qw_member pathlink.com> writes:
"why do i want to create an object of unknown type?".

Or, the object descends from TComponent. Being a TComponent, you can obtain a list of properties. You obtain the properties and it's types and show them in an object inspector. Congratulations, you have just built a GUI builder a-la-Delphi. In C++, you would have to register classes, register properties and types, etc. I other words, you would have to build the whole framework from scratch. Some parts may be easy, others are clearly not.
Dec 30 2003
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"qw" <qw_member pathlink.com> wrote in message
news:bst9qn$22k2$1 digitaldaemon.com...
"why do i want to create an object of unknown type?".

Or, the object descends from TComponent.

Then it's not unknown, is it? Or am I missing something
Being a TComponent, you can obtain a
 list of properties. You obtain the properties and it's types and show them

 object inspector. Congratulations, you have just built a GUI builder
 a-la-Delphi.
 In C++, you would have to register classes, register properties and types,

 I other words, you would have to build the whole framework from scratch.

 parts may be easy, others are clearly not.

Jan 29 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
"why do i want to create an object of unknown type?".

Or, the object descends from TComponent.

Then it's not unknown, is it? Or am I missing something

class MyClass { } class MyDerivedA : MyClass { } class MyDerivedB : MyClass { } .. int main () { MyClass foo; if (someCondition) foo = new MyDerivedA; else foo = new MyDerivedB; // OK, now tell me the type of foo. // you can't as it's not known. // OK you could using classinfo, but this is some kind of reflection, too return 0; }
Jan 30 2004
next sibling parent reply "davepermen" <davepermen hotmail.com> writes:
if you knew oo you would knew that this is exactly what oo is about: you get
a baseclass reference if you don't need more.

you know its a MyClass, or derived from it. so you know how to use it. do
you need more?

if so, just try to cast it to mroe..

MyDervidedA fooA = cast(MyDerivedA)foo;
if(fooA) {
    // hey, its a MyDerivedA, or a derived of MyDerivedA!!
}

but if you don't know the type you WANT it to be, you have no clue on how to
USE it in code. you know how to use MyClass, as well as MyDerivedA. so you
just cast to the one you expect it to be. if it is that (or derived from
it), you can use it as that.

but still, the main point is, you should not NEED that.

if you think you need it (and while you're 99% wrong then), you even can
check it. dynamic_cast in c++ works the same, and does the job as nice.

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvd9hr$2c9u$1 digitaldaemon.com...
"why do i want to create an object of unknown type?".

Or, the object descends from TComponent.

Then it's not unknown, is it? Or am I missing something

class MyClass { } class MyDerivedA : MyClass { } class MyDerivedB : MyClass { } .. int main () { MyClass foo; if (someCondition) foo = new MyDerivedA; else foo = new MyDerivedB; // OK, now tell me the type of foo. // you can't as it's not known. // OK you could using classinfo, but this is some kind of reflection, too return 0; }

Jan 30 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
In article <bvdhgs$2qm7$1 digitaldaemon.com>, davepermen says...
if you knew oo you would knew that this is exactly what oo is about: you get
a baseclass reference if you don't need more.

you know its a MyClass, or derived from it. so you know how to use it. do
you need more?

I just wanted to point out that you don't know the type without reflection. Of course you don't need too know it. That's what I like about OO.
Jan 30 2004
parent "davepermen" <davepermen hotmail.com> writes:
but what gain would you have with reflection? because without casting it to
a type you GUESS it is, you can not USE it.

i've looked at a lot of reflection examples in java, in c#, and they are
hell clumpsy, and doing it with real scripting languages (using java, c#, or
D itself!) is the much cleaner way.

and, as you said, normally, you don't need it. if you program in a nice way,
there is no need for it. oo or not oo. generic programming lets you code
with "signatures". a.k.a. you don't know the type, but you know you can call
a certain function of it. reflection could give you this runtime
signature-checking. this _could_ get useful, yes. but interfaces most the
time can handle this job as well..

signatures would be interesting anyways. sort of interfaces for individual
functions..

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvdiu6$2svb$1 digitaldaemon.com...
 In article <bvdhgs$2qm7$1 digitaldaemon.com>, davepermen says...
if you knew oo you would knew that this is exactly what oo is about: you


a baseclass reference if you don't need more.

you know its a MyClass, or derived from it. so you know how to use it. do
you need more?

I just wanted to point out that you don't know the type without

 course you don't need too know it. That's what I like about OO.

Jan 30 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
To me that seems a perfect example of interface-based programming. You know,
separating interface from implementation. That's a core OO concept, btw.

(Sorry for sarcasm, but your example does not serve your purpose)

"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bvd9hr$2c9u$1 digitaldaemon.com...
"why do i want to create an object of unknown type?".

Or, the object descends from TComponent.

Then it's not unknown, is it? Or am I missing something

class MyClass { } class MyDerivedA : MyClass { } class MyDerivedB : MyClass { } .. int main () { MyClass foo; if (someCondition) foo = new MyDerivedA; else foo = new MyDerivedB; // OK, now tell me the type of foo. // you can't as it's not known. // OK you could using classinfo, but this is some kind of reflection, too return 0; }

Jan 30 2004
prev sibling next sibling parent reply "Phill" <phill pacific.net.au> writes:
I am by no means a guru at programming, I am Sun Certified Java programmer
thats about all, Im not a
professional, Ive only done one contract, but even I
can grasp the concept of OO.
You said earlier that Barry had a lot to learn, I believe
that you are the one that has a lot to learn(about OO
anyway) and maybe listening is a great part of learning.

wow I cant believe that you can say this:
===========================
"how does

max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is
a
different part..

programming happens on different layers. oo is one. procedural is another.
"
===================
that statement can return the contents of the greater one of two of the
Objects data fields.
You use procedural inside Objects on their data fields....

Phill.

"He who asks is a fool for five minutes, but he who does not ask remains a
fool forever."

"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
 just a quick question before i go to bed:

 my exe scans the folder for all .plugin files, wich are renamed .dll

 get loaded, and each has a "describe" function in, wich returns name and
 function pointer to a creator function of the type in there (wich is

 from a base interface, a.k.a. IPlugin

 then i can just code new plugins, compile as dll, and add to the folder of

 exe.. and voilą, the exe can create objects of it..

 i've made that way "app wizards", wich could create different types of

 (leds could use it for different project types, for example).

 no need to change the factory in the exe at all. this is what i stated

 times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<




and about oo.. how does max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it

 different part..

 programming happens on different layers. oo is one. procedural is another.
 generic another. patterns fit onto a top layer above them.

 only if you know to use all, you are really good at creating reusable

 is dynamic even while static compiled. every c++ programer knows this.

 brainwashed java/.NET programmers still think you always have to create a

 around a static method.

 do i really have to code that up? well then.. if i have time, tomorrow at

 else.. next year:D


 or is that still too static?


 and you haven't answered my question:

 if you know the type at code time (or a base of it, like IPlugin), then

 code with it. but then you don't need runtime object creation of unknown

 factory is enough.
 if you don't know the type at code time, then how do you code with it?

 with some script at runtime, or.. how?
 you haven't answered that basic question. wich is the whole "why do i want

 create an object of unknown type?".
 i simply don't understand what i should be able to use it for?

 and sorry for being that ignorant btw.. i simply don't get it. and i want

 it. but i don't know how yet.. you have to help me.. some applications

 how it adds really would be useful.



 and vm's are simply basecode to run scripts. binary scripts, but still


Dec 30 2003
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
simple answer: the main 'problem' with oo is, you can map it to everywhere.

but just because it happens to work with objects, its not object oriented. in
java, simply "everything" is called objectoriented. a function/method still
isn't. oo is a design on how to structure your objects, parts of oo is about
inheritance, or, what IS an object. the other is about encapsulation, or what
does an object LOOK like.

sure, every algorithm processes data. there is no "ergo algorithms are object
oriented". max doesn't bother AT ALL about objects. it is a generic working
algorithm. works with everything. i don't call an int an object.. i primarily
call it a number..

its a way of thinking. oo-pure thinking is way too restricted. thats all. but
you _can_ of course call everything oo. you can as well call everything
procedural if you want, as in the end, hw only works procedural anyways. your
obj.func() is just a a func(obj_handle), so what?

oo helps a lot. other approaches can help in other situations even more.

(oh, and classes are not oo, but i guess you're well avare of that.. if not, you
definitely have to learn other languages than java.. immediately)

In article <bstcfk$26ic$1 digitaldaemon.com>, Phill says...
I am by no means a guru at programming, I am Sun Certified Java programmer
thats about all, Im not a
professional, Ive only done one contract, but even I
can grasp the concept of OO.
You said earlier that Barry had a lot to learn, I believe
that you are the one that has a lot to learn(about OO
anyway) and maybe listening is a great part of learning.

wow I cant believe that you can say this:
===========================
"how does

max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is
a
different part..

programming happens on different layers. oo is one. procedural is another.
"
===================
that statement can return the contents of the greater one of two of the
Objects data fields.
You use procedural inside Objects on their data fields....

Phill.

"He who asks is a fool for five minutes, but he who does not ask remains a
fool forever."

"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
 just a quick question before i go to bed:

 my exe scans the folder for all .plugin files, wich are renamed .dll

 get loaded, and each has a "describe" function in, wich returns name and
 function pointer to a creator function of the type in there (wich is

 from a base interface, a.k.a. IPlugin

 then i can just code new plugins, compile as dll, and add to the folder of

 exe.. and voilą, the exe can create objects of it..

 i've made that way "app wizards", wich could create different types of

 (leds could use it for different project types, for example).

 no need to change the factory in the exe at all. this is what i stated

 times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<




and about oo.. how does max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it

 different part..

 programming happens on different layers. oo is one. procedural is another.
 generic another. patterns fit onto a top layer above them.

 only if you know to use all, you are really good at creating reusable

 is dynamic even while static compiled. every c++ programer knows this.

 brainwashed java/.NET programmers still think you always have to create a

 around a static method.

 do i really have to code that up? well then.. if i have time, tomorrow at

 else.. next year:D


 or is that still too static?


 and you haven't answered my question:

 if you know the type at code time (or a base of it, like IPlugin), then

 code with it. but then you don't need runtime object creation of unknown

 factory is enough.
 if you don't know the type at code time, then how do you code with it?

 with some script at runtime, or.. how?
 you haven't answered that basic question. wich is the whole "why do i want

 create an object of unknown type?".
 i simply don't understand what i should be able to use it for?

 and sorry for being that ignorant btw.. i simply don't get it. and i want

 it. but i don't know how yet.. you have to help me.. some applications

 how it adds really would be useful.



 and vm's are simply basecode to run scripts. binary scripts, but still



Dec 30 2003
parent reply "Phill" <phill pacific.net.au> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bstmf8$2lfa$1 digitaldaemon.com...
 simple answer: the main 'problem' with oo is, you can map it to

 but just because it happens to work with objects, its not object oriented.

 java, simply "everything" is called objectoriented. a function/method

 isn't.

In Java methods are not called Objects. oo is a design on how to structure your objects, parts of oo is about
 inheritance, or, what IS an object. the other is about encapsulation, or

 does an object LOOK like.

my understanding of encapsulation is when a classes variables are made private and they have public get and set methods.
 sure, every algorithm processes data. there is no "ergo algorithms are

 oriented". max doesn't bother AT ALL about objects. it is a generic

 algorithm. works with everything. i don't call an int an object.. i

 call it a number..

I dont call variables Objects either. With max I meant if you used it inside an Object it has , I didnt mean that IT used Objects. I miss understood your meaning. I agree that Classes arent Objects, but Instantiated classes are Objects. And I would love to learn other languages and intend to eventually, D in fact, which is no doubt why I am here. Phill.
 its a way of thinking. oo-pure thinking is way too restricted. thats all.

 you _can_ of course call everything oo. you can as well call everything
 procedural if you want, as in the end, hw only works procedural anyways.

 obj.func() is just a a func(obj_handle), so what?

 oo helps a lot. other approaches can help in other situations even more.

 (oh, and classes are not oo, but i guess you're well avare of that.. if

 definitely have to learn other languages than java.. immediately)

 In article <bstcfk$26ic$1 digitaldaemon.com>, Phill says...
I am by no means a guru at programming, I am Sun Certified Java


thats about all, Im not a
professional, Ive only done one contract, but even I
can grasp the concept of OO.
You said earlier that Barry had a lot to learn, I believe
that you are the one that has a lot to learn(about OO
anyway) and maybe listening is a great part of learning.

wow I cant believe that you can say this:
===========================
"how does

max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it


a
different part..

programming happens on different layers. oo is one. procedural is


"
===================
that statement can return the contents of the greater one of two of the
Objects data fields.
You use procedural inside Objects on their data fields....

Phill.

"He who asks is a fool for five minutes, but he who does not ask remains


fool forever."

"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
 just a quick question before i go to bed:

 my exe scans the folder for all .plugin files, wich are renamed .dll

 get loaded, and each has a "describe" function in, wich returns name



 function pointer to a creator function of the type in there (wich is

 from a base interface, a.k.a. IPlugin

 then i can just code new plugins, compile as dll, and add to the folder



the
 exe.. and voilą, the exe can create objects of it..

 i've made that way "app wizards", wich could create different types of

 (leds could use it for different project types, for example).

 no need to change the factory in the exe at all. this is what i stated

 times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<




and about oo.. how does max(a,b) { return a > b ? a : b; } gain anything with oo? not at all.



is a
 different part..

 programming happens on different layers. oo is one. procedural is



 generic another. patterns fit onto a top layer above them.

 only if you know to use all, you are really good at creating reusable

 is dynamic even while static compiled. every c++ programer knows this.

 brainwashed java/.NET programmers still think you always have to create



class
 around a static method.

 do i really have to code that up? well then.. if i have time, tomorrow



work..
 else.. next year:D


 or is that still too static?


 and you haven't answered my question:

 if you know the type at code time (or a base of it, like IPlugin), then

 code with it. but then you don't need runtime object creation of



type,
 factory is enough.
 if you don't know the type at code time, then how do you code with it?

 with some script at runtime, or.. how?
 you haven't answered that basic question. wich is the whole "why do i



to
 create an object of unknown type?".
 i simply don't understand what i should be able to use it for?

 and sorry for being that ignorant btw.. i simply don't get it. and i



to get
 it. but i don't know how yet.. you have to help me.. some applications

 how it adds really would be useful.



 and vm's are simply basecode to run scripts. binary scripts, but still




Dec 31 2003
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
In Java methods are not  called Objects.

rather restricted.
my understanding of encapsulation is when a classes
variables are made private and they have public get and set methods.

usage.. you can't use private members, you have to use public methods. and get/set should be in as less as possible.. get/set is not really oo btw. your objects should have real methods instead of wrappers for the variables. methods that do something. as your object can do something.
I dont call variables Objects either.
With max I meant if you used it inside an Object it has , I didnt mean that
IT used Objects.
I miss understood your meaning.

that doesn't exist..) but it defines exactly the purpose of max. no mather if you use it with two objects, or something else.. thats generic programming.. its about designing algoritms and components that do certain tasks everywhere. no mather what object is in (container), or on what objects they work on (algorithms).. if objects at all..
I agree that Classes arent Objects, but Instantiated classes are Objects.
And I would love to learn other languages and intend to eventually,  D in
fact, which is no doubt why I
am here.

oriented.
Dec 31 2003
parent reply "Phill" <phill pacific.net.au> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsu539$9fh$1 digitaldaemon.com...
In Java methods are not  called Objects.


 rather restricted.

pain in the ass, and its a bit slower than some other languages.
 yes instances of a class are objects. still, that doesn't make it object
 oriented.

when you use these Objects to do tasks and make them Polymorphic then it is OO. Do you agree on that? Happy New Year! Phill.
Dec 31 2003
next sibling parent davepermen <davepermen_member pathlink.com> writes:
In article <bsvdi8$22ug$1 digitaldaemon.com>, Phill says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsu539$9fh$1 digitaldaemon.com...
In Java methods are not  called Objects.


 rather restricted.

pain in the ass, and its a bit slower than some other languages.

the java language is very restricted, a.k.a. has less possible paradigms to use to program with. it has less language features, and thats why. now they add generics to some extend, to "solve" some of the restrictions.. having shown the max function, you realise how bad java is at such tasks. the max has to be written for every type manually, and has to rely in some class as static method(-s) not really a powerful language if you want to do such a task.. in the same way, you can't write generic algorithms for all sort of tasks. like sorting, searching, managing, etc.. a sneak peak to <algorithm> in your favourite c++ compiler header set gives you an idea.. i'm not saying java doesn't work well in quite some situations. but you need much too much manual writing and hacking around in other situations..
 yes instances of a class are objects. still, that doesn't make it object
 oriented.

when you use these Objects to do tasks and make them Polymorphic then it is OO. Do you agree on that?

no. the one that created the object possibly made it oo, or not. oo is about how to design objects/object hirarchies to make them selfcontained. if you write a class that has some private members, and some public methods, and what ever you try to do with those public methods, what ever parameters you give in, how ever you copy the object around and all, it does NEVER NEVER NEVER get into an invalid state. THEN you created an object oriented class of wich you can create object oriented objects. only if your objects 100% behave as such (and this is by no means true with most classes out there), only THEN it is object oriented. else, its just an object.
Happy New Year!
Phill.

happy new year! davepermen
Jan 01 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
when you use these Objects to do tasks and make them Polymorphic then
it is OO.
Do you agree on that?

newbe or he codes in Java.
Jan 30 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
oo is a design on how to structure your objects, parts of oo is about
 inheritance, or, what IS an object. the other is about encapsulation, or

 does an object LOOK like.

my understanding of encapsulation is when a classes variables are made private and they have public get and set methods.

This understanding is simply crap. This is just plain stupid. Sorry fore being that rude, but that's the way it is, at least if we are talking about objectorientation. I've seen this by many java-coders. Just make the variable private and write public get and set routines for it. Objectorientation is intended to abstract real objects. Encapsulation shoudl be used to distinguish between implementation (what isn't interesting for the usage of the object) and the "interface" which describes what the object can do. If you write a get and set routine for a privat variable you loose the abstraction completly. But abstraction is why you use objectorientation.
 sure, every algorithm processes data. there is no "ergo algorithms are

 oriented". max doesn't bother AT ALL about objects. it is a generic

 algorithm. works with everything. i don't call an int an object.. i

 call it a number..


And what is a number? Some kind of abstract object. So it's not wron using it like, ... no ...., as an object. It depends on the situation whether this view is usefull or not. In a pure mathmatical problem it would be stupid. If the whole problem is about simple mathmatical problems it is somehow stupid to use a objectorientated language, as a functional one would fit much better.
I dont call variables Objects either.

Could you please code C++ for one day. There variables represent object all the time, as all objects have value-semantics by defualt (opposed to reference-semantic as you're used to as a java-coder).
I agree that Classes arent Objects, but Instantiated classes are Objects.
And I would love to learn other languages and intend to eventually,  D in
fact, which is no doubt why I
am here.

this is very common.
Jan 30 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 I am by no means a guru at programming, I am Sun Certified Java programmer
 thats about all, Im not a
 professional, Ive only done one contract, but even I
 can grasp the concept of OO.

You don't need to qualify like this. Everyone gets a shot on this NG. :)
 You said earlier that Barry had a lot to learn, I believe
 that you are the one that has a lot to learn(about OO
 anyway) and maybe listening is a great part of learning.

 wow I cant believe that you can say this:
 ===========================
 "how does

 max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it

 a
 different part..

 programming happens on different layers. oo is one. procedural is another.
 "
 ===================
 that statement can return the contents of the greater one of two of the
 Objects data fields.
 You use procedural inside Objects on their data fields....

Hmm. This is a bad example on which to be arguing for OO, especially wrt D. If a and b are related polymorphically, and provide different overloads of their comparison operators, then the result can depend on the order in which a and b are expressed to the function. This is, in fact, a great example of how generics and non-member overloads are important.
 Phill.

 "He who asks is a fool for five minutes, but he who does not ask remains a
 fool forever."

How about: "He who learns from one who is learning drinks from a running stream"?
Jan 29 2004
prev sibling next sibling parent reply "Phill" <phill pacific.net.au> writes:
see this URL, Java can load the classes(Objects)with a lot less trouble:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html

Phill.


"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
 just a quick question before i go to bed:

 my exe scans the folder for all .plugin files, wich are renamed .dll

 get loaded, and each has a "describe" function in, wich returns name and
 function pointer to a creator function of the type in there (wich is

 from a base interface, a.k.a. IPlugin

 then i can just code new plugins, compile as dll, and add to the folder of

 exe.. and voilą, the exe can create objects of it..

 i've made that way "app wizards", wich could create different types of

 (leds could use it for different project types, for example).

 no need to change the factory in the exe at all. this is what i stated

 times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<




and about oo.. how does max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it

 different part..

 programming happens on different layers. oo is one. procedural is another.
 generic another. patterns fit onto a top layer above them.

 only if you know to use all, you are really good at creating reusable

 is dynamic even while static compiled. every c++ programer knows this.

 brainwashed java/.NET programmers still think you always have to create a

 around a static method.

 do i really have to code that up? well then.. if i have time, tomorrow at

 else.. next year:D


 or is that still too static?


 and you haven't answered my question:

 if you know the type at code time (or a base of it, like IPlugin), then

 code with it. but then you don't need runtime object creation of unknown

 factory is enough.
 if you don't know the type at code time, then how do you code with it?

 with some script at runtime, or.. how?
 you haven't answered that basic question. wich is the whole "why do i want

 create an object of unknown type?".
 i simply don't understand what i should be able to use it for?

 and sorry for being that ignorant btw.. i simply don't get it. and i want

 it. but i don't know how yet.. you have to help me.. some applications

 how it adds really would be useful.



 and vm's are simply basecode to run scripts. binary scripts, but still


Dec 30 2003
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
and that does say? it is still possible to just have an extern(D) IMyBaseType
createType(SomeParams) { return new MyDerivedType(SomeParams); } in a dll, and
the class..

most the time you don't need more. you need only if you want at runtime
inspection of the actual members and all. but how often do you need that, i'm
curious. and as far as i know only when you want to bother with that runtime
inspection, a.k.a. do something at runtime with it. and that, by default, means
scripting. (scripting == creating new program flow at runtime.. a console in a
game is a small scripting engine, for example.. it can be invisible, behind a
gui, too, and is still there).

i KNOW java makes it nicer. but its not MUCH code. and its definitely DOABLE.
there is no need to get a class object, to only call myClass.new() on it. if you
know what interface you want, you can just have a factory doing it. (the above
given function IS a factory..).

i'm still waiting to see the use..

plugins have their use. but neighter c++ nor D have ANY problem with creating
objects in dll's that are of some basetype, and the dll loader only knows the
basetype. this is a nobrainer. tons of applications use that. they don't even
all know objects yet..

there IS a problem currently with D and plugins (a.k.a. dll's). and that is,
sharing of gc collections. this is not yet possible in a clean way.. possibly
you have to just derive the objects from com, so that they don't get gc
collected anyways.. have to test that..

In article <bstct1$273q$1 digitaldaemon.com>, Phill says...
see this URL, Java can load the classes(Objects)with a lot less trouble:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html

Phill.


"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
 just a quick question before i go to bed:

 my exe scans the folder for all .plugin files, wich are renamed .dll

 get loaded, and each has a "describe" function in, wich returns name and
 function pointer to a creator function of the type in there (wich is

 from a base interface, a.k.a. IPlugin

 then i can just code new plugins, compile as dll, and add to the folder of

 exe.. and voilą, the exe can create objects of it..

 i've made that way "app wizards", wich could create different types of

 (leds could use it for different project types, for example).

 no need to change the factory in the exe at all. this is what i stated

 times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<




and about oo.. how does max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it

 different part..

 programming happens on different layers. oo is one. procedural is another.
 generic another. patterns fit onto a top layer above them.

 only if you know to use all, you are really good at creating reusable

 is dynamic even while static compiled. every c++ programer knows this.

 brainwashed java/.NET programmers still think you always have to create a

 around a static method.

 do i really have to code that up? well then.. if i have time, tomorrow at

 else.. next year:D


 or is that still too static?


 and you haven't answered my question:

 if you know the type at code time (or a base of it, like IPlugin), then

 code with it. but then you don't need runtime object creation of unknown

 factory is enough.
 if you don't know the type at code time, then how do you code with it?

 with some script at runtime, or.. how?
 you haven't answered that basic question. wich is the whole "why do i want

 create an object of unknown type?".
 i simply don't understand what i should be able to use it for?

 and sorry for being that ignorant btw.. i simply don't get it. and i want

 it. but i don't know how yet.. you have to help me.. some applications

 how it adds really would be useful.



 and vm's are simply basecode to run scripts. binary scripts, but still



Dec 30 2003
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
most the time you don't need more. you need only if you want at runtime
inspection of the actual members and all. but how often do you need that, i'm
curious. and as far as i know only when you want to bother with that runtime
inspection, a.k.a. do something at runtime with it. and that, by default, means
scripting. (scripting == creating new program flow at runtime.. a console in a
game is a small scripting engine, for example.. it can be invisible, behind a
gui, too, and is still there).

And why do you consider some kind of "scripting" in a program as bad?
i KNOW java makes it nicer. but its not MUCH code. and its definitely DOABLE.
there is no need to get a class object, to only call myClass.new() on it. if you
know what interface you want, you can just have a factory doing it. (the above
given function IS a factory..).

But you still have to write a factory.
Jan 30 2004
parent "davepermen" <davepermen hotmail.com> writes:
i don't see scripting as something bad. but here we talked about having sort
of reflection in. and all stated we need reflection, even without scripting.
and i see no use for reflection outside of scripting situations at all.
while i don't even require reflection for scripting, that is.

scripting is useful. reflection is very questionable.

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvdb60$2gcq$1 digitaldaemon.com...
most the time you don't need more. you need only if you want at runtime
inspection of the actual members and all. but how often do you need that,


curious. and as far as i know only when you want to bother with that


inspection, a.k.a. do something at runtime with it. and that, by default,


scripting. (scripting == creating new program flow at runtime.. a console


game is a small scripting engine, for example.. it can be invisible,


gui, too, and is still there).

And why do you consider some kind of "scripting" in a program as bad?
i KNOW java makes it nicer. but its not MUCH code. and its definitely


there is no need to get a class object, to only call myClass.new() on it.


know what interface you want, you can just have a factory doing it. (the


given function IS a factory..).

But you still have to write a factory.

Jan 30 2004
prev sibling parent davepermen <davepermen_member pathlink.com> writes:
In article <bstct1$273q$1 digitaldaemon.com>, Phill says...
see this URL, Java can load the classes(Objects)with a lot less trouble:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html

Phill.

PluginLoader.exe: interface IPlugin : IUnknown { extern(Windows): void sayHello(); } import c.stdio; int main(char[][] args) { printf("Hello davepermen!" \n); alias instance Plugin(IPlugin) MyPlugin; MyPlugin.Factory f = MyPlugin.openPlugin("TestPlugin.dll"); IPlugin p = f.newInstance(); p.sayHello(); // or IPlugin p2 = instance Plugin(IPlugin).newInstance("TestPlugin2.dll"); p2.sayHello(); return 0; } TestPlugin.dll: class Plug : ComObject, IPlugin { extern(Windows): void sayHello() { printf("Plug says Hello" \n); } } extern(C) IPlugin createPlugin() { return new Plug; } TestPlugin2.dll: class Plug : ComObject, IPlugin { extern(Windows): void sayHello() { printf("Plug2 says Hello" \n); } } extern(C) IPlugin createPlugin() { return new Plug; } all you need is this template: Plugin Template: template Plugin(T) { class Factory { private T function() createPlugin; private HANDLE lib; this(char[] pluginName) { lib = std.c.windows.windows.LoadLibraryA(std.string.toStringz(pluginName)); assert(lib !== null); createPlugin = cast(T function())std.c.windows.windows.GetProcAddress(lib,"createPlugin"); assert(createPlugin !== null); } T newInstance() { return createPlugin(); } ~this() { std.c.windows.windows.FreeLibrary(lib); } } Factory openPlugin(char[] pluginName) { return new Factory(pluginName); } T newInstance(char[] pluginName) { HANDLE lib = std.c.windows.windows.LoadLibraryA(std.string.toStringz(pluginName)); assert(lib !== null); T function() f = cast(T function())std.c.windows.windows.GetProcAddress(lib,"createPlugin"); assert(f !== null); return f(); } } in my case, i would only use Plugin(T).newInstance.. so the code is very short. now, all we need is a platform independent runtime lib loader (.dll and .so), and with recls you can iterate trough the file system scanning for plugins if you want to. dunno.. what more do you need as long as you don't need scripting? and if i need scripting, i can do so with my JIT D compiler setup (wich uses dmd to generate .dll's to load:D)
Dec 31 2003
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
and about oo..

how does

max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is a
different part..

programming happens on different layers. oo is one. procedural is another.
generic another. patterns fit onto a top layer above them.

only if you know to use all, you are really good at creating reusable code, that
is dynamic even while static compiled. every c++ programer knows this. only
brainwashed java/.NET programmers still think you always have to create a class
around a static method.

and you haven't answered my question:

if you know the type at code time (or a base of it, like IPlugin), then you can
code with it. but then you don't need runtime object creation of unknown type,
factory is enough.
if you don't know the type at code time, then how do you code with it? eighter
with some script at runtime, or.. how?
you haven't answered that basic question. wich is the whole "why do i want to
create an object of unknown type?".
i simply don't understand what i should be able to use it for?

and sorry for being that ignorant btw.. i simply don't get it. and i want to get
it. but i don't know how yet.. you have to help me.. some applications showing
how it adds really would be useful.

There are two basic types of OO: The Simula model and the Smalltalk model. They are pretty different. Using a language based on the Smalltalk principles (e.g. Objective-C) the type never matters. These languages allways follow the rule: If something can be done a t runtime, do it at runtime, so you are as flexible as possible. If you have an object you can send it a message. The object will respond to this message if it can. e.g. you could send "reverse" to an object. If it is a string it will reverse the order of it's characters. If it's a figure in a game it will turn around but it doesn't matter to the coder. This can be done very limited using the simula model with virtual methods, but the objects have to have the same base and you have to have a reference of a base type to invoke this method. In languages using the Smalltalk model objects can often forward messages. If you send an object that you'd like to discuss something with it and it is a "warrior" he could delegate this message to a "diplomat" (is this the right word?) and you wouldn't even notice it. [whatever discuss:"blabla"]; // here whatever turns out to be a warrior who delegates the message discuss:"blabla" to a diplomat, but you don't notice it. It looks like you'd directly use whatever (which is a warrior).
and vm's are simply basecode to run scripts. binary scripts, but still scripts.

Yes and native executables are just scripts for the cpu!?! But this isn't what you normaly refer to as "script".
Jan 30 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
[also inline]

Sorry Barry, I am a bit brain-dead atm, so that may explain, but I just
don't get it.

Can you answer me this question:

    What is there that you need that is not supported conceptually (and I
_mean_ conceptually, not all the registry, apartment, coding complexity) by
COM?

Cheers

Reginald


"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns9461CA745A134barrycarrixiansoftwa 63.105.9.61...
 Dave,

 I'm going to cut through all this BS. My position is this:

 C++ is too static. There are times (and I've cited two good examples)
 where  you need some runtime dynamicism to reduce coding, improve
 reliability and allow an application to adapt to new *SOME* new
 situations without falling flat on its face. This is not scripting, IMO,
 but the ability keep an application "Closed for modification, but open
 for extension" as Robert Martin states. Factories always require
 modification and thus break this rule. If you know different then show me
 an example factory as proof. If DMD has similar facilities or better, I'd
 like to see these too.

 I have work long enough with languages with dynamic facilities to know
 that a completely static languages are very restrictive and don't
 facilitate eligant, workable solutions - you end up having to code round
 situations to half get what you want. In my experience, the more dynamic
 a language is the more power the developer has at his or her disposal and
 the quicker they can get the job done. There is big role for compile-time
 facilities such as templates or generics as these can improve runtime
 performance and type safety, but these are still closed solutions.

 Furthermore, there is no reason to use procedural code anymore - OO
 technologies provide a much richer way of modeling problems and provide
 robust, extensible solutions to them. Objects implement algorithms to
 provide these solutions, not the other way round.

I'm checking my calendar here, and it's not saying 1st April. I hate being impolite on NGs to people I've not met but, mate, are you serious?! Have you read *any* of Stepanov's writings on these issues. He's far more erudite than I am, so I won't even attempt to paraphrase; see http://www.stlport.org/resources/StepanovUSA.html. But I will quote some of the less blunt words: "I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work" Please read that article, if you've not already, and tell me where he is fundamentally wrong. I don't mean biased. Of course he's biased, as are we all wont to be. But is he fundamentally and completely wrong, and the Java/Smalltalk folks complete right? If so, you'd better tell the largest community of programmers in the world - the 5+ million C++ programmers - that they're wasting their time basing robust, extensible and *efficient* code on an intellectually bankrupt whim of a mathematically obsessed programming under-achiever. I think not. (btw, I don't believe in 100% generics either. I don't believe in 100% anything. This puts me in a commanding position over anyone, from any camp, who does.)
 Virtual Machines are not uber-scripting languages, they are proper,
 complete languages in there own right and a realisation in the industry
 that a more dynamic runtime environment is required to provide timely,
 robust solutions.

 Now, if you don't agree with any of this, which you clearly don't -
 explain your counter arguments and cite examples.

I'd love to, but I don't find any of your postulates sufficiently concrete to grasp. For example: "Virtual Machines are not uber-scripting languages, they are proper, complete languages in there own right and a realisation in the industry that a more dynamic runtime environment is required to provide timely, robust solutions." I don't even know what that means. Please explain as if you're talking to an idiot as, in some respects, you are. ;)
 And I still want to know what if D has any dynamic facilities.

Yes and no. It has all the necessary mechanisms to do so, with difficulty. I cannot imagine it won't evolve (within the next 12 months) further mechanisms for making it easy to do. But I don't see it evolving to provide what you're talking about, for two reasons: (i) I don't really understand what you're after, (ii) it already addresses the main problem C++ has, the lack of an interface ABI, and will address the others such that dynamic facilities will be supported by compile-time techniques. Cheers Matthew
Jan 29 2004
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
I have work long enough with languages with dynamic facilities to know 
that a completely static languages are very restrictive and don't 
facilitate eligant, workable solutions - you end up having to code round 
situations to half get what you want. In my experience, the more dynamic 
a language is the more power the developer has at his or her disposal and 
the quicker they can get the job done. There is big role for compile-time 
facilities such as templates or generics as these can improve runtime 
performance and type safety, but these are still closed solutions. 

Smalltalk like object system (like Objective-C does to C). So you can use the extrem felxible features of Objective-C class when needed or use the powerfull compiletime stuff c++ offers, whe you prefer this in a situation. My experience showed me that using the mvc-model it's pretty cool to do the model in C++ and the view in objective-c and the controler brings both worlds together. At first ObjectiveC++ looks a bit strange as it looks like a simple mixture of two languages, but whe you try it it turnes out that they fir toghether very well.
Jan 30 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Why do we need a foreach in D? you can do it with a simple for loop. Or qhat do
we need the for loop and the do-while loop for? We don't. We could do everything
with a simple while. So they are senseless. Why do we have virtual methods? we
don't need them. We could do the same with simple functionpointers. There are
many things we don't neccessarily "need".

But We have it and use it very often. It's the same with reflection abilitys.
This feature would be used less often than a foreach loop, but it would be used.

You could pass types arround at runtime without concerning about it. It simple
makes life more compfortable as virtual methods do.
Jan 30 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
virtual methods are designed exactly for that purpose: passing around object
you only know the base type, and you're 100% able to use them as this. THAT
is oo.

read up on the reply above. it's all there!

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvd7u4$29mj$1 digitaldaemon.com...
 Why do we need a foreach in D? you can do it with a simple for loop. Or

 we need the for loop and the do-while loop for? We don't. We could do

 with a simple while. So they are senseless. Why do we have virtual

 don't need them. We could do the same with simple functionpointers. There

 many things we don't neccessarily "need".

 But We have it and use it very often. It's the same with reflection

 This feature would be used less often than a foreach loop, but it would be

 You could pass types arround at runtime without concerning about it. It

 makes life more compfortable as virtual methods do.

Jan 30 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
In article <bvdhjj$2qpu$1 digitaldaemon.com>, davepermen says...
virtual methods are designed exactly for that purpose: passing around object
you only know the base type, and you're 100% able to use them as this. THAT
is oo.

Of course the type has to be derived from a baseclass, so I know the interface, but I don't know the behavior. Of course this can be emulated very easyly.
Jan 30 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
and what do you use the type for? for creating instances? so all you need to
pass around is some

delegate IBaseClass create();

or not?

i see your point, but i simply see NO use for it. except if you, at runtime,
want to inform the AppUser for stuff. and let him use that knowledge. and
that means scripting (scripting is, letting the user (re)program parts of
the program)

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvdj6j$2tbl$1 digitaldaemon.com...
 In article <bvdhjj$2qpu$1 digitaldaemon.com>, davepermen says...
virtual methods are designed exactly for that purpose: passing around


you only know the base type, and you're 100% able to use them as this.


is oo.

Of course the type has to be derived from a baseclass, so I know the

 but I don't know the behavior.

 Of course this can be emulated very easyly.

Jan 30 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
and what do you use the type for? for creating instances? so all you need to
pass around is some

delegate IBaseClass create();

or not?

As I said, this can be emulated without any problems. Yes, right.
i see your point, but i simply see NO use for it. except if you, at runtime,
want to inform the AppUser for stuff. and let him use that knowledge. and
that means scripting (scripting is, letting the user (re)program parts of
the program)

The "passed type" could depend on anything, on something you've read from a database, on a click by the user on a button. This depends very much the situation. It would only save some code, if you could pass types arround. Without you have to write a function for each type you want to pass around. That's all.
Jan 30 2004
parent "davepermen" <davepermen hotmail.com> writes:
templated functions?

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bve146$i00$1 digitaldaemon.com...
and what do you use the type for? for creating instances? so all you need


pass around is some

delegate IBaseClass create();

or not?

As I said, this can be emulated without any problems. Yes, right.
i see your point, but i simply see NO use for it. except if you, at


want to inform the AppUser for stuff. and let him use that knowledge. and
that means scripting (scripting is, letting the user (re)program parts of
the program)

The "passed type" could depend on anything, on something you've read from

 database, on a click by the user on a button. This depends very much the
 situation.

 It would only save some code, if you could pass types arround. Without you

 to write a function for each type you want to pass around. That's all.

Jan 30 2004
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Barry Carr wrote:
 Thats the first time I ever heard it to be a bad thing to be too "OO". 
 Alan Kay (the creator of Smalltalk) was right when he said (more or 
 less): "I invented the term 'Object Oriented' and C++ wasn't what I had 
 in mind". In my not so humble opinion, procedural code is degenerate, and 
 closed for extension. How can being too "OO" be a bad thing?

Simply don't let it constrain yourself too much. Be assured that most people in this particular newsgroup find a lot of pleasure in using OOP to solve most of the tasks. However, OOP in C++ and D and Delphi is not complete, so rely for it for daily tasks, but not for every piece of wizardry. Sometimes getting down to a mix of OOP and non-OOP would get you shorter and more elegant code than either of the worlds. Example: multimethods.
  1. Delphi and C++ Builder need and use this facility when creating forms    

Delphi generates DLLs. It also generates RTTI very similar to what D has. I think we might have this extended to provide full Delphi-like RTTI, since it's marvellous.
 All the examples I've seen of factories in C++, and I've looked at a few 
 of them like Scott Meyer's in Effective C++ and Bjarne's in the wave 
 book, and they are all closed. You have to keep coming back to them as 
 you add more classes to your app - this means that they are never stable 
 as they are always open to change. Now, its been a while since I've 
 checked this out, things may have moved on since them. Can you point me 
 to, or show me a contempory factory implementation?

Yup. It doesn't work in portable or standard C++, since creation of shared object files (.so/.dll) is not the language ability, since it's a relatively "new" platform feature on some platforms. You have to rely on compiler extensions. This would be __declspec(dllimport) and __declspec(dllexport). The difference is, DLL creation is part of the D Programming Language with an "export" keyword. I believe some furter extensions are requiered to the library to make this support complete, but the language apparently has what we need. The plug-in loader in the main application would rely upon a few functions defined in DLLs, which would describe what objects this plug-in can generate, along with descriptive information, and create objects of corresponding type. The factory in the application enumerates the plug-ins at application start by scanning a certain directory where plug-ins should be stored, and running the information functions of all the DLLs in there. Almost every extensible C++ appplication uses a similar technique, the ones i'm aware of are Jeskola BUZZ and Psycle Modular Music Studio. Usually they can only be extended by plug-ins compiled with the same compiler as the main application, but this will not be a problem with D. ;)
 But the whole point is that you DON'T know at runtime what a class is. A 
 class could have been added after the main application was compiled and 
 shipped.

Yup. Plug-in system is what you need.
 Sorry, I'm not really following this. Are you saying that all languages 
 with a VM are scripting languages?

 I think you are missing the point here

Let noone tell you that you need a scripting language. ;) You need D, but improved one - more likely on the library part than on the language part. But as far as the library features go, you have to rely upon yourself and other community members. Walter has quite enough to do with the compilers. About the Delphi example. I believe this can also be implemented in D. I'll have a look at it. As to C++ example: ever heard of named constructors ideom? Look it up in any FAQ. And i believe i would get an even more elegant solution for D.
 And BTW, I'm not trying to say that Delphi is better than C++ or D for 
 that matter.

Why not? Delphi can be better than C++ in a ton of aspects. Definately not in each and every of them, but i believe we have had so many Delphi followers here, that it has significantly influenced the design of D.
 Don't be ridiculous! I am not trying to diss the GC. GCs are a wonderful, 
 and nessesary thing. I was merely pointing out that any overhead incured 
 by having extra runtime info included with a class would be far 
 outweighed by sweeps of the GC, no matter how effiecent the GC was.

Hmmmm... You apparently have no idea. A class is stored as a struct of its values, with one pointer into read-only application part. This read-only data, "vtable" is shared among all class instances, and contains pointers to class methods, as well as possibly some other descriptive information, such as class name and pointers to its parents' vtable, and also layout of fields (D and Delphi only), as well as layout of properties and/or other methods (so far Delphi only, *might* be added to D). As you can guess, this whole information is stored in a constant application area, and hence doesn't affect the GC in any way. It doesn't even affect the heap. -eye
Dec 30 2003
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns9460C663C917Ebarrycarrixiansoftwa 63.105.9.61...
 Hi Dave, Antti

It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as
they don't allow access to objects unless you use COM); streaming in
and creating objects etc. esp. if you're using an OODBMS; any form of
data driven application is extremly difficult to construct without
this facility. Having the ability to create instances dynamically adds
an extra dimension of flexibility to your software at NO extra cost if
the feature is support by the language.

sounds so poethic. but is rather nonsence imho. i had never problems adding objects with dll's and all. you "think" too much oo. in the end, its all just binary code to execute. creating objects is just calling a function doing that. creating them by name only needs a factory wich can get runtime edited.

Thats the first time I ever heard it to be a bad thing to be too "OO". Alan Kay (the creator of Smalltalk) was right when he said (more or less): "I invented the term 'Object Oriented' and C++ wasn't what I had in mind". In my not so humble opinion, procedural code is degenerate, and closed for extension. How can being too "OO" be a bad thing?

Halleluyah! All power to his elbow. I think OO sucks no less (and no more) than procedural programming, or generic programming, or ADTs, or assembler. Anyone that thinks that any single paradigm is the answer to the programming problems one meets in the real world is a <moderator-snip> the kindest translation of the author's language would be "confused individual" </moderator-snip>. So I'm quite happy that C++ is not deemed to be OO by Smalltalk people. I just wish it wasn't deemed as an OO language by C++ programmers. C++ is a programming language that supports multiple programming paradigms with equal facility. Apart from a few obvious ones, such as DbC mechanisms (in particular postconditions, since pre-conditions and invariants are largely trivial to support), it does that a sight better than any other language ... yet. Maybe D will be the one that beats it, but there's a long way to go before we can see that.
 <snip>


Overall, I just don't get your feature request. If you're saying that D makes it impossible to provide binary-compatible objects to be loaded at runtime, then I say phooeey! Several years ago I invented (though I expect several have done so) a compiler-/platform-independent mechanism to do this in C++ - it's documented in Chapters 13 & 14 of my forthcoming book "Imperfect C++" - and it ran so well on so many different operating systems, and outperformed the previous system that it became the client's world standard programmable parsing architecture. D makes several of the problems we encounter in C++ moot, so if anything it makes these none-too-difficult things even easier. If you're saying that D should provide some of the admittedly boilerplate aspects of these mechanisms, then maybe you have a point. But until and unless you can provide a compelling example of such I'm afraid I must agree with the others who have expressed befuddlement at the issues, or the fundamental nature thereof, that you're putting forth. Let's have a practical example, with whatever pseudo-D you consider appropriate. Cheers Matthew Wilson STLSoft moderator (http://www.stlsoft.org) Contributing editor, C/C++ Users Journal (www.synesis.com.au/articles.html#columns) "If I'm curt with you it's because time is a factor. I think fast, I talk fast, and I need you guys to act fast" -- Mr Wolf ---------------------------------------------------------------------------- ---
Jan 29 2004
prev sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <Xns945FD4AE1AF7Fbarrycarrixiansoftwa 63.105.9.61>, Barry Carr wrote:
 davepermen <davepermen_member pathlink.com> wrote in
 news:bsmu5g$1m96$1 digitaldaemon.com: 
 
 dunno why this should be vital at all.. D is not a scripting language,
 and not written in runtime.. why should it be able to create objects
 of unknown type at runtime? there are simply no unkown types anymore
 at runtime. 
 
 and creating a factory in D is ridiculous easy.. so no problem.

It is vital because an application should be a network of autonomous objects able to react to new situations (within reason) and work with derived classes without any trouble - as Liskov states. For instance: loading plugins at runtime (dlls are not adquate for this purpose as they don't allow access to objects unless you use COM); streaming in and creating objects etc. esp. if you're using an OODBMS; any form of data driven application is extremly difficult to construct without this facility. Having the ability to create instances dynamically adds an extra dimension of flexibility to your software at NO extra cost if the feature is support by the language.

Could you describe in more detail what you mean by this dynamic instantiation? When I think "virtual constructors" and "creating an object without knowing its actual type", that means factory methods, a standard technique in statically typed OO languages. But are you proposing something like: Object create(String type); // creates object of type type or perhaps something more dynamic, such as compiling new types at runtime? Examples from existing languages?
 I can never understand why the C++ community cannot see this - instead 
 they bang on about how you don't need it.

Maybe it's that we're so accustomed to doing things the usual way that we cannot even imagine what you are looking for. -Antti
Dec 29 2003
prev sibling next sibling parent reply "Charles" <sanders-consulting comcast.net> writes:
Hmm, you own Ixian software ?  Is that a dune refrence ?

C

"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61...
 Hi,

 I was looking at the language comparison chart for D and I was wondering
 how dynamic was the language at runtime?

 One of the things that I don't like about C++ is its lack of virtual
 constructors, or any other mechanism within the language to be able to
 instantiate an object without compile time knowledge of its type. Java and
 C# get around this through reflection - not ideal but it works. Delphi has
 a datatype design to hold class references that make dynamic instantiation
 very easy. Does D have a similar facility? If not, could you explain why
 this feature wasn't included as it strikes me as being an absolutely vital
 feature of any OO language. I also notice that someone else asked a

 question in this newsgroup in Feb 2001; Has any progress been made in this
 area since then?

 Cheers,

 Barry Carr

 Ixian Software Components Ltd
 Blairgowrie
 Perthshire
 Scotland
 www.Ixian-Software.com

Dec 28 2003
parent Barry Carr <barrycarr ixian-software.com> writes:
"Charles" <sanders-consulting comcast.net> wrote in
news:bsn0tu$1rcr$1 digitaldaemon.com: 

 Hmm, you own Ixian software ?  Is that a dune refrence ?
 

Cheers Barry Carr Ixian Software Components Ltd
Dec 28 2003
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Barry Carr wrote:
 Hi,
 
 I was looking at the language comparison chart for D and I was wondering
 how dynamic was the language at runtime? 
 
 One of the things that I don't like about C++ is its lack of virtual 
 constructors, or any other mechanism within the language to be able to 
 instantiate an object without compile time knowledge of its type. Java and 
 C# get around this through reflection - not ideal but it works. Delphi has 
 a datatype design to hold class references that make dynamic instantiation 
 very easy. Does D have a similar facility? If not, could you explain why 
 this feature wasn't included as it strikes me as being an absolutely vital 
 feature of any OO language. I also notice that someone else asked a similar 
 question in this newsgroup in Feb 2001; Has any progress been made in this 
 area since then?

Maybe my C++ background is showing, but I've never found this to be much of a problem. The prototype and factory patterns accomplish this without much fuss. I have used this sort of thing in Python, but not enough that I'd call it a vital feature of the language. -- andy
Dec 28 2003
parent Charles Hixson <charleshixsn earthlink.net> writes:
Andy Friesen wrote:
 Barry Carr wrote:
 
 Hi,

 I was looking at the language comparison chart for D and I was wondering
 how dynamic was the language at runtime?
 One of the things that I don't like about C++ is its lack of virtual 
 constructors, or any other mechanism within the language to be able to 
 instantiate an object without compile time knowledge of its type. Java 
 and C# get around this through reflection - not ideal but it works. 
 Delphi has a datatype design to hold class references that make 
 dynamic instantiation very easy. Does D have a similar facility? If 
 not, could you explain why this feature wasn't included as it strikes 
 me as being an absolutely vital feature of any OO language. I also 
 notice that someone else asked a similar question in this newsgroup in 
 Feb 2001; Has any progress been made in this area since then?

Maybe my C++ background is showing, but I've never found this to be much of a problem. The prototype and factory patterns accomplish this without much fuss. I have used this sort of thing in Python, but not enough that I'd call it a vital feature of the language. -- andy

problems you deal with. (That is, of course, constrained by the language you use.) Most modern languages are "complete", but the jobs that one tends to tackle with them are the jobs that they make easy to solve. One could theoretically implement a full object system with persistent memory caching and distributed computational capabilities in C. In fact, Gnome practically is such a project. But doing this in C means that you must carry around a huge amount of custom created software. And Gnome doesn't think of itself as the project that I've described, despite the fact that about half (WAG) of the project is useful towards those ends. Prototype and factory don't do this. They don't approach it. And a modern language should contain "hooks" to support this kind of thing. But this is a far different thing than saying that the language should, itself, support this. The capabilities probably fit more neatly into a standard library. But the hooks to enable them need to be present in the basic language. You can't write a factory to deal with an unknown object being presented to you from a machine at the other end of a telecom line. OTOH, what you need is some way to a) run things in a sandbox and b) allow code to be treated as a first class object. (I'm not sure whether it should be source or binary, though I lean towards source, which means that this capability would only be present when the compiler was present, but it allows portability between architectures. Java does this with "jvm" code, but I prefer source anyway, though you could compress it.) Note that this basically means that the library needs to be able to link in a routine that is built during the code execution. No "magic" required. But the alternative is sometimes the requirement to embed a FORTH, LISP, or Python engine into the code. And run them in a sandbox...so you've still got the need for a sandbox.
Dec 28 2003
prev sibling parent reply "Achilleas Margaritis" <axilmar b-online.gr> writes:
It would be nice to have these dynamic capabilities in D. It would make
dynamic applications development much easier. For example, it would make it
dead easy to write a good GUI editor. And there are lots of types of apps
that it would benefit from it.

I come from a C++ background, and I usually implement this sort of
functionality manually by providing as Class object which fully describes
the class in run-time. The Class class has the following public interface:

class Class {
public:
    //default constructor
    Class(const Class *super, const string &name, const string &nameSpace,
bool abstract);

    //returns the class name
    const string &name() const;

    //returns the class namespace
    const string &nameSpace() const;

    //returns the superclass
    const Class *super() const;

    //returns an iterator for traversing the class members
    MemberList::const_iterator beginMembers() const;

    //returns an iterator for ending the traversing the class members
    MemberList::const_iterator endMembers() const;

    //creates an object instance
    virtual Object *createInstance() const = 0;

    //returns an iterator which can be used to examine registered classes
    static ClassList::const_iterator beginClasses() const;
};

In the Class constructor, a Class object registers itself in an internal
static list which can be traversed by external entities using the
beginClasses() static method.

The Class class also has protected methods for adding members:

class Class {
protected:
    void addMember(const Member &m);
};

Finally, the Object class has an interface for returning the object's class:

class Object {
public:
    virtual const Class *getClass() const;
};

In a class implementation file, I manually create a Class-derived object
which describes my class (let's say our dynamic class is named Foo):

class Foo : public Object {
public:
    //returns the foo class
    virtual const Class *getClass() const;

    //some method
    void action();
};

class FooClass : public Class {
public:
    //constructor
    FooClass() : Class(NULL, "Foo", "", false) {
        addMember("action", "void");
    }

    //creates a Foo instance
    virtual Object *createInstance() const {
        return new Foo();
    }
};

//the one and only FooClass instance
static FooClass fooClass;

const Class *FooClass::getClass() const
{
    return &fooClass;
}

So, in run time, I can examine registered classes, and create object
instances without having the classes available at compile time.

As you can see, it can be done in C++. But that's not the problem. Anything
can be done in C++ or any other language. The problem is that it takes too
long to write all this code, when the language could have supported it
automatically.

Somebody will say "but what you are doing is not the proper way, the proper
way is to use class factories". Well, class factories don't solve the
problem.

So, it would be very good if D supported full run-time reflection. Maybe it
could be optional with a compiler flag. But it is important.

"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61...
 Hi,

 I was looking at the language comparison chart for D and I was wondering
 how dynamic was the language at runtime?

 One of the things that I don't like about C++ is its lack of virtual
 constructors, or any other mechanism within the language to be able to
 instantiate an object without compile time knowledge of its type. Java and
 C# get around this through reflection - not ideal but it works. Delphi has
 a datatype design to hold class references that make dynamic instantiation
 very easy. Does D have a similar facility? If not, could you explain why
 this feature wasn't included as it strikes me as being an absolutely vital
 feature of any OO language. I also notice that someone else asked a

 question in this newsgroup in Feb 2001; Has any progress been made in this
 area since then?

 Cheers,

 Barry Carr

 Ixian Software Components Ltd
 Blairgowrie
 Perthshire
 Scotland
 www.Ixian-Software.com

Dec 29 2003
parent reply "Mark Brudnak" <malibrud provide.net> writes:
This is very similar to Smalltalk where a class is an object which creates
objects!  You are right that this can be implemented in any language (I have
seen this done in C as well).  It would be nice if a language (like D) would
treat classes as objects. You could then look up a class in a dll/plugin and
directly instantiate them.  In this case, no factory pattern would be
needed.  For example:

interface Bar {
}

class Foo : Bar {
}

// Open the plugin which has a derivation of Foo.
Plugin myPlugin = openPlugin("MySpecialFoo.dll") ;

// Create a reference to a class.
// Note that Foo.class is a type which is the metaclass of Foo.
Foo.class AFooClass ;

// Now I have a reference to a class by looking it up in the plugin
AFooClass = myPlugin.class() ; // run time check needed here.  Returned
class should be derived from Foo.

// Create an instance of the derived class by calling the constructor.
Foo someSortOfFoo = AFooClass.new() ;

Notice that an instance is created by calling the new() member function of
the *class*.  No factory is needed because the class is instantiated in the
core app and not in the plugin.  The class is merely looked up in the plugin
and returned to the app.

--- Another alternative. ---

It may make more sense to make the lookup based on the type of  interface,
although this is illegal in D right now.

Bar.interface ISpeakBar ;
ISpeakBar = myPlugin.class() ; // runtime check needed here.  Returned class
should have Bar interface.

// Create an instance of a class which conforms to Bar.
Object someBarThing = ISpeakBar.new() ;

--- Generic Alternative ---

IMO the cleanest alternative is to look up a generic class and instantiate
it.  This removes any compiler type checking and forces the core app to
assure that the plugin will support the required calls.

Object AnyClass;
AnyClass = myPlugin.class() ; // runtime check impossible here.

// Create an instance of the class which was looked up.
if (AnyClass --> Foo)  // pseudo code --> means derived from.
{
        Foo someFooObject= AnyClass.new() ;
}

Mark.

"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bssnac$17mt$1 digitaldaemon.com...
 It would be nice to have these dynamic capabilities in D. It would make
 dynamic applications development much easier. For example, it would make

 dead easy to write a good GUI editor. And there are lots of types of apps
 that it would benefit from it.

 I come from a C++ background, and I usually implement this sort of
 functionality manually by providing as Class object which fully describes
 the class in run-time. The Class class has the following public interface:

 class Class {
 public:
     //default constructor
     Class(const Class *super, const string &name, const string &nameSpace,
 bool abstract);

     //returns the class name
     const string &name() const;

     //returns the class namespace
     const string &nameSpace() const;

     //returns the superclass
     const Class *super() const;

     //returns an iterator for traversing the class members
     MemberList::const_iterator beginMembers() const;

     //returns an iterator for ending the traversing the class members
     MemberList::const_iterator endMembers() const;

     //creates an object instance
     virtual Object *createInstance() const = 0;

     //returns an iterator which can be used to examine registered classes
     static ClassList::const_iterator beginClasses() const;
 };

 In the Class constructor, a Class object registers itself in an internal
 static list which can be traversed by external entities using the
 beginClasses() static method.

 The Class class also has protected methods for adding members:

 class Class {
 protected:
     void addMember(const Member &m);
 };

 Finally, the Object class has an interface for returning the object's

 class Object {
 public:
     virtual const Class *getClass() const;
 };

 In a class implementation file, I manually create a Class-derived object
 which describes my class (let's say our dynamic class is named Foo):

 class Foo : public Object {
 public:
     //returns the foo class
     virtual const Class *getClass() const;

     //some method
     void action();
 };

 class FooClass : public Class {
 public:
     //constructor
     FooClass() : Class(NULL, "Foo", "", false) {
         addMember("action", "void");
     }

     //creates a Foo instance
     virtual Object *createInstance() const {
         return new Foo();
     }
 };

 //the one and only FooClass instance
 static FooClass fooClass;

 const Class *FooClass::getClass() const
 {
     return &fooClass;
 }

 So, in run time, I can examine registered classes, and create object
 instances without having the classes available at compile time.

 As you can see, it can be done in C++. But that's not the problem.

 can be done in C++ or any other language. The problem is that it takes too
 long to write all this code, when the language could have supported it
 automatically.

 Somebody will say "but what you are doing is not the proper way, the

 way is to use class factories". Well, class factories don't solve the
 problem.

 So, it would be very good if D supported full run-time reflection. Maybe

 could be optional with a compiler flag. But it is important.

 "Barry Carr" <barrycarr ixian-software.com> wrote in message
 news:Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61...
 Hi,

 I was looking at the language comparison chart for D and I was wondering
 how dynamic was the language at runtime?

 One of the things that I don't like about C++ is its lack of virtual
 constructors, or any other mechanism within the language to be able to
 instantiate an object without compile time knowledge of its type. Java


 C# get around this through reflection - not ideal but it works. Delphi


 a datatype design to hold class references that make dynamic


 very easy. Does D have a similar facility? If not, could you explain why
 this feature wasn't included as it strikes me as being an absolutely


 feature of any OO language. I also notice that someone else asked a

 question in this newsgroup in Feb 2001; Has any progress been made in


 area since then?

 Cheers,

 Barry Carr

 Ixian Software Components Ltd
 Blairgowrie
 Perthshire
 Scotland
 www.Ixian-Software.com


Dec 30 2003
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Mark Brudnak wrote:

This is very similar to Smalltalk where a class is an object which creates
objects!  You are right that this can be implemented in any language (I have
seen this done in C as well).  It would be nice if a language (like D) would
treat classes as objects. You could then look up a class in a dll/plugin and
directly instantiate them.  In this case, no factory pattern would be
needed.  For example:

interface Bar {
}

class Foo : Bar {
}

// Open the plugin which has a derivation of Foo.
Plugin myPlugin = openPlugin("MySpecialFoo.dll") ;

// Create a reference to a class.
// Note that Foo.class is a type which is the metaclass of Foo.
Foo.class AFooClass ;

// Now I have a reference to a class by looking it up in the plugin
AFooClass = myPlugin.class() ; // run time check needed here.  Returned
class should be derived from Foo.

// Create an instance of the derived class by calling the constructor.
Foo someSortOfFoo = AFooClass.new() ;

Notice that an instance is created by calling the new() member function of
the *class*.  No factory is needed because the class is instantiated in the
core app and not in the plugin.  The class is merely looked up in the plugin
and returned to the app.

--- Another alternative. ---

It may make more sense to make the lookup based on the type of  interface,
although this is illegal in D right now.

Bar.interface ISpeakBar ;
ISpeakBar = myPlugin.class() ; // runtime check needed here.  Returned class
should have Bar interface.

// Create an instance of a class which conforms to Bar.
Object someBarThing = ISpeakBar.new() ;

--- Generic Alternative ---

IMO the cleanest alternative is to look up a generic class and instantiate
it.  This removes any compiler type checking and forces the core app to
assure that the plugin will support the required calls.

Object AnyClass;
AnyClass = myPlugin.class() ; // runtime check impossible here.

// Create an instance of the class which was looked up.
if (AnyClass --> Foo)  // pseudo code --> means derived from.
{
        Foo someFooObject= AnyClass.new() ;
}

Mark.

  

could also be extended. How about something like (in the very simple case with no exceptions ect...): class plugin1 : unknown; //This could be tricky, since it doesn't exist until plugin1 is set to a class. Also it would be dynamic and probably use some form of indirection. //Note that plugin1extend is also made public dynamicly. export class plugin1extend : plugin1 { float field3; void method2() {} } export void initClasses() { plugin1.setClass("something.dll", "plugin1"); //Name of the file, Name of the class to import (also should be able to loop through available classes with getClass.) plugin1extend bar2 = new plugin1extend; } //something2.dll export class myPlugin : unknown { void func() { initClasses(); plugin1 bar = new plugin1(); //These next two are basicly for users who know about a class that exists within some plugin and want to call methods directly. bar.foo(50); //foo is a method in something.dll plugin1, the compiler would see it like bar.method("foo", 50);, although it'd be hashed, and transparent to the user. bar.val = 100; //val is a property in something.dll plugin1 //If val doesn't exist an exception could be thrown delegate() [] methods = bar.getMethod(); //List of methods as delegates (ie dynamic reflection) delegate() [] setters = bar.getSet(); //List of setters as delegates delegate() [] getters = bar.getGet(); //List of getters as delegates bar2.foo(30); bar2.val = 70; bar2.field3 = 10.5f; } } //something.dll ... export class plugin1 : unknown { int val; void foo(int 50) { } //Note now, that it would be possible for this plugin to access plugin1extend in something2.dll, although both classes would have to exist first. } With this you'd be able to have a whole heap of classes working together, that don't originally know each other. Note that most of the above would be possible as a library extension. It wouldn't be as efficient as static binding (or checking) and I'm not saying that static binding has been removed. To make this library friendly, parhaps bar.foo(50); bar.val = 100; could be changed to (using some form of template): bar.method("foo", 50); bar.setValue("val", 100); //Not as nice. but then, things get more messy from the plugin side. What about this example: You've written a file exporter plugin for a particular 2d/3d editor (ie 3dsmax) and later someone else adds a new type of shader (material) to the exporter. They don't have access to your file exporter, but your file exporter recognises their plugin and adds a field for it in the export. Furthermore, it could be possible to project the object in an exporter file on to the material surface (thus both classes work cooperately, without knowing each other). Someone may later come along and extend the material (m2). The person who originally wrote the material may add some more features which in turn improves m2. Ok, you all understand this, it's basic inheritance, but it's dynamic, the writes don't even need to touch the editor, and they can all work independently, while at the same time contributing collaboratly. When some class becomes well established, it can be added to the main engine (if the developer so wishes), without causing problems to other plugins that extend the class. Therefore, it should be very easy to change a class from dynamic to static. PS - There seem to be quite a few holes in the code I've just written, but hopefully some elegant syntax will fall out.
Dec 31 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
You've written a file exporter plugin for a particular 2d/3d editor (ie 
3dsmax) and later someone else adds a new type of shader (material) to 
the exporter. They don't have access to your file exporter, but your 
file exporter recognises their plugin and adds a field for it in the 
export.  Furthermore, it could be possible to project the object in an 
exporter file on to the material surface (thus both classes work 
cooperately, without knowing each other).

Someone may later come along and extend the material (m2). The person 
who originally wrote the material may add some more features which in 
turn improves m2.
Ok, you all understand this, it's basic inheritance, but it's dynamic, 
the writes don't even need to touch the editor, and they can all work 
independently, while at the same time contributing collaboratly. 

When some class becomes well established, it can be added to the main 
engine (if the developer so wishes), without causing problems to other 
plugins that extend the class.  Therefore, it should be very easy to 
change a class from dynamic to static.

wich is so nice doable with max script, isn't it? see, scripting is much more capable, and thus much more usable, as this half-script stuff.. and all you show here can be done without the need for any of that loading stuff at all.. imho.
Dec 31 2003
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:

 You've written a file exporter plugin for a particular 2d/3d editor 
 (ie 3dsmax) and later someone else adds a new type of shader 
 (material) to the exporter. They don't have access to your file 
 exporter, but your file exporter recognises their plugin and adds a 
 field for it in the export.  Furthermore, it could be possible to 
 project the object in an exporter file on to the material surface 
 (thus both classes work cooperately, without knowing each other).

 Someone may later come along and extend the material (m2). The person 
 who originally wrote the material may add some more features which in 
 turn improves m2.
 Ok, you all understand this, it's basic inheritance, but it's 
 dynamic, the writes don't even need to touch the editor, and they can 
 all work independently, while at the same time contributing 
 collaboratly.
 When some class becomes well established, it can be added to the main 
 engine (if the developer so wishes), without causing problems to 
 other plugins that extend the class.  Therefore, it should be very 
 easy to change a class from dynamic to static.
   

wich is so nice doable with max script, isn't it? see, scripting is much more capable, and thus much more usable, as this half-script stuff..

isn't as efficient. There are many things that can't be done with scripting. Why then did 3dsmax include the SDK at all?
 and all you show here can be done without the need for any of that 
 loading stuff
 at all.. imho.
  

mind that each plugin/component is programmed by a different group of people, without access to the other's code. And keeping it reasonably efficient. BTW I'm not trying to be defensive, I'm actually interested in other ways of thinking about this problem.
Dec 31 2003
parent reply davepermen <davepermen_member pathlink.com> writes:
Why have D at all if it can all be done though scripting? Scripting 
isn't as efficient.  There are many things that can't be done with 
scripting.  Why then did 3dsmax include the SDK at all?

uhm.. if i remember, that sdk is c++, and creates dlls, and has no need for that fancy fuzz that got requested here, and works well dynamic without recompiling max itself everytime you add a plugin:D
How would you do a D implementation (not max) like that then, taking in 
mind that each plugin/component is programmed by a different group of 
people, without access to the other's code. And keeping it reasonably 
efficient.

essencially what you ask for. com objects can use others, and don't know how they work internally. you can replace them, make new ones, etc.. all without any hassle, all fully dynamic. guess what happens when you download a patch for windows? exactly that. you get some new COMponents that replace the old ones. your system won't even notice
BTW
I'm not trying to be defensive, I'm actually interested in other ways of 
thinking about this problem.

i'm still interested in getting my answer: what do you need the dynamic instantiation of unknown type for if you at compile time a) know its base type (interface), or b) don't know its base type (interested how your exe then uses the actual object) a) works great without rtti b) will never work, except if you can script a bit around at runtime.. oh, and D is not a good scripting language. but a great plugin language anyways. and it's a great language for giving the user ability to code realtime such plugins (even in your very application.. just add a scintilla window, and share the dmd with the user.. all you need for rtcompilation is about 700kb, and, if you set up the paths right in the sc.ini file, it can all be done without any issue with one system(char[] cmdLine) call. very nice, not? when the user presses [RUN], then it gets compiled into a dll, loaded, and executed. i've done that yet. for me, thats enough scripting power for my apps.. D is simply no real cmdline scripting language, phyton or so fits there much bether.
Jan 01 2004
next sibling parent reply "Phill" <phill pacific.net.au> writes:
This is slightly different to what Barry is after but is
a great feature of Java.
For the last two days I have been "dig"ing around
looking for a GUI library for D that actually works.
One is not up to date with D yet(which is understandable considering the
pace of D's development)
 and the other doesnt have a working Windows version.
With these libraries as you know there is a lot of stuffing
around building them and downloading other software
to make them compatible.
With Java it is much easier for example. If you want
to write JavaMail programs, you just download the
JavaMail API. Drop "mail.jar" into the jre's lib\ext
dir and that is all you have to do. Its a matter of minutes, or less.
Its very handy.

It would be good if D could have somthing like this.

Phill.

"davepermen" <davepermen_member pathlink.com> wrote in message
news:bt2j9r$ieq$1 digitaldaemon.com...
Why have D at all if it can all be done though scripting? Scripting
isn't as efficient.  There are many things that can't be done with
scripting.  Why then did 3dsmax include the SDK at all?

uhm.. if i remember, that sdk is c++, and creates dlls, and has no need

 fancy fuzz that got requested here, and works well dynamic without

 max itself everytime you add a plugin:D

How would you do a D implementation (not max) like that then, taking in
mind that each plugin/component is programmed by a different group of
people, without access to the other's code. And keeping it reasonably
efficient.

essencially what you ask for. com objects can use others, and don't know

 they work internally. you can replace them, make new ones, etc.. all

 hassle, all fully dynamic. guess what happens when you download a patch

 windows? exactly that. you get some new COMponents that replace the old

 your system won't even notice

BTW
I'm not trying to be defensive, I'm actually interested in other ways of
thinking about this problem.

i'm still interested in getting my answer: what do you need the dynamic instantiation of unknown type for if you at compile time a) know its base

 (interface), or b) don't know its base type (interested how your exe then

 the actual object)

 a) works great without rtti
 b) will never work, except if you can script a bit around at runtime..


 oh, and D is not a good scripting language. but a great plugin language

 and it's a great language for giving the user ability to code realtime

 plugins (even in your very application.. just add a scintilla window, and

 the dmd with the user.. all you need for rtcompilation is about 700kb,

 you set up the paths right in the sc.ini file, it can all be done without

 issue with one system(char[] cmdLine) call. very nice, not? when the user
 presses [RUN], then it gets compiled into a dll, loaded, and executed.

 i've done that yet. for me, thats enough scripting power for my apps..

 D is simply no real cmdline scripting language, phyton or so fits there

 bether.

Jan 01 2004
next sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Fri, 02 Jan 2004 14:58:43 +1100, Phill wrote:

 This is slightly different to what Barry is after but is
 a great feature of Java.
 For the last two days I have been "dig"ing around
 looking for a GUI library for D that actually works.
 One is not up to date with D yet(which is understandable considering the
 pace of D's development)
  and the other doesnt have a working Windows version.
 With these libraries as you know there is a lot of stuffing
 around building them and downloading other software
 to make them compatible.
 With Java it is much easier for example. If you want
 to write JavaMail programs, you just download

like the watter that comes from your tap: You have no idea where it comes from and you don't care.
 the
 JavaMail API. Drop "mail.jar" into the jre's lib\ext
 dir and that is all you have to do. Its a matter of minutes, or less.
 Its very handy.
 
 It would be good if D could have somthing like this.
 
 Phill.

Let me remind you that those are the work of volunteers. You can always build yours. let me also say that DUI works perfectly (in it's expected alpha quality) with dmd 0.74 both on Linux and Windows. further more why do you need it? just interface directly with C. Do you have a bugget to build such libraries? Hopefully some one, some day will be able to gather a few developers and start a big project. Until then I will have, and share, DUI. One of the main objectives of DUI is to generate interest on D. The other objective is to let ME write D GUI apps. thank you. you made me forget my terrible cold for 3 minutes. Ant http://dui.sourceforge.net
Jan 01 2004
parent "Phill" <phill pacific.net.au> writes:
It wasnt meant as an insult to your work.
I am just trying to get people to look at this from a beginners point of
view, people that are trying to learn a language that
everyone wants to become a popular language.

"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.01.02.05.00.25.458497 yahoo.ca...
 On Fri, 02 Jan 2004 14:58:43 +1100, Phill wrote:

 This is slightly different to what Barry is after but is
 a great feature of Java.
 For the last two days I have been "dig"ing around
 looking for a GUI library for D that actually works.
 One is not up to date with D yet(which is understandable considering the
 pace of D's development)
  and the other doesnt have a working Windows version.
 With these libraries as you know there is a lot of stuffing
 around building them and downloading other software
 to make them compatible.
 With Java it is much easier for example. If you want
 to write JavaMail programs, you just download

like the watter that comes from your tap: You have no idea where it comes from and you don't care.

Nor do most people that use the water, but we all cant go out and dig a well just learn how to use it, instead in our ignorance we turn the tap on.
 the
 JavaMail API. Drop "mail.jar" into the jre's lib\ext
 dir and that is all you have to do. Its a matter of minutes, or less.
 Its very handy.

 It would be good if D could have somthing like this.

 Phill.

Let me remind you that those are the work of volunteers. You can always build yours.

No I cant because I dont have the experience, maybe by the time I am 14 or 15 yrs old I might.
 let me also say that DUI works perfectly
 (in it's expected alpha quality) with dmd 0.74
 both on Linux and Windows.

If you read my post again you might notice I wrote this: "One is not up to date with D yet(which is understandable considering the pace of D's development)" I have the latest DMD.
 further more why do you need it?
 just interface directly with C.

because I am a learner......
 Do you have a bugget to build such libraries?

what is a bugget?
 Hopefully some one, some day will be able to gather a few
 developers and start a big project.
 Until then I will have, and share, DUI.

 One of the main objectives of DUI is to generate interest on D.
 The other objective is to let ME write D GUI apps.

 thank you. you made me forget my terrible cold for 3 minutes.

your welcome! Phill.
 Ant

 http://dui.sourceforge.net

Jan 02 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Phill wrote:
 This is slightly different to what Barry is after but is
 a great feature of Java.
 For the last two days I have been "dig"ing around
 looking for a GUI library for D that actually works.
 One is not up to date with D yet(which is understandable considering the
 pace of D's development)
  and the other doesnt have a working Windows version.
 With these libraries as you know there is a lot of stuffing
 around building them and downloading other software
 to make them compatible.
 With Java it is much easier for example. If you want
 to write JavaMail programs, you just download the
 JavaMail API. Drop "mail.jar" into the jre's lib\ext
 dir and that is all you have to do. Its a matter of minutes, or less.
 Its very handy.
 
 It would be good if D could have somthing like this.
 
 Phill.

It already can, really. All it needs is for a convention to be set forth. Since packages are a part of the language, it's not much to ask that everybody put their libraries in a package, and copy all the imports to one big holding directory. -I is something we could use less of. :) Also, if the import libs get glommed into the binary lib itself, (as digc can do alerady) it's that much easier. -- andy
Jan 02 2004
parent "Phill" <phill pacific.net.au> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:bt3b09$1mm2$1 digitaldaemon.com...
 Phill wrote:
 This is slightly different to what Barry is after but is
 a great feature of Java.
 For the last two days I have been "dig"ing around
 looking for a GUI library for D that actually works.
 One is not up to date with D yet(which is understandable considering the
 pace of D's development)
  and the other doesnt have a working Windows version.
 With these libraries as you know there is a lot of stuffing
 around building them and downloading other software
 to make them compatible.
 With Java it is much easier for example. If you want
 to write JavaMail programs, you just download the
 JavaMail API. Drop "mail.jar" into the jre's lib\ext
 dir and that is all you have to do. Its a matter of minutes, or less.
 Its very handy.

 It would be good if D could have somthing like this.

 Phill.

It already can, really. All it needs is for a convention to be set forth. Since packages are a part of the language, it's not much to ask that everybody put their libraries in a package, and copy all the imports to one big holding directory. -I is something we could use less of. :) Also, if the import libs get glommed into the binary lib itself, (as digc can do alerady) it's that much easier. -- andy

That sounds like it would make life easier Phill.
Jan 02 2004
prev sibling parent reply davepermen <davepermen_member pathlink.com> writes:
Drop "mail.jar" into the jre's lib\ext
dir and that is all you have to do. Its a matter of minutes, or less.
Its very handy.

but you still have to manually code with the mail package then. and the "feature" how you call it, is just the virtual machine feature. D will not have a virtual machine (by default). a D.NET possibly will, if ever. this is even yet possible, when you just download a mail.d file and use it:D if coded properly. problem is, in java, sun is behind the scenes hard working on making all features on all platforms available. this is unique. but its not a great feature of java. its merely great work of sun
Jan 03 2004
parent reply "Phill" <phill pacific.net.au> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bt79td$1gkf$1 digitaldaemon.com...
 Drop "mail.jar" into the jre's lib\ext
dir and that is all you have to do. Its a matter of minutes, or less.
Its very handy.

but you still have to manually code with the mail package then. and the "feature" how you call it, is just the virtual machine feature.

Im well aware of that....
 this is even yet possible, when you just download a mail.d file and use

 coded properly.

That is good then as long as you dont have to use Makefiles and stuff that dont work.
 problem is, in java, sun is behind the scenes hard working on making all
 features on all platforms available. this is unique. but its not a great

 of java. its merely great work of sun

Well thats like saying a great house does not have great features, its just that it was merely great work from the builder.
Jan 03 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
In article <bt7aju$1hoi$1 digitaldaemon.com>, Phill says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bt79td$1gkf$1 digitaldaemon.com...
 Drop "mail.jar" into the jre's lib\ext
dir and that is all you have to do. Its a matter of minutes, or less.
Its very handy.

but you still have to manually code with the mail package then. and the "feature" how you call it, is just the virtual machine feature.

Im well aware of that....
 this is even yet possible, when you just download a mail.d file and use

 coded properly.

That is good then as long as you dont have to use Makefiles and stuff that dont work.
 problem is, in java, sun is behind the scenes hard working on making all
 features on all platforms available. this is unique. but its not a great

 of java. its merely great work of sun

Well thats like saying a great house does not have great features, its just that it was merely great work from the builder.

i just say its not a language feature, but simply a part of the good work of sun to provide a complete and platform independent library. the other issue is only a linker issue (and is actually planned to get resolved in a future dmd version..)
Jan 03 2004
parent reply "Phill" <phill pacific.net.au> writes:
 i just say its not a language feature, but simply a part of the good work

 to provide a complete and platform independent library.

 the other issue is only a linker issue (and is actually planned to get

 in a future dmd version..)

cool! I looked at a tutorial last night and it looks not too hard to learn, what I saw looked a bit like Java coding which I am used to. But I think eventually D will be better because it will be more closer to the System(Java being like the third person). All I can say is that you guys are doing a great and very fast job! The biggest problem that I can see is the developers of D keeping up with each other and the latest version.(not that I know much) How many of you are there? Phill
Jan 03 2004
parent davepermen <davepermen_member pathlink.com> writes:
thats just a problem till version 1.0.

after then, it will be final till the end of days..


okay, it will not:D

but its really no big problem imho. at least i hadn't have any yet. and after
1.0, yes, you don't need to really update, only for bugfixes, or, if you're
interested in testing out new, promoted features.

the standard library will change quite some times i guess.. currently, we're
merely all collecting reusable features.. having them in a general, generic, oo,
etc design that works all nice and proper together, that'll come with time.

In article <bt7eon$1ntd$1 digitaldaemon.com>, Phill says...
 i just say its not a language feature, but simply a part of the good work

 to provide a complete and platform independent library.

 the other issue is only a linker issue (and is actually planned to get

 in a future dmd version..)

cool! I looked at a tutorial last night and it looks not too hard to learn, what I saw looked a bit like Java coding which I am used to. But I think eventually D will be better because it will be more closer to the System(Java being like the third person). All I can say is that you guys are doing a great and very fast job! The biggest problem that I can see is the developers of D keeping up with each other and the latest version.(not that I know much) How many of you are there? Phill

Jan 03 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Why have D at all if it can all be done though scripting? Scripting 
isn't as efficient.  There are many things that can't be done with 
scripting.  Why then did 3dsmax include the SDK at all?

uhm.. if i remember, that sdk is c++, and creates dlls, and has no need for that fancy fuzz that got requested here, and works well dynamic without recompiling max itself everytime you add a plugin:D
How would you do a D implementation (not max) like that then, taking in 
mind that each plugin/component is programmed by a different group of 
people, without access to the other's code. And keeping it reasonably 
efficient.

essencially what you ask for. com objects can use others, and don't know how they work internally. you can replace them, make new ones, etc.. all without any hassle, all fully dynamic. guess what happens when you download a patch for windows? exactly that. you get some new COMponents that replace the old ones. your system won't even notice

But we want a general abstraction that runs on Windows, Linux and MacOS. Something like coded once compiled everywhere.
Jan 30 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
wich is just a mather of abstracting dll/so loading code, wich is one class
and one function..

wow.

that was hard.


"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvdc8i$2i4g$1 digitaldaemon.com...
Why have D at all if it can all be done though scripting? Scripting
isn't as efficient.  There are many things that can't be done with
scripting.  Why then did 3dsmax include the SDK at all?

uhm.. if i remember, that sdk is c++, and creates dlls, and has no need


fancy fuzz that got requested here, and works well dynamic without


max itself everytime you add a plugin:D

How would you do a D implementation (not max) like that then, taking in
mind that each plugin/component is programmed by a different group of
people, without access to the other's code. And keeping it reasonably
efficient.

essencially what you ask for. com objects can use others, and don't know


they work internally. you can replace them, make new ones, etc.. all


hassle, all fully dynamic. guess what happens when you download a patch


windows? exactly that. you get some new COMponents that replace the old


your system won't even notice

But we want a general abstraction that runs on Windows, Linux and MacOS. Something like coded once compiled everywhere.

Jan 30 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
wich is just a mather of abstracting dll/so loading code, wich is one class
and one function..

wow.

that was hard.

I have no problem with that. To me it never matters whether something is part of the language or part of the library, while I normaly even prefer it to be part of the library. (E.g. I don'T understand why we have hashes as a part of the language). If you could write such a gneral loader, and it works fine, I'm sure Walter will concider it as being part of the next release.
Jan 30 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
hashes are part of the language because maps/hashmaps are an often used
feature, and adding them to the language lets one write rather complex
constructs in a nice, clean way..

it wouldn't be as clean at all to write in stl style in c++.

i'm not using linux at all, but i'm using an abstraction to win32 dlls since
long time to do such stuff with dlls.. using com interface because else the
gc has stress managing both sides, exe and dll..

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvdjc1$2tie$1 digitaldaemon.com...
wich is just a mather of abstracting dll/so loading code, wich is one


and one function..

wow.

that was hard.

I have no problem with that. To me it never matters whether something is

 the language or part of the library, while I normaly even prefer it to be

 of the library. (E.g. I don'T understand why we have hashes as a part of

 language).

 If you could write such a gneral loader, and it works fine, I'm sure

 concider it as being part of the next release.

Jan 30 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
hashes are part of the language because maps/hashmaps are an often used
feature, and adding them to the language lets one write rather complex
constructs in a nice, clean way..

So a "int[char] foo;" is much better than a "hash!(int, char) foo;"? And what about linked lists? Why aren't they part of the language? They are used very often, too, epecially by those who like the functional paradigm.
Jan 30 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
never ever used linked lists myself yet..

but yes, int[char] is bether htan hash!(int,char), espencially if you have
complex arrays in each other.. the value[key] syntax is very natural and
fits well into more complex situations..

but yes, it's just sugar.

on the other side, there is more reason for a map-implementation to get into
the language as a linked list. why? because linked lists and dynamic arrays
have the same features (not in performance, but they are both essencially
dynamic arrays..).
maps are something else. they are a key-value-container, and due that often
needed in situations an array itself doesn't work anymore..

so yes, a language should have (at least) one dynamic array data type, and
one (or more) map data types.

linked list doesn't give you anything really.. there was, once, a proposed
way, sort of this:
type[^] will be the same as list!(type)..

just as type[] will stay vector!(type)

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bve19q$i82$1 digitaldaemon.com...
hashes are part of the language because maps/hashmaps are an often used
feature, and adding them to the language lets one write rather complex
constructs in a nice, clean way..

So a "int[char] foo;" is much better than a "hash!(int, char) foo;"? And

 about linked lists? Why aren't they part of the language? They are used

 often, too, epecially by those who like the functional paradigm.

Jan 30 2004
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
never ever used linked lists myself yet..

Never? Interssting.
on the other side, there is more reason for a map-implementation to get into
the language as a linked list. why? because linked lists and dynamic arrays
have the same features (not in performance, but they are both essencially
dynamic arrays..).
maps are something else. they are a key-value-container, and due that often
needed in situations an array itself doesn't work anymore..

But what about sets? Why isn't there a set in the language? What about sorted structures (trees)?
linked list doesn't give you anything really.. there was, once, a proposed
way, sort of this:
type[^] will be the same as list!(type)..

just as type[] will stay vector!(type)

Well, if implemented right, they can give you a lot. Have you ever used a functional lanugage like Haskell or something? Imagine you want a list of all Elements smaller than a threshold. Using linked lists that could be nicly written as: Type[^] filter (Type[^] list, Type threshold) { if (list.head < threshold) return new Type[^](list.head, filter(list.tail, threshold)); else return filter(list.tail, threshold); } As allways: Using some helper functions you can do the same with dynamic arrays as convenient (but slower).
Feb 01 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
i actually used in c++ days only vectors and maps..

now i use [] and [type]..

never needed something else.

but of course, it would be useful for some.

no, i never used functional languages by myself yet

"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvigp2$1trp$1 digitaldaemon.com...
never ever used linked lists myself yet..

Never? Interssting.
on the other side, there is more reason for a map-implementation to get


the language as a linked list. why? because linked lists and dynamic


have the same features (not in performance, but they are both essencially
dynamic arrays..).
maps are something else. they are a key-value-container, and due that


needed in situations an array itself doesn't work anymore..

But what about sets? Why isn't there a set in the language? What about

 structures (trees)?


linked list doesn't give you anything really.. there was, once, a


way, sort of this:
type[^] will be the same as list!(type)..

just as type[] will stay vector!(type)

Well, if implemented right, they can give you a lot. Have you ever used a functional lanugage like Haskell or something? Imagine you want a list of

 Elements smaller than a threshold. Using linked lists that could be nicly
 written as:

 Type[^] filter (Type[^] list, Type threshold)
 {
 if (list.head < threshold)
 return new Type[^](list.head, filter(list.tail, threshold));
 else
 return filter(list.tail, threshold);
 }


 As allways: Using some helper functions you can do the same with dynamic

 as convenient (but slower).

Feb 01 2004
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
What you see in functional languages such as Haskell is that lists are not
mutable, so *behind the scenes*, they are treated more like pipes anyway, a
way to get data items from one place to another, and can in fact be
implemented as flat vectors providing the compiler can see enough about
what's going on and predict the length requirement.

When you make the lists mutable, you're forcing the compiler to implement
them in a certain way at runtime.  I'm not arguing that lists are not
necessary;  in fact the opposite, as they have quite different complexity
than flat vectors, which dramatically changes performance once they grow to
a given large size.  With small lists, it really doesn't matter if you use a
vector instead, you won't notice the difference until you start dealing with
thousands of objects or more.

A sorted structure is in D already, it's an associative array... if all you
want is to sort the objects, use the object itself as a key and void as the
associated type, like   void[MyKeyType]  .   To be honest I am not sure that
will compile, but it should.

A set is in D already, it's an associative array of bit.

There's a big difference between "feature X should be in D" and "feature X
should be in the D language".  All this stuff could in fact go into the D
standard runtime library, if template syntax wasn't so ugly.  Putting them
in the language itself provides some convenient syntax sugar, but I'd rather
a way be found to make templates less ugly.  Ok, it's not so bad anymore,
just a single set of parens and a bang character...  now if we could just
get rid of the bang.  ;)

Sean

Matthias Becker wrote:
|| never ever used linked lists myself yet..
|
| Never? Interssting.
|
|| on the other side, there is more reason for a map-implementation to
|| get into the language as a linked list. why? because linked lists
|| and dynamic arrays have the same features (not in performance, but
|| they are both essencially dynamic arrays..).
|| maps are something else. they are a key-value-container, and due
|| that often needed in situations an array itself doesn't work
|| anymore..
|
| But what about sets? Why isn't there a set in the language? What
| about sorted structures (trees)?
|
|
|| linked list doesn't give you anything really.. there was, once, a
|| proposed way, sort of this:
|| type[^] will be the same as list!(type)..
||
|| just as type[] will stay vector!(type)
||
|
| Well, if implemented right, they can give you a lot. Have you ever
| used a functional lanugage like Haskell or something? Imagine you
| want a list of all Elements smaller than a threshold. Using linked
| lists that could be nicly written as:
|
| Type[^] filter (Type[^] list, Type threshold)
| {
| if (list.head < threshold)
| return new Type[^](list.head, filter(list.tail, threshold));
| else
| return filter(list.tail, threshold);
| }
|
|
| As allways: Using some helper functions you can do the same with
| dynamic arrays as convenient (but slower).
Feb 01 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
void[type] works.

at least, it worked last time i've used it..

i think..

it's late:D

"Sean L. Palmer" <palmer.sean verizon.net> schrieb im Newsbeitrag
news:bvjmn2$noo$1 digitaldaemon.com...
 What you see in functional languages such as Haskell is that lists are not
 mutable, so *behind the scenes*, they are treated more like pipes anyway,

 way to get data items from one place to another, and can in fact be
 implemented as flat vectors providing the compiler can see enough about
 what's going on and predict the length requirement.

 When you make the lists mutable, you're forcing the compiler to implement
 them in a certain way at runtime.  I'm not arguing that lists are not
 necessary;  in fact the opposite, as they have quite different complexity
 than flat vectors, which dramatically changes performance once they grow

 a given large size.  With small lists, it really doesn't matter if you use

 vector instead, you won't notice the difference until you start dealing

 thousands of objects or more.

 A sorted structure is in D already, it's an associative array... if all

 want is to sort the objects, use the object itself as a key and void as

 associated type, like   void[MyKeyType]  .   To be honest I am not sure

 will compile, but it should.

 A set is in D already, it's an associative array of bit.

 There's a big difference between "feature X should be in D" and "feature X
 should be in the D language".  All this stuff could in fact go into the D
 standard runtime library, if template syntax wasn't so ugly.  Putting them
 in the language itself provides some convenient syntax sugar, but I'd

 a way be found to make templates less ugly.  Ok, it's not so bad anymore,
 just a single set of parens and a bang character...  now if we could just
 get rid of the bang.  ;)

 Sean

 Matthias Becker wrote:
 || never ever used linked lists myself yet..
 |
 | Never? Interssting.
 |
 || on the other side, there is more reason for a map-implementation to
 || get into the language as a linked list. why? because linked lists
 || and dynamic arrays have the same features (not in performance, but
 || they are both essencially dynamic arrays..).
 || maps are something else. they are a key-value-container, and due
 || that often needed in situations an array itself doesn't work
 || anymore..
 |
 | But what about sets? Why isn't there a set in the language? What
 | about sorted structures (trees)?
 |
 |
 || linked list doesn't give you anything really.. there was, once, a
 || proposed way, sort of this:
 || type[^] will be the same as list!(type)..
 ||
 || just as type[] will stay vector!(type)
 ||
 |
 | Well, if implemented right, they can give you a lot. Have you ever
 | used a functional lanugage like Haskell or something? Imagine you
 | want a list of all Elements smaller than a threshold. Using linked
 | lists that could be nicly written as:
 |
 | Type[^] filter (Type[^] list, Type threshold)
 | {
 | if (list.head < threshold)
 | return new Type[^](list.head, filter(list.tail, threshold));
 | else
 | return filter(list.tail, threshold);
 | }
 |
 |
 | As allways: Using some helper functions you can do the same with
 | dynamic arrays as convenient (but slower).

Feb 01 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bvjmn2$noo$1 digitaldaemon.com...
 What you see in functional languages such as Haskell is that lists are not
 mutable, so *behind the scenes*, they are treated more like pipes anyway,

 way to get data items from one place to another, and can in fact be
 implemented as flat vectors providing the compiler can see enough about
 what's going on and predict the length requirement.

 When you make the lists mutable, you're forcing the compiler to implement
 them in a certain way at runtime.  I'm not arguing that lists are not
 necessary;  in fact the opposite, as they have quite different complexity
 than flat vectors, which dramatically changes performance once they grow

 a given large size.  With small lists, it really doesn't matter if you use

 vector instead, you won't notice the difference until you start dealing

 thousands of objects or more.

 A sorted structure is in D already, it's an associative array... if all

 want is to sort the objects, use the object itself as a key and void as

 associated type, like   void[MyKeyType]  .   To be honest I am not sure

 will compile, but it should.

That's a bloody good idea, although I'm not sure we've got the syntax to test for existence yet. Checking docs now ... ... The only properties are size length keys values rehash so there'd need to be an "exists()" method to support void values
 A set is in D already, it's an associative array of bit.

 There's a big difference between "feature X should be in D" and "feature X
 should be in the D language".  All this stuff could in fact go into the D
 standard runtime library, if template syntax wasn't so ugly.  Putting them
 in the language itself provides some convenient syntax sugar, but I'd

 a way be found to make templates less ugly.  Ok, it's not so bad anymore,
 just a single set of parens and a bang character...  now if we could just
 get rid of the bang.  ;)

 Sean

 Matthias Becker wrote:
 || never ever used linked lists myself yet..
 |
 | Never? Interssting.
 |
 || on the other side, there is more reason for a map-implementation to
 || get into the language as a linked list. why? because linked lists
 || and dynamic arrays have the same features (not in performance, but
 || they are both essencially dynamic arrays..).
 || maps are something else. they are a key-value-container, and due
 || that often needed in situations an array itself doesn't work
 || anymore..
 |
 | But what about sets? Why isn't there a set in the language? What
 | about sorted structures (trees)?
 |
 |
 || linked list doesn't give you anything really.. there was, once, a
 || proposed way, sort of this:
 || type[^] will be the same as list!(type)..
 ||
 || just as type[] will stay vector!(type)
 ||
 |
 | Well, if implemented right, they can give you a lot. Have you ever
 | used a functional lanugage like Haskell or something? Imagine you
 | want a list of all Elements smaller than a threshold. Using linked
 | lists that could be nicly written as:
 |
 | Type[^] filter (Type[^] list, Type threshold)
 | {
 | if (list.head < threshold)
 | return new Type[^](list.head, filter(list.tail, threshold));
 | else
 | return filter(list.tail, threshold);
 | }
 |
 |
 | As allways: Using some helper functions you can do the same with
 | dynamic arrays as convenient (but slower).

Feb 01 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
Matthew wrote:
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bvjmn2$noo$1 digitaldaemon.com...
 A sorted structure is in D already, it's an associative array... if
 all you want is to sort the objects, use the object itself as a key
 and void as the associated type, like   void[MyKeyType]  .   To be
 honest I am not sure that will compile, but it should.

That's a bloody good idea, although I'm not sure we've got the syntax to test for existence yet. Checking docs now ... ... The only properties are size length keys values rehash so there'd need to be an "exists()" method to support void values


if (someKey in hash.keys) { ... } I believe that works. ----------------------- Carlos Santander Bernal
Feb 01 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bvjpu4$tff$1 digitaldaemon.com...
 Matthew wrote:
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bvjmn2$noo$1 digitaldaemon.com...
 A sorted structure is in D already, it's an associative array... if
 all you want is to sort the objects, use the object itself as a key
 and void as the associated type, like   void[MyKeyType]  .   To be
 honest I am not sure that will compile, but it should.

That's a bloody good idea, although I'm not sure we've got the syntax to test for existence yet. Checking docs now ... ... The only properties are size length keys values rehash so there'd need to be an "exists()" method to support void values


if (someKey in hash.keys) { ... } I believe that works. ----------------------- Carlos Santander Bernal

<blushes>Of course</blushes> Thanks
Feb 01 2004
parent "Carlos Santander B." <carlos8294 msn.com> writes:
Matthew wrote:
 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:bvjpu4$tff$1 digitaldaemon.com...
 if (someKey in hash.keys) { ... }

 I believe that works.

 -----------------------
 Carlos Santander Bernal

<blushes>Of course</blushes> Thanks

That was wrong too. It's only someKey in hash ----------------------- Carlos Santander Bernal
Feb 02 2004
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Just realized I am wrong.  A set is more like an associative array of void,
also.

Sean

Sean L. Palmer wrote:
| A set is in D already, it's an associative array of bit.
Feb 01 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Sean L. Palmer wrote:

Just realized I am wrong.  A set is more like an associative array of void,
also.

Sean

Sean L. Palmer wrote:
| A set is in D already, it's an associative array of bit.


  

an array of bits. ie bit [] set; -- -Anderson: http://badmama.com.au/~anderson/
Feb 01 2004
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
That's a Pascal-style set, and it doesn't scale well.  It's more like an
automated flags DWORD than a real set.  Sure, if the set domain is known at
compile time it could be implemented as such.

Sean

J Anderson wrote:
| Sean L. Palmer wrote:
|
|| Just realized I am wrong.  A set is more like an associative array
|| of void, also.
||
|| Sean
||
|| Sean L. Palmer wrote:
||| A set is in D already, it's an associative array of bit.
||
||
||
||
| If it's a set of numbers (within a reasonable range) you can simply
| use an array of bits.
|
| ie
| bit [] set;
Feb 02 2004