|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
D - Dynamic Capabilities of D
↑ ↓ ← → Barry Carr <barrycarr ixian-software.com> writes:
Hi,
I was looking at the language comparison chart for D and I was wondering
how dynamic was the language at runtime?
One of the things that I don't like about C++ is its lack of virtual
constructors, or any other mechanism within the language to be able to
instantiate an object without compile time knowledge of its type. Java and
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
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
dunno why this should be vital at all.. D is not a scripting language, and not
written in runtime.. why should it be able to create objects of unknown type at
runtime? there are simply no unkown types anymore at runtime.
and creating a factory in D is ridiculous easy.. so no problem.
In article <Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61>, Barry Carr
says...
Hi,
I was looking at the language comparison chart for D and I was wondering
how dynamic was the language at runtime?
One of the things that I don't like about C++ is its lack of virtual
constructors, or any other mechanism within the language to be able to
instantiate an object without compile time knowledge of its type. Java and
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
↑ ↓ ← → Mathias Becker <Mathias_member pathlink.com> writes:
In article <bsmu5g$1m96$1 digitaldaemon.com>, davepermen says...
dunno why this should be vital at all.. D is not a scripting language, and not
written in runtime.. why should it be able to create objects of unknown type at
runtime? there are simply no unkown types anymore at runtime.
and creating a factory in D is ridiculous easy.. so no problem.
In article <Xns945F864EEC85Abarrycarrixiansoftwa 63.105.9.61>, Barry Carr
says...
Hi,
I was looking at the language comparison chart for D and I was wondering
how dynamic was the language at runtime?
One of the things that I don't like about C++ is its lack of virtual
constructors, or any other mechanism within the language to be able to
instantiate an object without compile time knowledge of its type. Java and
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 <barrycarr ixian-software.com> writes:
davepermen <davepermen_member pathlink.com> wrote in
news:bsmu5g$1m96$1 digitaldaemon.com:
dunno why this should be vital at all.. D is not a scripting language,
and not written in runtime.. why should it be able to create objects
of unknown type at runtime? there are simply no unkown types anymore
at runtime.
and creating a factory in D is ridiculous easy.. so no problem.
It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as they
don't allow access to objects unless you use COM); streaming in and
creating objects etc. esp. if you're using an OODBMS; any form of data
driven application is extremly difficult to construct without this
facility. Having the ability to create instances dynamically adds an
extra dimension of flexibility to your software at NO extra cost if the
feature is support by the language.
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community
defend this position when they could be petitioning for this feature to
be added? If the facility is there you are not compelled to use it, but
with out it all other options are kludges and workarounds (IMHO). An OO
language should support the ability to create objects anonimously.
When I used to use C++ the lack of this feature caused me no end of
problems, it was one of the main reasons why I ditched it. Factories are
NOT the answer, as adding new classes to the app means making changes to
the factory. Factories are not orthogonal.
And I didn't say D was a scripting language and non of the example
languages I cited were scripting languages either. It is possible to have
this feature in an efficent compiled language with no cost to runtime
performance; esp. in garbage collected language because the gc is going
to take up more time then any extra runtime info will do.
I'm not here to start a language war - I just want to understand why the
C++ community does think this is an important feature, esp when it has
every other feature under the sun crammed in there? And why D, as an
improvement to C++ (which it certainly looks likes), hasn't added this
feature either.
Cheers
Barry Carr
Ixian Software Components Ltd
↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:
Ok, I'll bite, being predominantly a C++ person.
I am prepared to be compelled, so please supply a compelling example.
:)
--
Matthew Wilson
STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)
"If I'm curt with you it's because time is a factor. I think fast, I talk
fast, and I need you guys to act fast" -- Mr Wolf
----------------------------------------------------------------------------
---
"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns945FD4AE1AF7Fbarrycarrixiansoftwa 63.105.9.61...
davepermen <davepermen_member pathlink.com> wrote in
news:bsmu5g$1m96$1 digitaldaemon.com:
dunno why this should be vital at all.. D is not a scripting language,
and not written in runtime.. why should it be able to create objects
of unknown type at runtime? there are simply no unkown types anymore
at runtime.
and creating a factory in D is ridiculous easy.. so no problem.
It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as they
don't allow access to objects unless you use COM); streaming in and
creating objects etc. esp. if you're using an OODBMS; any form of data
driven application is extremly difficult to construct without this
facility. Having the ability to create instances dynamically adds an
extra dimension of flexibility to your software at NO extra cost if the
feature is support by the language.
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community
defend this position when they could be petitioning for this feature to
be added? If the facility is there you are not compelled to use it, but
with out it all other options are kludges and workarounds (IMHO). An OO
language should support the ability to create objects anonimously.
When I used to use C++ the lack of this feature caused me no end of
problems, it was one of the main reasons why I ditched it. Factories are
NOT the answer, as adding new classes to the app means making changes to
the factory. Factories are not orthogonal.
And I didn't say D was a scripting language and non of the example
languages I cited were scripting languages either. It is possible to have
this feature in an efficent compiled language with no cost to runtime
performance; esp. in garbage collected language because the gc is going
to take up more time then any extra runtime info will do.
I'm not here to start a language war - I just want to understand why the
C++ community does think this is an important feature, esp when it has
every other feature under the sun crammed in there? And why D, as an
improvement to C++ (which it certainly looks likes), hasn't added this
feature either.
Cheers
Barry Carr
Ixian Software Components Ltd
↑ ↓ ← → "Charles" <sanders-consulting comcast.net> writes:
I've never had a problem with it, then again I've never used it, can you
give an example in a compiled language that has this ability ( reflection
its called ? ). I must say it looks very cool , though I'm not sure how a
'compiled' language would implement it.
C
"Barry Carr" <barrycarr ixian-software.com> wrote in message
news:Xns945FD4AE1AF7Fbarrycarrixiansoftwa 63.105.9.61...
davepermen <davepermen_member pathlink.com> wrote in
news:bsmu5g$1m96$1 digitaldaemon.com:
dunno why this should be vital at all.. D is not a scripting language,
and not written in runtime.. why should it be able to create objects
of unknown type at runtime? there are simply no unkown types anymore
at runtime.
and creating a factory in D is ridiculous easy.. so no problem.
It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as they
don't allow access to objects unless you use COM); streaming in and
creating objects etc. esp. if you're using an OODBMS; any form of data
driven application is extremly difficult to construct without this
facility. Having the ability to create instances dynamically adds an
extra dimension of flexibility to your software at NO extra cost if the
feature is support by the language.
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community
defend this position when they could be petitioning for this feature to
be added? If the facility is there you are not compelled to use it, but
with out it all other options are kludges and workarounds (IMHO). An OO
language should support the ability to create objects anonimously.
When I used to use C++ the lack of this feature caused me no end of
problems, it was one of the main reasons why I ditched it. Factories are
NOT the answer, as adding new classes to the app means making changes to
the factory. Factories are not orthogonal.
And I didn't say D was a scripting language and non of the example
languages I cited were scripting languages either. It is possible to have
this feature in an efficent compiled language with no cost to runtime
performance; esp. in garbage collected language because the gc is going
to take up more time then any extra runtime info will do.
I'm not here to start a language war - I just want to understand why the
C++ community does think this is an important feature, esp when it has
every other feature under the sun crammed in there? And why D, as an
improvement to C++ (which it certainly looks likes), hasn't added this
feature either.
Cheers
Barry Carr
Ixian Software Components Ltd
↑ ↓ ← → J Anderson <REMOVEanderson badmama.com.au> writes:
Barry Carr wrote:
davepermen <davepermen_member pathlink.com> wrote in
news:bsmu5g$1m96$1 digitaldaemon.com:
dunno why this should be vital at all.. D is not a scripting language,
and not written in runtime.. why should it be able to create objects
of unknown type at runtime? there are simply no unkown types anymore
at runtime.
and creating a factory in D is ridiculous easy.. so no problem.
It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as they
don't allow access to objects unless you use COM); streaming in and
creating objects etc. esp. if you're using an OODBMS; any form of data
driven application is extremly difficult to construct without this
facility. Having the ability to create instances dynamically adds an
extra dimension of flexibility to your software at NO extra cost if the
feature is support by the language.
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community
defend this position when they could be petitioning for this feature to
be added? If the facility is there you are not compelled to use it, but
with out it all other options are kludges and workarounds (IMHO). An OO
language should support the ability to create objects anonimously.
When I used to use C++ the lack of this feature caused me no end of
problems, it was one of the main reasons why I ditched it. Factories are
NOT the answer, as adding new classes to the app means making changes to
the factory. Factories are not orthogonal.
And I didn't say D was a scripting language and non of the example
languages I cited were scripting languages either. It is possible to have
this feature in an efficent compiled language with no cost to runtime
performance; esp. in garbage collected language because the gc is going
to take up more time then any extra runtime info will do.
I'm not here to start a language war - I just want to understand why the
C++ community does think this is an important feature, esp when it has
every other feature under the sun crammed in there? And why D, as an
improvement to C++ (which it certainly looks likes), hasn't added this
feature either.
Cheers
Barry Carr
Ixian Software Components Ltd
I would like a feature like this in D. I made a game engine last year in
C++ that would automaticly detect new objects and make them available to
the editor and scripting engines. For example, if I wanted to make a new
type of weapon, I'd simply derive the weapons class and fill out all the
weapons particular info. It would be compiled as a DLL, and the program
would automaticly detect it and make the weapon available to the editor.
Then you'd be able to place the weapon in a shop, somewhere in the world
or in one of the creatures (players and monsters). It was vary useful
as you didn't have to touch the engine at all and made things easy to
maintain. Users could easily customise the game into anything they
wanted without touching the engine.
The workaround required in C++ to do this was more effort then I would
have hoped for.
Is that what your talking about?
Anderson
↑ ↓ ← → Barry Carr <barrycarr ixian-software.com> writes:
J Anderson <REMOVEanderson badmama.com.au> wrote in
news:bsok83$16s2$1 digitaldaemon.com:
I would like a feature like this in D. I made a game engine
in C++ that would automaticly detect new objects and make
available to the editor and scripting engines. For example,
wanted to make a new type of weapon, I'd simply derive the
class and fill out all the weapons particular info. It would
compiled as a DLL, and the program would automaticly detect
make the weapon available to the editor. Then you'd be able
the weapon in a shop, somewhere in the world or in one of the
creatures (players and monsters). It was vary useful as you
have to touch the engine at all and made things easy to
Users could easily customise the game into anything they
without touching the engine.
The workaround required in C++ to do this was more effort
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
↑ ↓ ← → J Anderson <REMOVEanderson badmama.com.au> writes:
inline
Barry Carr wrote:
J Anderson <REMOVEanderson badmama.com.au> wrote in
news:bsok83$16s2$1 digitaldaemon.com:
I would like a feature like this in D. I made a game engine
in C++ that would automaticly detect new objects and make
available to the editor and scripting engines. For example,
wanted to make a new type of weapon, I'd simply derive the
class and fill out all the weapons particular info. It would
compiled as a DLL, and the program would automaticly detect
make the weapon available to the editor. Then you'd be able
the weapon in a shop, somewhere in the world or in one of the
creatures (players and monsters). It was vary useful as you
have to touch the engine at all and made things easy to
Users could easily customise the game into anything they
without touching the engine.
The workaround required in C++ to do this was more effort
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
↑ ↓ ← → Ant <Ant_member pathlink.com> writes:
In article <bsok83$16s2$1 digitaldaemon.com>, J Anderson says...
I would like a feature like this in D. I made a game engine last year in
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"
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
↑ ↓ ← → "Mark Brudnak" <malibrud provide.net> writes:
"Ant" <Ant_member pathlink.com> wrote
<snip>
Is this what Mark Brudnak suggested on
"3) Native support for plugin modules"
D/19555
Basically, yes.
<snip>
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as they
don't allow access to objects unless you use COM); streaming in and
creating objects etc. esp. if you're using an OODBMS; any form of data
driven application is extremly difficult to construct without this
facility. Having the ability to create instances dynamically adds an
extra dimension of flexibility to your software at NO extra cost if the
feature is support by the language.
sounds so poethic. but is rather nonsence imho. i had never problems adding
objects with dll's and all. you "think" too much oo. in the end, its all just
binary code to execute. creating objects is just calling a function doing that.
creating them by name only needs a factory wich can get runtime edited.
and that both is very doable and nothing fancy. (but your topic is not really
about that..)
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community
defend this position when they could be petitioning for this feature to
be added? If the facility is there you are not compelled to use it, but
with out it all other options are kludges and workarounds (IMHO). An OO
language should support the ability to create objects anonimously.
why we don't see it? because there is not yet a good example showing us that we
DO need it. there isn't much use in what you described (but thats not what you
want, as it looks like..)
When I used to use C++ the lack of this feature caused me no end of
problems, it was one of the main reasons why I ditched it. Factories are
NOT the answer, as adding new classes to the app means making changes to
the factory. Factories are not orthogonal.
what problems?
And I didn't say D was a scripting language and non of the example
languages I cited were scripting languages either. It is possible to have
this feature in an efficent compiled language with no cost to runtime
performance; esp. in garbage collected language because the gc is going
to take up more time then any extra runtime info will do.
if you want at runtime instantiation of at compile time known objects (and
compile time can be splitted if you create dll's for example), then all you need
is a method to add to a global factory. that is simple doable, there is no
problem with that.
if you DONT want that, you NEED some sort of runtime compilation, a.k.a.
SCRIPTING. and you know what? D (or should i say DMD?) is capable of doing that.
redistributing dmd lets you runtime generate new dll's wich you can load (and
register your new objects with complete new behaviour in the factory:D)
tested, and worked so far so good. issues with the gc exist, yes..
I'm not here to start a language war - I just want to understand why the
C++ community does think this is an important feature, esp when it has
every other feature under the sun crammed in there? And why D, as an
improvement to C++ (which it certainly looks likes), hasn't added this
feature either.
show us its a needed feature.. show us your purpose of it. show us your use of
it. what do you think you want to use it for? we simply don't see it. i'd like
to see it, though. but i see nothing special in it, nor anything that useful in
it. i can run later-added code. oo is just a paradigm. so yes, i can run
later-added oo-code, too.
and you do see that all the languages that have it run in virtual machines? they
are actually scripted then. dunno if you see what you really request. because
its not juse about
Object createObject(char[] name);
if it would be that, easy. its not that. you want scripting (wether you call it
that, or not. you want runtime compilation).
oh, and, COM works great.. just to say that.
and finally that statement again:
It is possible to have
this feature in an efficent compiled language with no cost to runtime
performance; esp. in garbage collected language because the gc is going
to take up more time then any extra runtime info will do.
show us how. don't request, but propose.
and you don't try to diss the gc, do you? i hope not. because then you're very
wrong..
no war intended. just... a battle:D
greetings,
davepermen
↑ ↓ ← → Barry Carr <barrycarr ixian-software.com> writes:
Hi Dave, Antti
It is vital because an application should be a network of autonomous
objects able to react to new situations (within reason) and work with
derived classes without any trouble - as Liskov states. For instance:
loading plugins at runtime (dlls are not adquate for this purpose as
they don't allow access to objects unless you use COM); streaming in
and creating objects etc. esp. if you're using an OODBMS; any form of
data driven application is extremly difficult to construct without
this facility. Having the ability to create instances dynamically adds
an extra dimension of flexibility to your software at NO extra cost if
the feature is support by the language.
sounds so poethic. but is rather nonsence imho. i had never problems
adding objects with dll's and all. you "think" too much oo. in the
end, its all just binary code to execute. creating objects is just
calling a function doing that. creating them by name only needs a
factory wich can get runtime edited.
Thats the first time I ever heard it to be a bad thing to be too "OO".
Alan Kay (the creator of Smalltalk) was right when he said (more or
less): "I invented the term 'Object Oriented' and C++ wasn't what I had
in mind". In my not so humble opinion, procedural code is degenerate, and
closed for extension. How can being too "OO" be a bad thing?
and that both is very doable and nothing fancy. (but your topic is not
really about that..)
I can never understand why the C++ community cannot see this - instead
they bang on about how you don't need it. Why does the C++ community
defend this position when they could be petitioning for this feature
to be added? If the facility is there you are not compelled to use it,
but with out it all other options are kludges and workarounds (IMHO).
An OO language should support the ability to create objects
anonimously.
why we don't see it? because there is not yet a good example showing
us that we DO need it. there isn't much use in what you described (but
thats not what you want, as it looks like..)
Here are two examples for then need to be able to create object of
unknown type at runtime:
1. Delphi and C++ Builder need and use this facility when creating forms
and dialogs at runtime (amongst other objects like DB connections). The
"description" of the form and its consituent components are stored as a
resource within the .exe. The runtime streams in the resource at runtime
to (re)create the form. It is not possible to us a factory in this
situation as the runtime will need to create the components provided out
of the box along with 3rd party component and any user created components
that may be being used - class details a factory could never know. BTW,
C++ Builder relies on compiler extensions and the Delphi runtime to make
this work for C++ Builder apps.
2. Several years ago I wrote an accounts package for the Legal sector in
England (Scottish law is different). A legal accounts package is much the
same as any double entry book keeping system, except that certain monies
have to be seen to be kept seperate to stop fraud. To cut a long story
short, I tried to make this application as dynamic as possible and I
acheived this by making the app data-driven where possible. To this end,
most of the rules about where and how to post money were held in data-
table. Amongst this data was the name of class that represented the form
needed to get the data from the user. Where specialised posting
instructions were needed I employed the strategy pattern, the strategy
classes needed for a transaction were listed in a data-table and created
and iterated through to complete the task. The advantage of this approach
was that I (we) could add transaction types with minium effort and in one
place (orthoganality) knowing it would work. It meant that one point in
the code could create the classes needed to complete a transaction and
still work as more transactions types were added to the application or
extended.
When I used to use C++ the lack of this feature caused me no end of
problems, it was one of the main reasons why I ditched it. Factories
are NOT the answer, as adding new classes to the app means making
changes to the factory. Factories are not orthogonal.
what problems?
All the examples I've seen of factories in C++, and I've looked at a few
of them like Scott Meyer's in Effective C++ and Bjarne's in the wave
book, and they are all closed. You have to keep coming back to them as
you add more classes to your app - this means that they are never stable
as they are always open to change. Now, its been a while since I've
checked this out, things may have moved on since them. Can you point me
to, or show me a contempory factory implementation?
And I didn't say D was a scripting language and non of the example
languages I cited were scripting languages either. It is possible to
have this feature in an efficent compiled language with no cost to
runtime performance; esp. in garbage collected language because the gc
is going to take up more time then any extra runtime info will do.
if you want at runtime instantiation of at compile time known objects
(and compile time can be splitted if you create dll's for example),
then all you need is a method to add to a global factory. that is
simple doable, there is no problem with that.
But the whole point is that you DON'T know at runtime what a class is. A
class could have been added after the main application was compiled and
shipped.
if you DONT want that, you NEED some sort of runtime compilation,
a.k.a. SCRIPTING. and you know what? D (or should i say DMD?) is
capable of doing that. redistributing dmd lets you runtime generate
new dll's wich you can load (and register your new objects with
complete new behaviour in the factory:D)
I am not talking about runtime compilation and you don't need runtime
compilation, except on very rare occasions. If I wanted apps that could
write themselves I'd use Lisp, Scheme or Smalltalk. I'm talking about not
trying to second guess what I will need to create at runtime and allow
some room for future extensions.
Fine, if DMD will allow dynamic compilation then you show me an example
of how you do this and why you would need it. (BTW, .NET will do this
too, via the emit facility).
tested, and worked so far so good. issues with the gc exist, yes..
I'm not here to start a language war - I just want to understand why
the C++ community does think this is an important feature, esp when it
has every other feature under the sun crammed in there? And why D, as
an improvement to C++ (which it certainly looks likes), hasn't added
this feature either.
show us its a needed feature.. show us your purpose of it. show us
your use of it. what do you think you want to use it for? we simply
don't see it. i'd like to see it, though. but i see nothing special in
it, nor anything that useful in it. i can run later-added code. oo is
just a paradigm. so yes, i can run later-added oo-code, too.
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..
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.
↑ ↓ ← → Andy Friesen <andy ikagames.com> writes:
Barry Carr wrote:
1. Delphi and C++ Builder need and use this facility when creating forms
and dialogs at runtime (amongst other objects like DB connections). The
"description" of the form and its consituent components are stored as a
resource within the .exe. The runtime streams in the resource at runtime
to (re)create the form. It is not possible to us a factory in this
situation as the runtime will need to create the components provided out
of the box along with 3rd party component and any user created components
that may be being used - class details a factory could never know. BTW,
C++ Builder relies on compiler extensions and the Delphi runtime to make
this work for C++ Builder apps.
How about the pluggable factory pattern? That's what I use for
situations like this. A three-line factory implementation per class and
it's ready to go.
Hopefully this brief and contrived example will illustrate
how class references work:
type
TMyClass = class
...
public
constructor create; virtual;
destructor destroy; override;
end;
TMyClassReference = class of TMyClass // Declare Class refence type
TMyDerivedClass = class TMyClass
...
public
constructor create; override;
destructor destroy; override;
end;
...
var
ClassRef : TMyClassReference; // Class ref var
myClass : TMyClass;
begin
ClassRef := TMyDerivedClass;
myClass := ClassRef.create;
/* As constructor is virtual, the correct constructor is called and
myClass will hold a reference to an instance of TMyDerivedClass. The line
above it equivallent to this line below. As there are ways of
"calculating" the value of class reference it is possible to therefore
dynamically create an instance without knowing its class at runtime */
myClass := TMyDerivedClass.create;
end;
Interesting. Python allows the exact same thing, though it's merely
emergent behaviour. (types are themselves objects, so you can deal with
them as such)
I don't think it would be very difficult to add this to D. ClassInfo
would simply need to grow a create() or constructor() method that calls
the constructor.
-- andy
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
and the battle goes on.. and gets rather big for this much too small textbox..
anyways.. lets go!
Thats the first time I ever heard it to be a bad thing to be too "OO".
Alan Kay (the creator of Smalltalk) was right when he said (more or
less): "I invented the term 'Object Oriented' and C++ wasn't what I had
in mind". In my not so humble opinion, procedural code is degenerate, and
closed for extension. How can being too "OO" be a bad thing?
if thats the first time you hear that, you have a lot to learn... very lot.
algorithms are independent of objects, and they are the actual major part of
every program. oo is just one paradigm you have to follow, or not, to code. it
solves some tasks nice, others not at all. thats why we have c++, or D, wich
allows for different paradigms.. (generics are hip today, thats why oo-only
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.
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.
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..
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.
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
↑ ↓ ← → Ant <Ant_member pathlink.com> writes:
In article <bsrlgc$2kcv$1 digitaldaemon.com>, davepermen says...
and the battle goes on.. and gets rather big for this much too small textbox..
One of us didn't understand the issue.
(it's probably me, don't worry;)
I thought it was about extending/adapting an application
through external and independent modules that would conform
to some rules - let's say trought an implementation of an interface.
The example of weapons and mosters is easy to understand.
Another example is an IDE where all non core functionalities
are provided externally (CVS access, code browser, what ever)
Another example is an OS kernel that would load specific modules
for different tasks/environments.
how is D able to do that?
(of course we can always start two processes
with an ad-hoc "smart pluggin abstraction" layer between them
and send messages across. But I guess that what
J Anderson calls a work around)
BTW what were Walter and Matthew talking about when replying to Mark's post?
Maybe we can extend this concept and the core application becomes
just the pluggin loader... I bet I could get a pattent on that ;)
how is D able to do that?
Ant
↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bss7ll$ded$1 digitaldaemon.com...
In article <bsrlgc$2kcv$1 digitaldaemon.com>, davepermen says...
and the battle goes on.. and gets rather big for this much too small
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
Can't remember the post or the reply. I was probably talking out of my arse,
as usual.
Can you remind?
↑ ↓ ← → Barry Carr <barrycarr ixian-software.com> writes:
Dave,
I'm going to cut through all this BS. My position is this:
C++ is too static. There are times (and I've cited two good examples)
where you need some runtime dynamicism to reduce coding, improve
reliability and allow an application to adapt to new *SOME* new
situations without falling flat on its face. This is not scripting, IMO,
but the ability keep an application "Closed for modification, but open
for extension" as Robert Martin states. Factories always require
modification and thus break this rule. If you know different then show me
an example factory as proof. If DMD has similar facilities or better, I'd
like to see these too.
I have work long enough with languages with dynamic facilities to know
that a completely static languages are very restrictive and don't
facilitate eligant, workable solutions - you end up having to code round
situations to half get what you want. In my experience, the more dynamic
a language is the more power the developer has at his or her disposal and
the quicker they can get the job done. There is big role for compile-time
facilities such as templates or generics as these can improve runtime
performance and type safety, but these are still closed solutions.
Furthermore, there is no reason to use procedural code anymore - OO
technologies provide a much richer way of modeling problems and provide
robust, extensible solutions to them. Objects implement algorithms to
provide these solutions, not the other way round.
Virtual Machines are not uber-scripting languages, they are proper,
complete languages in there own right and a realisation in the industry
that a more dynamic runtime environment is required to provide timely,
robust solutions.
Now, if you don't agree with any of this, which you clearly don't -
explain your counter arguments and cite examples.
And I still want to know what if D has any dynamic facilities.
Cheers
Barry Carr
Ixian Software Components Ltd.
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
just a quick question before i go to bed:
my exe scans the folder for all .plugin files, wich are renamed .dll files, wich
get loaded, and each has a "describe" function in, wich returns name and
function pointer to a creator function of the type in there (wich is derived
from a base interface, a.k.a. IPlugin
then i can just code new plugins, compile as dll, and add to the folder of the
exe.. and voilą, the exe can create objects of it..
i've made that way "app wizards", wich could create different types of editors
(leds could use it for different project types, for example).
no need to change the factory in the exe at all. this is what i stated several
times now, and should finally answer this statement:
Factories always require modification and thus break this rule.<<<<
and about oo..
how does
max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is a
different part..
programming happens on different layers. oo is one. procedural is another.
generic another. patterns fit onto a top layer above them.
only if you know to use all, you are really good at creating reusable code, that
is dynamic even while static compiled. every c++ programer knows this. only
brainwashed java/.NET programmers still think you always have to create a class
around a static method.
do i really have to code that up? well then.. if i have time, tomorrow at work..
else.. next year:D
or is that still too static?
and you haven't answered my question:
if you know the type at code time (or a base of it, like IPlugin), then you can
code with it. but then you don't need runtime object creation of unknown type,
factory is enough.
if you don't know the type at code time, then how do you code with it? eighter
with some script at runtime, or.. how?
you haven't answered that basic question. wich is the whole "why do i want to
create an object of unknown type?".
i simply don't understand what i should be able to use it for?
and sorry for being that ignorant btw.. i simply don't get it. and i want to get
it. but i don't know how yet.. you have to help me.. some applications showing
how it adds really would be useful.
and vm's are simply basecode to run scripts. binary scripts, but still scripts.
↑ ↓ ← → qw <qw_member pathlink.com> writes:
"why do i want to create an object of unknown type?".
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.
↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:
"qw" <qw_member pathlink.com> wrote in message
news:bst9qn$22k2$1 digitaldaemon.com...
"why do i want to create an object of unknown type?".
Or, the object descends from TComponent.
Then it's not unknown, is it? Or am I missing something
Being a TComponent, you can obtain a
list of properties. You obtain the properties and it's types and show them
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,
I other words, you would have to build the whole framework from scratch.
parts may be easy, others are clearly not.
↑ ↓ ← → Matthias Becker <Matthias_member pathlink.com> writes:
"why do i want to create an object of unknown type?".
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;
}
↑ ↓ ← → "davepermen" <davepermen hotmail.com> writes:
if you knew oo you would knew that this is exactly what oo is about: you get
a baseclass reference if you don't need more.
you know its a MyClass, or derived from it. so you know how to use it. do
you need more?
if so, just try to cast it to mroe..
MyDervidedA fooA = cast(MyDerivedA)foo;
if(fooA) {
// hey, its a MyDerivedA, or a derived of MyDerivedA!!
}
but if you don't know the type you WANT it to be, you have no clue on how to
USE it in code. you know how to use MyClass, as well as MyDerivedA. so you
just cast to the one you expect it to be. if it is that (or derived from
it), you can use it as that.
but still, the main point is, you should not NEED that.
if you think you need it (and while you're 99% wrong then), you even can
check it. dynamic_cast in c++ works the same, and does the job as nice.
"Matthias Becker" <Matthias_member pathlink.com> schrieb im Newsbeitrag
news:bvd9hr$2c9u$1 digitaldaemon.com...
"why do i want to create an object of unknown type?".
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;
}
↑ ↓ ← → Matthias Becker <Matthias_member pathlink.com> writes:
In article <bvdhgs$2qm7$1 digitaldaemon.com>, davepermen says...
if you knew oo you would knew that this is exactly what oo is about: you get
a baseclass reference if you don't need more.
you know its a MyClass, or derived from it. so you know how to use it. do
you need more?
I just wanted to point out that you don't know the type without reflection. Of
course you don't need too know it. That's what I like about OO.
↑ ↓ ← → "davepermen" <davepermen hotmail.com> writes:
but what gain would you have with reflection? because without casting it to
a type you GUESS it is, you can not USE it.
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
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
course you don't need too know it. That's what I like about OO.
↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:
To me that seems a perfect example of interface-based programming. You know,
separating interface from implementation. That's a core OO concept, btw.
(Sorry for sarcasm, but your example does not serve your purpose)
"Matthias Becker" <Matthias_member pathlink.com> wrote in message
news:bvd9hr$2c9u$1 digitaldaemon.com...
"why do i want to create an object of unknown type?".
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;
}
↑ ↓ ← → "Phill" <phill pacific.net.au> writes:
I am by no means a guru at programming, I am Sun Certified Java programmer
thats about all, Im not a
professional, Ive only done one contract, but even I
can grasp the concept of OO.
You said earlier that Barry had a lot to learn, I believe
that you are the one that has a lot to learn(about OO
anyway) and maybe listening is a great part of learning.
wow I cant believe that you can say this:
===========================
"how does
max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is
a
different part..
programming happens on different layers. oo is one. procedural is another.
"
===================
that statement can return the contents of the greater one of two of the
Objects data fields.
You use procedural inside Objects on their data fields....
Phill.
"He who asks is a fool for five minutes, but he who does not ask remains a
fool forever."
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
just a quick question before i go to bed:
my exe scans the folder for all .plugin files, wich are renamed .dll
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
from a base interface, a.k.a. IPlugin
then i can just code new plugins, compile as dll, and add to the folder of
exe.. and voilą, the exe can create objects of it..
i've made that way "app wizards", wich could create different types of
(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
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
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
is dynamic even while static compiled. every c++ programer knows this.
brainwashed java/.NET programmers still think you always have to create a
around a static method.
do i really have to code that up? well then.. if i have time, tomorrow at
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
code with it. but then you don't need runtime object creation of unknown
factory is enough.
if you don't know the type at code time, then how do you code with it?
with some script at runtime, or.. how?
you haven't answered that basic question. wich is the whole "why do i want
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
it. but i don't know how yet.. you have to help me.. some applications
how it adds really would be useful.
and vm's are simply basecode to run scripts. binary scripts, but still
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
simple answer: the main 'problem' with oo is, you can map it to everywhere.
but just because it happens to work with objects, its not object oriented. in
java, simply "everything" is called objectoriented. a function/method still
isn't. oo is a design on how to structure your objects, parts of oo is about
inheritance, or, what IS an object. the other is about encapsulation, or what
does an object LOOK like.
sure, every algorithm processes data. there is no "ergo algorithms are object
oriented". max doesn't bother AT ALL about objects. it is a generic working
algorithm. works with everything. i don't call an int an object.. i primarily
call it a number..
its a way of thinking. oo-pure thinking is way too restricted. thats all. but
you _can_ of course call everything oo. you can as well call everything
procedural if you want, as in the end, hw only works procedural anyways. your
obj.func() is just a a func(obj_handle), so what?
oo helps a lot. other approaches can help in other situations even more.
(oh, and classes are not oo, but i guess you're well avare of that.. if not, you
definitely have to learn other languages than java.. immediately)
In article <bstcfk$26ic$1 digitaldaemon.com>, Phill says...
I am by no means a guru at programming, I am Sun Certified Java programmer
thats about all, Im not a
professional, Ive only done one contract, but even I
can grasp the concept of OO.
You said earlier that Barry had a lot to learn, I believe
that you are the one that has a lot to learn(about OO
anyway) and maybe listening is a great part of learning.
wow I cant believe that you can say this:
===========================
"how does
max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is
a
different part..
programming happens on different layers. oo is one. procedural is another.
"
===================
that statement can return the contents of the greater one of two of the
Objects data fields.
You use procedural inside Objects on their data fields....
Phill.
"He who asks is a fool for five minutes, but he who does not ask remains a
fool forever."
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
just a quick question before i go to bed:
my exe scans the folder for all .plugin files, wich are renamed .dll
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
from a base interface, a.k.a. IPlugin
then i can just code new plugins, compile as dll, and add to the folder of
exe.. and voilą, the exe can create objects of it..
i've made that way "app wizards", wich could create different types of
(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
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
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
is dynamic even while static compiled. every c++ programer knows this.
brainwashed java/.NET programmers still think you always have to create a
around a static method.
do i really have to code that up? well then.. if i have time, tomorrow at
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
code with it. but then you don't need runtime object creation of unknown
factory is enough.
if you don't know the type at code time, then how do you code with it?
with some script at runtime, or.. how?
you haven't answered that basic question. wich is the whole "why do i want
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
it. but i don't know how yet.. you have to help me.. some applications
how it adds really would be useful.
and vm's are simply basecode to run scripts. binary scripts, but still
↑ ↓ ← → "Phill" <phill pacific.net.au> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bstmf8$2lfa$1 digitaldaemon.com...
simple answer: the main 'problem' with oo is, you can map it to
but just because it happens to work with objects, its not object oriented.
java, simply "everything" is called objectoriented. a function/method
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
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
oriented". max doesn't bother AT ALL about objects. it is a generic
algorithm. works with everything. i don't call an int an object.. i
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.
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.
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
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
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
a
different part..
programming happens on different layers. oo is one. procedural is
"
===================
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
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
get loaded, and each has a "describe" function in, wich returns name
function pointer to a creator function of the type in there (wich is
from a base interface, a.k.a. IPlugin
then i can just code new plugins, compile as dll, and add to the folder
the
exe.. and voilą, the exe can create objects of it..
i've made that way "app wizards", wich could create different types of
(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
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.
is a
different part..
programming happens on different layers. oo is one. procedural is
generic another. patterns fit onto a top layer above them.
only if you know to use all, you are really good at creating reusable
is dynamic even while static compiled. every c++ programer knows this.
brainwashed java/.NET programmers still think you always have to create
class
around a static method.
do i really have to code that up? well then.. if i have time, tomorrow
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
code with it. but then you don't need runtime object creation of
type,
factory is enough.
if you don't know the type at code time, then how do you code with it?
with some script at runtime, or.. how?
you haven't answered that basic question. wich is the whole "why do i
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
to get
it. but i don't know how yet.. you have to help me.. some applications
how it adds really would be useful.
and vm's are simply basecode to run scripts. binary scripts, but still
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
In Java methods are not called Objects.
rather restricted.
my understanding of encapsulation is when a classes
variables are made private and they have public get and set methods.
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.
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.
oriented.
↑ ↓ ← → "Phill" <phill pacific.net.au> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsu539$9fh$1 digitaldaemon.com...
In Java methods are not called Objects.
rather restricted.
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.
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
In article <bsvdi8$22ug$1 digitaldaemon.com>, Phill says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsu539$9fh$1 digitaldaemon.com...
In Java methods are not called Objects.
rather restricted.
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
↑ ↓ ← → Matthias Becker <Matthias_member pathlink.com> writes:
when you use these Objects to do tasks and make them Polymorphic then
it is OO.
Do you agree on that?
newbe or he codes in Java.
↑ ↓ ← → Matthias Becker <Matthias_member pathlink.com> writes:
oo is a design on how to structure your objects, parts of oo is about
inheritance, or, what IS an object. the other is about encapsulation, or
does an object LOOK like.
my understanding of encapsulation is when a classes
variables are made private and they have public get and set methods.
This understanding is simply crap. This is just plain stupid. Sorry fore being
that rude, but that's the way it is, at least if we are talking about
objectorientation.
I've seen this by many java-coders. Just make the variable private and write
public get and set routines for it.
Objectorientation is intended to abstract real objects. Encapsulation shoudl be
used to distinguish between implementation (what isn't interesting for the usage
of the object) and the "interface" which describes what the object can do. If
you write a get and set routine for a privat variable you loose the abstraction
completly. But abstraction is why you use objectorientation.
sure, every algorithm processes data. there is no "ergo algorithms are
oriented". max doesn't bother AT ALL about objects. it is a generic
algorithm. works with everything. i don't call an int an object.. i
call it a number..
And what is a number? Some kind of abstract object. So it's not wron using it
like, ... no ...., as an object. It depends on the situation whether this view
is usefull or not. In a pure mathmatical problem it would be stupid. If the
whole problem is about simple mathmatical problems it is somehow stupid to use a
objectorientated language, as a functional one would fit much better.
I dont call variables Objects either.
Could you please code C++ for one day. There variables represent object all the
time, as all objects have value-semantics by defualt (opposed to
reference-semantic as you're used to as a java-coder).
I agree that Classes arent Objects, but Instantiated classes are Objects.
And I would love to learn other languages and intend to eventually, D in
fact, which is no doubt why I
am here.
this is very common.
↑ ↓ ← → "Matthew" <matthew.hat stlsoft.dot.org> writes:
I am by no means a guru at programming, I am Sun Certified Java programmer
thats about all, Im not a
professional, Ive only done one contract, but even I
can grasp the concept of OO.
You don't need to qualify like this. Everyone gets a shot on this NG. :)
You said earlier that Barry had a lot to learn, I believe
that you are the one that has a lot to learn(about OO
anyway) and maybe listening is a great part of learning.
wow I cant believe that you can say this:
===========================
"how does
max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it
a
different part..
programming happens on different layers. oo is one. procedural is another.
"
===================
that statement can return the contents of the greater one of two of the
Objects data fields.
You use procedural inside Objects on their data fields....
Hmm. This is a bad example on which to be arguing for OO, especially wrt D.
If a and b are related polymorphically, and provide different overloads of
their comparison operators, then the result can depend on the order in which
a and b are expressed to the function.
This is, in fact, a great example of how generics and non-member overloads
are important.
Phill.
"He who asks is a fool for five minutes, but he who does not ask remains a
fool forever."
How about: "He who learns from one who is learning drinks from a running
stream"?
↑ ↓ ← → "Phill" <phill pacific.net.au> writes:
see this URL, Java can load the classes(Objects)with a lot less trouble:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html
Phill.
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
just a quick question before i go to bed:
my exe scans the folder for all .plugin files, wich are renamed .dll
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
from a base interface, a.k.a. IPlugin
then i can just code new plugins, compile as dll, and add to the folder of
exe.. and voilą, the exe can create objects of it..
i've made that way "app wizards", wich could create different types of
(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
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
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
is dynamic even while static compiled. every c++ programer knows this.
brainwashed java/.NET programmers still think you always have to create a
around a static method.
do i really have to code that up? well then.. if i have time, tomorrow at
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
code with it. but then you don't need runtime object creation of unknown
factory is enough.
if you don't know the type at code time, then how do you code with it?
with some script at runtime, or.. how?
you haven't answered that basic question. wich is the whole "why do i want
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
it. but i don't know how yet.. you have to help me.. some applications
how it adds really would be useful.
and vm's are simply basecode to run scripts. binary scripts, but still
↑ ↓ ← → davepermen <davepermen_member pathlink.com> writes:
and that does say? it is still possible to just have an extern(D) IMyBaseType
createType(SomeParams) { return new MyDerivedType(SomeParams); } in a dll, and
the class..
most the time you don't need more. you need only if you want at runtime
inspection of the actual members and all. but how often do you need that, i'm
curious. and as far as i know only when you want to bother with that runtime
inspection, a.k.a. do something at runtime with it. and that, by default, means
scripting. (scripting == creating new program flow at runtime.. a console in a
game is a small scripting engine, for example.. it can be invisible, behind a
gui, too, and is still there).
i KNOW java makes it nicer. but its not MUCH code. and its definitely DOABLE.
there is no need to get a class object, to only call myClass.new() on it. if you
know what interface you want, you can just have a factory doing it. (the above
given function IS a factory..).
i'm still waiting to see the use..
plugins have their use. but neighter c++ nor D have ANY problem with creating
objects in dll's that are of some basetype, and the dll loader only knows the
basetype. this is a nobrainer. tons of applications use that. they don't even
all know objects yet..
there IS a problem currently with D and plugins (a.k.a. dll's). and that is,
sharing of gc collections. this is not yet possible in a clean way.. possibly
you have to just derive the objects from com, so that they don't get gc
collected anyways.. have to test that..
In article <bstct1$273q$1 digitaldaemon.com>, Phill says...
see this URL, Java can load the classes(Objects)with a lot less trouble:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html
Phill.
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bsstda$1guh$1 digitaldaemon.com...
just a quick question before i go to bed:
my exe scans the folder for all .plugin files, wich are renamed .dll
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
from a base interface, a.k.a. IPlugin
then i can just code new plugins, compile as dll, and add to the folder of
exe.. and voilą, the exe can create objects of it..
i've made that way "app wizards", wich could create different types of
(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
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
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
is dynamic even while static compiled. |
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next