Re: [Templates] Design question

>

Again, treating hashes and arrays the same is a Bad Idea.
Implementation or no ... it's a Bad Idea ... because Data is Dumb. And
the fact that your code worked for 3 years prior means absolutely
nothing now if it don't work no more. Because now is what really
matters.

My boss Eduardo recommends the Facade Pattern, not the Factory
Pattern. Google it and good luck, i fear you have work ahead of you
... and next time hopefully you will not paint yourself into a corner.

At any rate ... use DBI's { Slice => {} } and save yourself headaches. 

jeffa

On Thu, 01 Jul 2004 12:11:05 -0400, Buddy Burden <buddy@xxxxxxxxx.xxx> wrote:
> 
> 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
> 

        -- 
        jeffa

_______________________________________________
templates mailing list
templates@xxxxxxxxxxxxxxxx.xxx
http://lists.template-toolkit.org/mailman/listinfo/templates