Interface question

[Charles D Hixson]

David Medlock wrote:
> Charles D Hixson wrote:
>> xs0 wrote:
>>
>>>...Ignore this if I am misreading you - David)
> 
> I don't quite 'get' what you are trying to accomplish(not technically 
> but in a design sense).
> 
> Unless you are attempting to add compiled classes at runtime, I would be 
> surprised if D could not accomplish what you are doing.
> 
> To create an object which has a known constructor, use a template 
> function/object....but there is a better way.
> 
> Have your objects created with no argument constructors then configured 
> using a common method.  I have a text format(XML lite) I use in which 
> each node is a 'constructor' for an object.  Then the children of the 
> node are passed to the config() method of the object.  In this way I can 
> have many similar objects which are combined in different ways.
> 
> Is this close to what you are trying?
> -David
The problem is, when the object is being read in from the 
file, the type of the object (on the file) determines the 
desired type of the created object.  This appears to require 
the kind of run-time parsing that Python, Smalltalk, and Ruby 
have...and that D doesn't.  I though I'd find away around it, 
but the only way I found involved storing everything in a 
common format (very inefficient) and making all the calls 
through multiple layers of indirection.  If I do all THAT I 
might as well use Python, which at least doesn't fight me 
every step of the way.

This just isn't something that D is designed to do.  You CAN 
do it, but it's not natural to the language, so you need to 
fight it every step of the way.  It would probably literally 
be more efficient to do this in Python, because in Python a 
lot of the steps that I need to do have been hand optimized by 
people who spent lots of time figuring the optimizations.  It 
would *CERTAINLY* be lots easier.  (I can create an object by 
merely unpickling it.  Each class will just need to implement 
the __getstate__ and __setstate__ methods.)  And if I try to 
do something with an object that hasn't been defined, I can 
catch it with an error handler, and figure out what I need to 
do differently...which I can do at run time, when I can 
examine what the class that I'm trying to handle is, but can't 
do at compile time, because the class hasn't been read in.  (A 
lot of the time what I'll want to do is return a message that 
means, approximately "I'm sorry Dave, I can't do that." :-)
I won't want to abort the process just because a particular 
kind of object can't do that.  Your brain doesn't dump memory 
when you encounter a parsing error...you recover.  You don't 
WANT a hard fault.  And you can't predict all the kinds of 
sensory stimuli you will receive.

I can't actually be too specific about what I need in detail, 
because I'm still feeling my way along.  I was hoping to use D 
because it's much more efficient ... if you can fit your 
requirements into what it is designed to do.  I was going to 
start off coding a simple neural net...which I could have done 
in D, but that is intended to be only a small part of the 
project...and the major part requires the additional 
flexibility in the handling of persistence.

It's no big thing.  Every language has it's strong points and 
it's weak point.  D has more strong points than almost any 
other...but they don't fit *all* of my needs.  (If the 
interface between D and Python is reactivated, I may end up 
recoding lots of modules that will fit the D model into D.  I 
*FAR* prefer it to C, or even to Pyrex [my current fallback if 
I need more efficiency].)