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

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)

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

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

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.

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

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.

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

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

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