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

>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

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

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

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

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

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.

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

and the battle goes on.. and gets rather big for this much too small textbox..

anyways.. lets go!

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

if thats the first time you hear that, you have a lot to learn... very lot.

algorithms are independent of objects, and they are the actual major part of every program. oo is just one paradigm you have to follow, or not, to code. it solves some tasks nice, others not at all. thats why we have c++, or D, wich allows for different paradigms.. (generics are hip today, thats why oo-only languages like c# and java now fake to implement it, too)

>Here are two examples for then need to be able to create object of unknown type at runtime:

hm.. i'm interested to see them

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

and.. i don't get it.. whats the use of it? what class details are needed at runtime? wich aren't there else? you code and compile. and it runs then with everything known yet. this worked even in c days. win32 is a c-api, and delphi/c++ builder in the end run on top of it. i don't really see what you gain from it. never had problems creating apps till now "the normal way". i'm interested, but i don't see really the added value. possibly a small demo app could help

> 2. Several years ago I wrote an accounts package for the Legal sector in
>England (Scottish law is different). A legal accounts package is much the same as any double entry book keeping system, except that certain monies have to be seen to be kept seperate to stop fraud. To cut a long story short, I tried to make this application as dynamic as possible and I acheived this by making the app data-driven where possible. To this end, most of the rules about where and how to post money were held in data- table. Amongst this data was the name of class that represented the form needed to get the data from the user. Where specialised posting instructions were needed I employed the strategy pattern, the strategy classes needed for a transaction were listed in a data-table and created and iterated through to complete the task. The advantage of this approach was that I (we) could add transaction types with minium effort and in one place (orthoganality) knowing it would work. It meant that one point in the code could create the classes needed to complete a transaction and still work as more transactions types were added to the application or extended.

so your app was never really finished, and just needed to be partially rewritable/extendable later.. so it is, in that case, scripting. for this, i'd use some scripting language. but i don't say some capabilities to do that directly in D would not be nice:D

>All the examples I've seen of factories in C++, and I've looked at a few of them like Scott Meyer's in Effective C++ and Bjarne's in the wave book, and they are all closed. You have to keep coming back to them as you add more classes to your app - this means that they are never stable as they are always open to change. Now, its been a while since I've checked this out, things may have moved on since them. Can you point me to, or show me a contempory factory implementation?

uhm? you can load dll's, can't you? if you can, then you have it dynamic. just loop trough all existing dll's, request the function you need, and share the factory to it.. it will register itself. with nice template facilities hidden, this is about one statement in the Dll code (or two.. unregistering on unload? wait no, thats RAII for:D), and its one loop + one statement (the factory instantiation) in the executable. thats how i did plugins all the time. worked great so far. and is very simple..

there is the fact that you only get interface access (com like) to your objects you create. you can't query its methods and all (except you implement it to be queriable.. every compiler creates the "reflection" info for you if you need it, even in c++.. but its complicated to work with.. mangled c++ names aren't fun:D).. but then again.. what for? how can your static compiled app call a method on an object it doesn't know the name of the method nor the calling rule, nor the parameters, nor their types.. how can your app call it? it can't. it _HAS_ to know it. and then, why don't you just use a real interface to it?

>But the whole point is that you DON'T know at runtime what a class is. A class could have been added after the main application was compiled and shipped.

if you don't know it, how can your app use it? the part of your app that USES it HAS to know it. except its the USER itself wich uses it. and then, he sort of scripts realtime.

>I am not talking about runtime compilation and you don't need runtime compilation, except on very rare occasions. If I wanted apps that could write themselves I'd use Lisp, Scheme or Smalltalk. I'm talking about not trying to second guess what I will need to create at runtime and allow some room for future extensions.

then what DO you need? if you only detect your classes at runtime, but your code is compile time, how shall your code use it?

>Fine, if DMD will allow dynamic compilation then you show me an example of how you do this and why you would need it. (BTW, .NET will do this too, via the emit facility).

i've read the "holy reflection, look at .NET, with emit and all" and read the example. this example was simple bullshit, sorry. in the end, all the stuff generated at runtime WAS KNOWN AT COMPILE TIME. why not simply... CODE IT?!.

if you have scripting, you laught about reflection.. and if you have both scripting, and compile time coded, and all the runtime reflection, and all, in D, then you don't give a fuzz about reflection. and you know what? i DO have all that.. perfect for coding "own games with given game engine". the trick is to know your tools.. JIT with D (with DMD) is very possible.. compile only at the moment you know what you need..

>My two examples above should show you why you need this feature. You show me examples of how you can do it without this feature, 'cos I'd love to know.

sorry.. i don't see the examples really.. can't imagine the problem 1 just from the text, and problem 2 can be done with my "dynamic plugin facility you've never seen before (a.k.a. dll loader:D)", or if needed, with "JIT D"

>> and you do see that all the languages that have it run in virtual machines? they are actually scripted then.
>
>Sorry, I'm not really following this. Are you saying that all languages with a VM are scripting languages?

scripted, JIT, what ever.. its all the same end. JIT is just a bit before the moment scripting languages get compiled.. just a bit:D

all languages with VM can do runtime compilations, and have the full power of the compile time available at runtime, if needed. (well, the asm part:D). and yes, .NET and the java virtual machine are sort of script engines... very powerful ones, though. even lua does jit today.. and this is a "well known scripting language".. its just smaller

>I think you are missing the point here

i said thats not the point, but wanted to clarify i don't see more in your request, so you missed to show your real problem

>And .NET works even better, Although it galls me to say it.
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

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