Re: Function caching...

At 15:48 12/12/2000, Ulf Wendel wrote:

dangerous features: Looking at http://www.phpbuilder.com/columns/peter20001107.php3 shows me people do not even understand the usage of OO. Wouldn't it be better to throw all the OO stuff away as people do not know how to use it? Using OO in a wrong way, they could slow down their applications and make them complicated....

I totally agree, but your example doesn't really prove anything. The fact that one dangerous feature is inside PHP, doesn't mean we should embrace any dangerous feature we can come up with. There's no God-given law that forces us to support OO in PHP. PHP could have advanced just fine without it. It may have been less popular, it may have been more popular, who knows. The reason your example doesn't really prove anything is that apparently you tried to show us that 'Here, it's *obvious* that we need OO support in PHP, and we don't reject it because it's dangerous'. My response is that it's *far* from being obvious that we need OO support in PHP, and if we were back in the drawing board today, the fact that people can abuse OO and it can complicate their lives very much would have been weighted. Whether or not it would have made it into PHP depends on whether the gain was bigger than the loss (as I said, it's one big world of tradeoffs).

dangerouse features: What's so dangerous about on a simple AppServer - the new global Hash $SESSIONS that can be used to make data persistant...

It all depends on whether people understand what it is, and how much you can rely on them. Many developers would just go 'oh cool, now I can throw this in the general direction of $SESSIONS, and it'll stick there forever!'. That's fine, until you figure out you also have to clean it every once in a while, that you mustn't store big structures in there, etc. There's a reason for why databases exist. At any rate, I do *NOT* want to argue this anymore. That's just what I think. I'm perfectly happy with the fact that you think differently.

function caching: I wasn't referring to it in my replay, I was talking about how nice web forms would be implemented in an application server enviroment. Event like design, persistent objects, persistent resources - wow! As far as the function caching feature goes, I'm nearly 100% satisfied with the userland implementeatio Sebastian Bergmann recently checked in to PEAR repository. If I get some delegate mechanism on top of it, it's nearly perfect.

I want to point out that regardless of whether it's a userland or a built-in implementation, the concept of this functionality is dangerous, by definition. When I see Kristian saying that it's fine 'as long as you follow a few simple rules', I know we have an error-prone feature in front of us. For Kristian it may be simple (which I doubt, by the way), but bare in mind that Kristian and you are hardly the average users.

Sorry, I can't get that point. I statet that scaling by hardware is limited as you told me to use more CPU power. Middle-sized web applications can't afford a dedicated machine. And there's an upper limit where you can't get more powerful machines.

You said that increasing hardware is not good scalability. That's wrong - this *is* scalability. Scalability means you can get 2x (or close to 2x) performance if you increase the power of your hardware by 2x. I doubt you've reached the limits of hardware improvements. If you did, than wait a couple of months, and those limits will move up. The fact that hardware today isn't fast enough for your needs (if this really is the case) doesn't mean that the software you're using should be redesigned, unless you're off by an order of magnitude. If you were off by an order of magnitude, then the kinds of changes Kristian was talking about wouldn't have helped anyway, since they won't improve performance by an order of magnitude. My point is simple. Giving up performance for gaining other things (ease of use, speedy development, stability) is an accepted tradeoff. You can decide you want to trade, or you can decide that you don't want to trade, and use another, faster yet more difficult to use and maintain solution. The AppServer Kristian was talking about clearly has performance benefits. It also clearly has usability and stability drawbacks. Whether you want to go forward with this tradeoff or not is your call, or would be your call, when this AppServer is available.

Tell this too all the brain death enterprise guys that translate PHP into C.

It may surprise you, but I don't see any problem with that. It *IS* a world of tradeoffs. The beauty in tradeoffs is that you can decide whether you want to go with it or not. If PHP doesn't cut it for them, and they need significantly faster performance, then going the C way is a valid option. Going with some AppServer would also be a valid option when it's available. It does not mean that most or even many people will have to consider this, because PHP does cut it for them.

Anyway, this is not my point. I was mainly talking about new ways to design todays web applications which requires an AppServer. With an application server we beware the ease of use of PHP, win the possibility to use new designs (web forms, table proxy => rapid application development) and become faster as we loose the session overhead.

I have no problem with that. As I told Kristian and everyone numerous times before, I don't mind seeing the kind of thing he's talking about. I do mind seeing it transforming PHP itself into what it isn't (in simplified terms, the ability to run PHP as it is today *MUST* remain available). Kristiain's idea isn't revolutionary in the sense that it finally defeated the generations old computer science axiom of this being a world of tradeoffs. It has clear advantages, it has clear disadvantages, and people will have to choose. Zeev -- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/