Re (tilly) 1: Why are you even bothering to do it that way?!?

Someone who is aware of how to write tie implementations had better be aware of how to write an object. And someone who wanted to avoid tie for performance reasons is going to be unlikely to want to use an object in the same place since the majority of the slowness in tie is in the method lookup.

Note that Perl 5.8 is supposed to do a lot to fix the issue, but current versions of Perl have a performance headache while running OO code. (Not that that is normally an important thing to factor into a decision about whether or not to use an OO design...)

Comment on Re (tilly) 1: Why are you even bothering to do it that way?!?

Replies are listed 'Best First'.
The proof is in the pudding, my friends by dragonchild (Archbishop) on Aug 09, 2001 at 17:19 UTC
Someone who is afraid of the performance penalties for using the "best" algorithms is someone who, in my humble opinion, is suffering from premature optimization. Until you have the system fully up and running and have run benchmarks and heard user complaints, you cannot know that method A is too slow! All you have is theory and, you know what? The best theory and $3.29+tx will get you a grande cafe mocha. ------ /me wants to be the brightest bulb in the chandelier! Vote paco for President!	[reply]
Re (tilly) 1: The proof is in the pudding, my friends by tilly (Archbishop) on Aug 09, 2001 at 19:01 UTC
I already pointed out that performance issues are usually irrelevant in the question of whether to choose an OO design. However algorithms are also often irrelevant in whether to choose an OO design. Generally speaking you can write the same algorithms in any programming paradigm. OK, so some of them come more naturally in one paradigm than another, but the ones that come most naturally in an OO design are often not particularly efficient. Quite the contrary in fact. For instance your memoizing object is the same algorithm as using an access function that memoizes its return. And using Dominus' Memoize module takes less setup work. Now programming paradigms have a huge effect on overall program design. They affect how easy it is to swap out one algorithm for another (in obvious and not so obvious ways). I am not saying that all paradigms are created equal. (OTOH I think that which one is "best" depends on circumstances.) But in general programming people who think that raw performance is a good reason for them to choose one paradigm over another are generally wrong. And likewise decent paradigms are not distinguished by what algorithms they can express. (Now ease of expression is a different story...)	[reply]