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 

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 

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 

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 


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


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 
    


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
    


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 


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 this what Mark Brudnak suggested on 
"3) Native support for plugin modules"  
http://www.digitalmars.com/drn-bin/wwwnews?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"  
 http://www.digitalmars.com/drn-bin/wwwnews?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.
 


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.


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


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.

 
 
 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



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.


dunno.. i wait till longhorn to believe it. till now, it doesn't give me much..


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.


bether than c++, possibly (definitely). bether than D, never..
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..
 


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.


i don't see how one has to do with the other, but.. well well..


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




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?

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


The object has a known base class. For example, TMyClass.
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?".


 The object has a known base class. For example, TMyClass.
 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


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


 The object has a known base class. For example, TMyClass.
 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?".


 The object has a known base class. For example, TMyClass.
 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.



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




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


 The object has a known base class. For example, TMyClass.
 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


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


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



  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


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.


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


what

 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


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


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.


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


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 31 2003



 next sibling parent reply davepermen <davepermen_member pathlink.com>  writes:


In Java methods are not  called Objects.


sure. i said object oriented.. java just has classes and methods in classes.
rather restricted.


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


wich is the same.. the definition on how an object looks like for external
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.


yes. i've showed you "generic programming" (in this case, in a virtual language
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.


yes instances of a class are objects. still, that doesn't make it object
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.


 sure. i said object oriented.. java just has classes and methods in


classes.

 rather restricted.


I dont call Java restricted in anyway, except maybe native methods are a
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.


 sure. i said object oriented.. java just has classes and methods in


classes.

 rather restricted.


I dont call Java restricted in anyway, except maybe native methods are a
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?


Whe you read a sentence like this you directly know this guy is either a total
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


what

 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


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




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.


There are languages where Classes are objects. Especialy in scripting languages
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


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


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


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


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



  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,




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



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.


That's exactly my opinion. Different paradigms for different tasks. 




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. 


Perhaps you should switch to Objective-C++. This language extends C++ by a
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


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


You don't got the point. I want to pass around types not objects!

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




object

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




THAT

is oo.


 You don't got the point. I want to pass around types not objects!

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




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



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

 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



  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 ?
 


Yup! well spotted.

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 

 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 

 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


It's not so much the language background, as the selection of 
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

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


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






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

  


To make things more complicated ;) It would be nice if these classes 
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..

  


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?


 and all you show here can be done without the need for any of that 
 loading stuff
 at all.. imho.
  


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.

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.


like i've shown before (haven't i?) for plugins.. com works great, and is
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.


sure.

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


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.


 like i've shown before (haven't i?) for plugins.. com works great, and is
 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.


 sure.

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


it:D if

 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


feature

 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


it:D if

 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


feature

 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


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


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


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


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.


like i've shown before (haven't i?) for plugins.. com works great, and is
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




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.


like i've shown before (haven't i?) for plugins.. com works great, and is
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 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




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


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




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


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



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,


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.


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


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



  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.


  


If it's a set of numbers (within a reasonable range) you can simply use 
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