Jeffa,
Buddy, with all due respect, it seems to me that your "wheel" is not exactly round, at least not as round as picking another solution.
With all due respect, my wheel has been rolling along for several years now with zero problems. It's only when I rolled smackdab into TT2 that I hit a snag. <s>
And, actually, to bring it back to TT2 for a moment, I was thinking that there's really nothing wrong with TT2 checking for overloaded derefs in addition to all the other stuff it checks for. This might be beneficial to other objects that utilize overloading as well. It seems like it would be pretty easy to implement; if anyone else agreed with me that it sounded like a good idea, I'd be happy to take a crack at it.
Personally, i avoid objects that treat hashes and arrays the same ... sure it might make your code "cooler" ... but's it not exactly rational. After all, why is there a distinction between hashes and arrays in the first place?
It's not about being "cooler". It's about having a single structure that does what I need it to do. Before I created my little object, my code was littered with converting arrays into hashes, or hashes into arrays. Now the code is much cleaner. Cleaner code is more maintainable code. And that's all I really care about.
Sure there's a dinstinction between an array and a hash. There's a distinction between a vector and a stack too, but that doesn't mean that one object can't be both; it happens all the time. It's obvious that a row in a database can be viewed as either an array or a hash: that's why all the DBI functions have two versions.
And didn't we discover that pseudohashes were not a great idea after all?
Personally, I believe that that's because of implementation issues. Certainly I know that when I tried to use pseudohashes to solve this problem years ago, the only reason it didn't work was because the key index was in the zeroth element of the array. Thus, a pseudohash was a great hash, but it wasn't a very good array: you couldn't do join()s or many other things without constantly slicing it. And that extra clutter more than canceled out the clutter you saved by not having to constantly convert it. And that's (indirectly) what led to me inventing the DataRow in the first place.
Either you need a hash or you need an array ... why not serve up the proper datastructure instead of trying to guess what it is in your code?
Well, _my_ code never has to guess. :-) TT2, because it wants to always Do The Right Thing(tm), is guessing. And I'm certainly glad it does it that way--I think it's a brilliant interface design--but it happens to be causing me a problem in this particular situation.
But, again, I fear that we're taking up too much of the time on the TT2 list with an abstract discussion that most folks won't care about. If we want to keep debating the usefulness of my object (which I certainly don't mind--design debates keep programmers on their toes), maybe we should take it over to PerlMonks or something.
-- Buddy
_______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
