liquid, i''m just not sure I understand which side of which fences your on ...

ok, I understand that you are saying current reuse is worlds behind what is imaginable ... and i completly agree ...

and then we talk about it for a second, and you begin saying that the people DO need to bother with custom networking code inside there engines, and spend more time and thought on it than they do currently ... hmm

(seems like a step backwards to want them to spend MORE thought, instead of find a way to let them spend less and still get better results .. isn''t that what we''re talking about - how to get MORE ADVANCED results, with less worry about unexpected interactions) Isn''t THAT what LARGER component reuse means, to get chunks that don''t need to be woven together as much manually for them to get a job done? (as much, is still relative of course - cause if it could be done automaticly, it really wouldn''t need to be done at all)

My statement about the AI brain and FileStream was that it is more benificial to have a STEP UP for all software developers, than a BIG STEP UP for just AI ... that''s all i was saying about that ...

Now here''s the ONLY section of your post that I absolutely completely 100% and more stand against:

"I''m only going to say it once: Not possible. Communication is vital to have components which mesh well. That''s the whole problem with component reuse. Certainly, you can build best-of-breed components easily. They will do one thing well. They will also be useless garbage when you try to combine them with other systems. I don''t have to conjecture about this."

What I am saying (which is also what I thought you we''re saying about the idea of just dropping in a large level brain component) ... is that not only MUST THIS BE POSSIBLE, but it is ESSENTIAL to getting any advancement or large scale reuse accomplished ...

Of course a product builder must understand the needs of his customers, no matter at what level of the chain we are talking about ... but he shouldn''t and MUST NOT need to understand his customer''s other vendors, nor their client''s, nor any other entity in the relationship ... if they do need that, then reuse or generalization is impossible ...

And do NOT say that reuse is not possible without such things ... then HOW would something like XML come to be "the" universal data communication medium? They didn''t need to understand my uses of XML to build me a great library ... and how did Knuth write chapters about Sorting algorithms ... from FUNDAMENTAL PRINCIPLES ... great software comes from being the complete embodyment of a very small set of fundamental properties or roles.

I have a logging library I originally wrote over 6 years ago, and still use to this day. And the improvements I have made to it since the first version are very rarely of the type that has anything to do with my code which is using the lirbary, but comes completely and totally from me analyzing what a Logging library SHOULD BE, fundamentally, no matter how it is used. This is how come by BeOS embedded application at my last job, my DirectX game at the job before, my side projects, and my friend''s personal projects all use this one Logging library ... because it is what it should be, WITH NO REGUARD to a particular user''s need - only to the general definition of it''s role. This same library''s design also mapped perfectly to my new job''s C# .NET project as well (but of course it must be reimplemented on the new platform).

I also have a game object framework which I thought would work well for turn based strategy games ... but when I wrote it as the general game object management system, it ended up being so generally usefull it is now misnamed ... cause I use it for my NON-GAME duplicate file removal software ... because it is simply an abstract object management and access framework (with features like query, lifetime management, persistence, etc) .. you could think of it as a very simple core of a C++ object database ...

THESE are the kinds of things that move the world forward (although I don''t mean mine specifically, they aren''t THAT good ... yet - but I mean, GENERAL PURPOSE programming objects, be they single functions, function libraries, classes, class libraries, applications, paradigms, langauges, models, or frameworks ... the next step if for people to create a FRAMEWORK that allows the plugging in of different components more easily and more completely than today ... and all we need are small steps at a time.

We are already halfway there ... TODAY I can open up MySQL Control Center and create a new database, and immediately begin DESIGNING / PROTOTYPING a game system in terms of it''s data model ... or I can start from the another point in the triangle and begin by modeling it''s Interfaces, or by drawing use cases and sequence diagrams ... programming isn''t really hard anymore, it''s only as confusing as we make it (and MY BOSS makes it VERY confusing) ... by placing artificial limits on ourselves and our tools, or choosing to do something the complicated and messy way, over the clear and complete way.

I don''t know why I went down that avenue ... I guess I went off topic, oh well ... I''m leaving it in for it''s own value (or lack thereof) ...

Basically I just want to express my disagreement with NOT building reusable component and systems, and wanted to express MY OPINION that the best way to do so is to make GENERAL PURPOSE solutions for the ABSTRACT use, not special cases for specific uses ...

Mybe it''s just me, I''m just a library writer at heart.

Xai:

Just to say it, I''m on neither side of the fence. I don''t have that simple a worldview, not by a long shot.

You misunderstand me. I don''t mean these things aren''t desirable. But they''re not possible. A component which is overgeneralized is useless in a competitive market. I am, at this moment, certain that for most kinds of organizations, Oracle is a wonderful RDBMS. Compared to its competitors it''s a piece of shit for the things I need it for (infrequent, short transactions, specifically), however, and I despise it for that reason.

Let''s take an example: A component like a brain is useful in that it should be drop in and forget. Problem is, your map data has to be transformed into input it can understand, which means either preprocessing or dynamic mapping of your map formats to the brain inputs. Your unit movement has to recognize the brain outputs. Your graphics and/or physics engine has to deliver collision information to it. Your networking code has to deliver its state or some subset thereof. If these systems are written together, they can usually talk efficiently. But that is not the proposition that was originally made vis a vis components, ergo that is not the case under discussion.

Component reuse would be great, but the reason why the higher-level object system "Framework" arises so frequently is because components are relatively useless in isolation, and impossible to get "right" in general.

ld