>when you use these Objects to do tasks and make them Polymorphic then
>it is OO.
>Do you agree on that?
>
Whe you read a sentence like this you directly know this guy is either a total newbe or he codes in Java.

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

And why do you consider some kind of "scripting" in a program as bad?

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

But you still have to write a factory.

>>Why have D at all if it can all be done though scripting? Scripting isn't as efficient.  There are many things that can't be done with scripting.  Why then did 3dsmax include the SDK at all?
>
>uhm.. if i remember, that sdk is c++, and creates dlls, and has no need for that fancy fuzz that got requested here, and works well dynamic without recompiling max itself everytime you add a plugin:D
>
>>How would you do a D implementation (not max) like that then, taking in mind that each plugin/component is programmed by a different group of people, without access to the other's code. And keeping it reasonably efficient.
>like i've shown before (haven't i?) for plugins.. com works great, and is essencially what you ask for. com objects can use others, and don't know how they work internally. you can replace them, make new ones, etc.. all without any hassle, all fully dynamic. guess what happens when you download a patch for windows? exactly that. you get some new COMponents that replace the old ones. your system won't even notice
>

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

if you knew oo you would knew that this is exactly what oo is about: you get a baseclass reference if you don't need more.

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

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

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

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

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

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

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvd9hr$2c9u$1@digitaldaemon.com...
> >> >"why do i want to create an object of unknown type?".
> >> The object has a known base class. For example, TMyClass. Or, the object descends from TComponent.
> >
> >Then it's not unknown, is it? Or am I missing something
> >
>
>
> class MyClass {
> }
>
> class MyDerivedA : MyClass {
> }
>
> class MyDerivedB : MyClass {
> }
> ..
> int main ()
> {
> MyClass foo;
>
> if (someCondition)
> foo = new MyDerivedA;
> else
> foo = new MyDerivedB;
>
>
> // OK, now tell me the type of foo.
> // you can't as it's not known.
> // OK you could using classinfo, but this is some kind of reflection, too
> return 0;
> }
>
>

virtual methods are designed exactly for that purpose: passing around object you only know the base type, and you're 100% able to use them as this. THAT is oo.

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

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvd7u4$29mj$1@digitaldaemon.com...
> Why do we need a foreach in D? you can do it with a simple for loop. Or
qhat do
> we need the for loop and the do-while loop for? We don't. We could do
everything
> with a simple while. So they are senseless. Why do we have virtual
methods? we
> don't need them. We could do the same with simple functionpointers. There
are
> many things we don't neccessarily "need".
>
> But We have it and use it very often. It's the same with reflection
abilitys.
> This feature would be used less often than a foreach loop, but it would be
used.
>
> You could pass types arround at runtime without concerning about it. It
simple
> makes life more compfortable as virtual methods do.
>
>

wich is just a mather of abstracting dll/so loading code, wich is one class and one function..

wow.

that was hard.


"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvdc8i$2i4g$1@digitaldaemon.com...
> >>Why have D at all if it can all be done though scripting? Scripting isn't as efficient.  There are many things that can't be done with scripting.  Why then did 3dsmax include the SDK at all?
> >
> >uhm.. if i remember, that sdk is c++, and creates dlls, and has no need
for that
> >fancy fuzz that got requested here, and works well dynamic without
recompiling
> >max itself everytime you add a plugin:D
> >
> >>How would you do a D implementation (not max) like that then, taking in mind that each plugin/component is programmed by a different group of people, without access to the other's code. And keeping it reasonably efficient.
> >like i've shown before (haven't i?) for plugins.. com works great, and is essencially what you ask for. com objects can use others, and don't know
how
> >they work internally. you can replace them, make new ones, etc.. all
without any
> >hassle, all fully dynamic. guess what happens when you download a patch
for
> >windows? exactly that. you get some new COMponents that replace the old
ones.
> >your system won't even notice
> >
>
> But we want a general abstraction that runs on Windows, Linux and MacOS. Something like coded once compiled everywhere.
>
>

In article <bvdhgs$2qm7$1@digitaldaemon.com>, davepermen says...
>
>if you knew oo you would knew that this is exactly what oo is about: you get a baseclass reference if you don't need more.
>
>you know its a MyClass, or derived from it. so you know how to use it. do you need more?

I just wanted to point out that you don't know the type without reflection. Of course you don't need too know it. That's what I like about OO.

In article <bvdhjj$2qpu$1@digitaldaemon.com>, davepermen says...
>
>virtual methods are designed exactly for that purpose: passing around object you only know the base type, and you're 100% able to use them as this. THAT is oo.
>
You don't got the point. I want to pass around types not objects!

Of course the type has to be derived from a baseclass, so I know the interface, but I don't know the behavior.

Of course this can be emulated very easyly.

but what gain would you have with reflection? because without casting it to a type you GUESS it is, you can not USE it.

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

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

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

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvdiu6$2svb$1@digitaldaemon.com...
> In article <bvdhgs$2qm7$1@digitaldaemon.com>, davepermen says...
> >
> >if you knew oo you would knew that this is exactly what oo is about: you
get
> >a baseclass reference if you don't need more.
> >
> >you know its a MyClass, or derived from it. so you know how to use it. do you need more?
>
> I just wanted to point out that you don't know the type without
reflection. Of
> course you don't need too know it. That's what I like about OO.
>
>

and what do you use the type for? for creating instances? so all you need to pass around is some

delegate IBaseClass create();

or not?

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

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvdj6j$2tbl$1@digitaldaemon.com...
> In article <bvdhjj$2qpu$1@digitaldaemon.com>, davepermen says...
> >
> >virtual methods are designed exactly for that purpose: passing around
object
> >you only know the base type, and you're 100% able to use them as this.
THAT
> >is oo.
> >
> You don't got the point. I want to pass around types not objects!
>
> Of course the type has to be derived from a baseclass, so I know the
interface,
> but I don't know the behavior.
>
> Of course this can be emulated very easyly.
>
>