Stefano Masini wrote: > On 10 Sep 2005 02:10:59 EDT, Tim Daneliuk <[EMAIL PROTECTED]> wrote: > >>As someone who implemented their own configuration mini-language >>with validation, blah, blah, blah >>(http://www.tundraware.com/Software/tconfpy/) > > > Well, a configuration mini language with validation and blahs is not > exactly what I would call _simple_... :) so maybe it doesn't even fit
It's actually not *that* complicated. Then again, the code is not as elegant as is might be. > >>1) The existing tool is inadequate for the task at hand and OO subclassing >> is overrated/overhyped to fix this problem. Even when you override >> base classes with your own stuff, you're still stuck with the larger >> *architecture* of the original design. You really can't subclass >> your way out of that, hence new tools to do old things spring into >> being. > > > That's true, but usually only when the original design if too simple > comparing to the complexity of the problem. Instead a very general > solution can usually be subclassed to easily handle a simpler problem. > You still have to actually understand the general and complex design > in order to be able to write subclasses, so maybe one can be tempted > to punt on it, and write its own simple solution. But in this case it The problem is that for a lot of interesting problems, you don't know the "generic" big-picture stuff until you've hacked around at small specific examples. This is one of the deepest flaws in the gestalt of OO, IMHO. Good OO requires just what you suggest - and understanding of generics, specific applications, and just what to factor. But in the early going of new problems, you simply don't know enough. For the record, I think Python is magnificent both in allowing you to work quickly in the "poking around" stage of things, and then later to create the more elegant fully-featured architectures. One other point here: In the commericial world, especially, software tends to be a direct reflection of the organization's *processes*. Commercial institutions distinguish themselves from one another (in an attempt to create competitive advantage) by customizing and tuning these business processes - well, the successful companies do, anyway. For example, Wal-Mart is really a supply chain management company, not a consumer goods retailer. It is their supply chain expertise and IT systems that have knocked their competitors well into 2nd place. And here's the important point: These distinguishing business processes are unique and proprietary *by intent*. This means that generic software frameworks are unlikely to serve them well as written. I realize this is all at a level of complexity above what you had in mind, but it's easy to forget that a significant portion of the world likes/needs/benefits from things that are *not* particularly generic. This is thus reflected in the software they write. >>2) It's a learning exercise. > > > Well, so we might as well learn a little more and rewrite os.path, the > time module and pickle. Right? :) I'm not deeply committed to that level of education at the moment :P > > >>3) You don't trust the quality of the code for existing modules. >> (Not that *I* have this problem :-p but some people might.) > So, let's talk about a way to more effectively present available > solutions to our good programmers! :) Grappa? -- ---------------------------------------------------------------------------- Tim Daneliuk [EMAIL PROTECTED] PGP Key: http://www.tundraware.com/PGP/ -- http://mail.python.org/mailman/listinfo/python-list