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.

It would be nice to have these dynamic capabilities in D. It would make dynamic applications development much easier. For example, it would make it dead easy to write a good GUI editor. And there are lots of types of apps that it would benefit from it.

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

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

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

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

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

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

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

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

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

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

The Class class also has protected methods for adding members:

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

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

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

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

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

    //some method
    void action();
};

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

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

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

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

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

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

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

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

"Barry Carr" <barrycarr@ixian-software.com> wrote in message news:Xns945F864EEC85Abarrycarrixiansoftwa@63.105.9.61...
> Hi,
>
> I was looking at the language comparison chart for D and I was wondering how dynamic was the language at runtime?
>
> One of the things that I don't like about C++ is its lack of virtual constructors, or any other mechanism within the language to be able to instantiate an object without compile time knowledge of its type. Java and C# get around this through reflection - not ideal but it works. Delphi has a datatype design to hold class references that make dynamic instantiation very easy. Does D have a similar facility? If not, could you explain why this feature wasn't included as it strikes me as being an absolutely vital feature of any OO language. I also notice that someone else asked a
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

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

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.

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

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

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

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
> > C# get around this through reflection - not ideal but it works. Delphi
has
> > a datatype design to hold class references that make dynamic
instantiation
> > very easy. Does D have a similar facility? If not, could you explain why this feature wasn't included as it strikes me as being an absolutely
vital
> > feature of any OO language. I also notice that someone else asked a
> similar
> > question in this newsgroup in Feb 2001; Has any progress been made in
this
> > area since then?
> >
> > Cheers,
> >
> > Barry Carr
> >
> > Ixian Software Components Ltd
> > Blairgowrie
> > Perthshire
> > Scotland
> > www.Ixian-Software.com
>
>

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

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