Re: [Templates] Design question

> Buddy, with all due respect, it seems to me that your "wheel" is not

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
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates