[DGD] Re: Auto object question

[Gregory D Lewis]

> > For the purposes of answering my question, let's assume that the entire
> > code base consists of 2 functions and 1 variable.  This is asinine, I
> > know, but it makes asking the question a lot easier.  My question is
> > this:  Without bringing LPC -> C into the picture, are there any
> > performance gains in having that code reside in the auto object as
> > opposed to another class that has to be explicitly inherited? 

I wouldn't have thought so, but I might be wrong ;).  Wow, thats useful ;).
But to do otherwise you have to assume that beneath the surface of DGD the
auto-magic inheritance of the auto object also makes calling of its functions
faster than those from an explicitly inherited objecct.  I would tend to think
this isn't in fact the case.  Dworkin can of course say for sure.  Someone
else who may have some practical information is Erwin Harte -- I know he split
up some of the array and mapping from the auto object to put in separate 
objects that were separately inherited on Caradon.  I don't believe he's
switched back so its looking like if there is performance degradation then
it isn't very noticeable.

> I was wondering that too coz I currently have lots of neat functions
> which I tend to class into libraries (eg: all string related
> functions go into string.h which gets #include'd by the autobj).
> Would it be a better idea to make that set into a standalone 'library'
> object and produce a header file consisting of #define str_trim(s)
> "/sys/lib/string"->str_trim(s)?

Yik.  You would definitely take a performance hit from making it into a
call_other.  You also may have an object which loads while critical objects
for its operation don't.  Neither of these problems will occur if you inherit
/sys/lib/string rather than using defines in a header file.  Nor will your 
code be as obfuscated.  

> Well, so far, my thoughts have gone along the lines of:
> 
> a) it'll be easier to maintain/update on the fly

If you update it and make a mistake then a whole bunch of your code stops
working until its fixed.  This problem gets avoided if you either inherit it
or clone an instance as a member variable.

> b) more object orientated (I think)

Ummm, not really (I think).  Right idea but I don't believe your proposal of 
it is the best implementation for splitting the auto obejct up.

> c) looks nice
> d) performance might take a hit

It will.  An internal function call is faster than a call_other.

> > The design problem/issue that I'm running into is that I currently have
> > a subset of functionality in the auto object which works great.  That
> > functionality, however, is not used by every class.  I'd like to extract
> > that functionality into a separate class that other classes can
> > explicitly inherit if the functionality is needed.  As a specific
> > example, I have object inventory and trigger (add_action()-like
> > functions - see previous posts in this list)  functionality in the auto
> > object.  I'd like to extract it because we have several hundred bin
> > commands, soul commands, and verbs that won't ever touch that kind of
> > stuff.  Daemons fall in the same boat, too.  My main concern is, though,
> > that for those objects that <do> use the inventory and trigger
> > functionality, will they take a huge performance hit in
> > speed/overhead/etc in having to explicitly inherit the appropriate class
> > to gain that functionality? 

Well, if my reasoning above is correct, I suspect there would be no
performance hit.  

Personally, I've come to the opinion that my auto object will do what it
_needs_ to do plus what cannot easily be implemented elsewhere and everything
else will go into appropriate modules/classes.

> 
> On a completely different tangent:
> Would it be too hopeful to see a future version of DGD support multiple
> binary listening ports?

That would be the networking kfuns package, which Dworkin has stated he will
never integrate into DGD proper.  I guess there is a chance he will add the
possibility of designating multiple telnet or binary ports though.

-- 
Greg Lewis                              Applied Maths Department
Email : glewis at maths.adelaide.edu.au    University of Adelaide
--
Seminars, n.:
	From "semi" and "arse", hence, any half-assed discussion.



List config page:  http://list.imaginary.com/mailman/listinfo/dgd