Trouble in Zend Framework Land?

[33degrees]

It certainly mirrors the experience in several threads here (e.g. Container, DI and Persistence) where we started out very excited and eventually ground to a halt -- with a rich understanding of the subject, no doubt -- but frustrated that no clean, complete implementation was available.

That's the problem with PHP's "as simple as possible" philosophy. It makes the simple things easy, but the sophisticated things difficult or even impossible. In the case of finders, there are alternate solutions that are perfectly acceptable, or in the case of using a finder object, even preferable for some. But the amount of effort that people (including myself) have put into work arounds trying to make this work goes to show that the "correct" solution (in term of design principles) isn't always the most desirable.

[jayboots]

Maybe I'm missing something -- I can understand why the engine does not automagic __get/__set on static classes but I don't see why it doesn't automagic __call on static classes.

[arborint]

But the amount of effort that people (including myself) have put into work arounds trying to make this work goes to show that the "correct" solution (in term of design principles) isn't always the most desirable.

I don't understand why the "'correct' solution isn't always the most desirable." Can you explain your thinking?

[kyberfabrikken]

That's the problem with PHP's "as simple as possible" philosophy. It makes the simple things easy, but the sophisticated things difficult or even impossible.

In the webcast this guy keep talking about their principle of "extreme simplicity" - what kind of goal is that ? I mean, every sane developer tries to make the api as simple as possible. But complexity is relative to the context. Simple problems need simple solutions, complicated problems need complex solutions. If you use a simple solution to a complex problem, you're in trouble. If you use complex solution to a simple problem you're in trouble too, although of another kind. Perhaps what they meant is that they'll settle for the lowest common denominator. I guess "extreme simplicity" has a better sound to it.

[33degrees]

I meant desireable in the sense of something that is pleasing.

In this case, I believe a finder object is objectively a superior solution, partially because retrieving multiple rows is a different responsibility than persisting an object, and because of the testing issues with static methods (which personally I'm not clear on, but I'm relatively new to unit testing). Therefore, from a design principles perspective, that would be the 'correct' solution. But a static finder method is more succinct, and given the choice between the two, that's what I'd pick, because it's simpler and therefore more pleasing to use. So to me it's the more desirable solution.

To me it's analogous to the whole static vs dynamic typing issue; common wisdom in the OOP world is (or at least was) that static typing is superior, but I find it a pain in the *** and it ultimately makes me less productive. And in the end, that's more important than strict adherence to design principles.

[arborint]

But complexity is relative to the context. Simple problems need simple solutions, complicated problems need complex solutions. If you use a simple solution to a complex problem, you're in trouble. If you use complex solution to a simple problem you're in trouble too, although of another kind.

The other aspect of "simplicity" is when you work with software written by a "real smart" person the simplicity (and beauty) of it are often very apparent -- and it is often simpler to use and change. Conversely, software written by a "regular" programmer more often envokes a "am I going to have to rewrite this whole thing!" response because the design is not thought through and flexible. So I guess what I am saying is that well designed software (e.g. Rails) provides the essence of "simplicity."

Perhaps what they meant is that they'll settle for the lowest common denominator. I guess extreme "simplicity sound" has a better sound to it.

They claim to be after solving the 20% of the problems that occur 80% of the time. The question is -- is there flexibilty built in to allow you to deal with another 60-70% of the problems faced?

[arborint]

But a static finder method is more succinct, and given the choice between the two, that's what I'd pick, because it's simpler and therefore more pleasing to use. So to me it's the more desirable solution.

What I have noticed, and has also been mentioned here by several people, is that static methods initially seem more desirable, but in the long run are not so desirable.

[33degrees]

What I have noticed, and has also been mentioned here by several people, is that static methods initially seem more desirable, but in the long run are not so desirable.

That's entirely possible, but I've yet to run into problems with them as finders, nor have I seen a good explenation as to why the would be bad in this case. Somebody enlighten me

[dreamscape]

"extremely simple" or whatever the webcast was saying is all marketing talk, not technically talk. They are really trying to hype it up, and I must say their marketing department has done a fantastic job at gaining alot of attention and exposure to something that doesn't even exist.

[topsmith]

Without using the backtrace hack, they could change 2 or 3 lines in the php core code to return in static context the called class name (like new self).

Or they could force the user to write a static dummy find method in users classes:

class Person extends ActiveRecord {

  public static function find() {
    ActiveRecord::setClassName(__CLASS__);
     return ActiveRecord::__find(func_get_args());
  }

}

this is how it works in the (pre-alpha) medick framework:
http://svn.berlios.de/wsvn/medick/tr...ile&rev=0&sc=0

[shiflett]

The desire for static calls is interesting. I know it has been discussed here that static calls are not that desireable. It makes me wonder how thoughtful the peer review is.

Keep in mind that it's very easy to underestimate a group of people who come to a different conclusion than you by assuming that they haven't thought of something you have.

Also note the framework-feedback@zend.com email address. Nothing to give feedback on yet, but there's an email address.

This doesn't seem to have stopped you from providing feedback here. :-)

Seems quite good thou Zend doing a framework, sometimes get the feeling alot of the PHP developers just develop the language, and do little in PHP itself. Probably an unfair comment, but does seem that way, when you hit some odd limitation you wonder why.

I think it's a fair comment, and this is why I think having a few of these people also contributing to the Zend Framework will ultimately help PHP. Jeff Moore elaborates on this idea here:

http://www.procata.com/blog/archives...bjects-in-php/

I get the sense that maybe one of the contributing companies had an ActiveRecord implementation that worked for them, so they got everyone excited. But when they actually tried to implement it without the constraints that the contributor had tolerated -- it is not working as well as planned.

I understand that you have to make some assumptions, since you can't try it for yourself yet, but does this really help? The framework is being written from the ground up.

The challenge that has been encountered with ZActiveRecord isn't impossible to solve, but keep in mind that the primary companies who have been pushing Zend to create this framework aren't likely to be running the very latest PHP release. Thus, Zend must provide a solution that works on existing PHP 5 versions, not just future ones.

In any case, I find it amusing that they did the webcast using that syntax, while there is currently no way of implementing it in PHP5. Makes you wonder how much code they'd actually written at that point.

All of the libraries demonstrated had been written at that point.

In the webcast this guy keep talking about their principle of "extreme simplicity" - what kind of goal is that?

A very good one. PHP has an existing culture. Many of us have been working with PHP for nearly a decade, and we appreciate its simple and direct approach to solving problems. Any framework that's going to be successful cannot stray too far from this path.

If you want evidence, look at the number of PHP developers who dislike frameworks in general, prefer the procedural paradigm, never use PEAR, etc.

Simple problems need simple solutions, complicated problems need complex solutions.

That's not true. I've worked with many, many developers, and the best ones always seem to come up with those simple, unimpressive solutions, regardless of the problem. You know, the type of solutions where you think, "Oh, that's easy," as soon as you see it. These are easy to test, easy to debug, easy to maintain, and tend to perform better than complex solutions.

The Zend Framework abides by this principle in a slightly different way. It's basically trying to do the hard stuff for you in much the same way that SimpleXML does. The idea is that the code you write will be very easy to debug and maintain, and any complexity is handled for you in the framework.

The other aspect of "simplicity" is when you work with software written by a "real smart" person the simplicity (and beauty) of it are often very apparent -- and it is often simpler to use and change.

Exactly. :-)

They claim to be after solving the 20% of the problems that occur 80% of the time. The question is -- is there flexibilty built in to allow you to deal with another 60-70% of the problems faced?

Yes.

"extremely simple" or whatever the webcast was saying is all marketing talk, not technically talk.

You mean technical talk? How do you know this? I'll answer for you - you don't know. This is a blatant attempt to spread misinformation. Shame on you.

Extreme simplicity is a guiding principle in the development of the framework. It is similar to the "filter input, escape output" principle for web application security - a roadmap that can help guide you as you focus on the details. It serves the same purpose that a mission statement does for an organization.

They are really trying to hype it up, and I must say their marketing department has done a fantastic job at gaining alot of attention and exposure to something that doesn't even exist.

It exists, so that part is wrong.

As for their marketing, I think you're too easily impressed. :-) It can't be that great, because I've missed it. I saw where they announced the framework at ZendCon, but that's about it. I can't even find the framework page from zend.com - I have to use a direct link to get there. (It's probably linked somehow, but it sure isn't easy to find.)

I'm sure their marketing department will kick in once it's released.

I hope this was helpful.

[Ren]

The challenge that has been encountered with ZActiveRecord isn't impossible to solve, but keep in mind that the primary companies who have been pushing Zend to create this framework aren't likely to be running the very latest PHP release. Thus, Zend must provide a solution that works on existing PHP 5 versions, not just future ones.

Yes, if they keep the static method syntax it'll be interesting exactly how they solve it. debug_backtrace() & parse the source seems the only 100 % PHP solution.

I'm wondering if the fix could implemented in an extension.

[kyberfabrikken]

[The priciple of "extreme simplicity" is] A very good one. PHP has an existing culture. Many of us have been working with PHP for nearly a decade, and we appreciate its simple and direct approach to solving problems. Any framework that's going to be successful cannot stray too far from this path.
...
Extreme simplicity is a guiding principle in the development of the framework. It is similar to the "filter input, escape output" principle for web application security - a roadmap that can help guide you as you focus on the details. It serves the same purpose that a mission statement does for an organization.

How is that different from lowest common denominator ? Please understand that I'm not out to ridicule Zend by that statement (well perhaps a bit). If that is their aim, fine. But pretending that the simplest possible solution will always be the best, and that it can't cause trouble ahead with more complex applications is just naive.

Simple problems need simple solutions, complicated problems need complex solutions.

That's not true. I've worked with many, many developers, and the best ones always seem to come up with those simple, unimpressive solutions, regardless of the problem. You know, the type of solutions where you think, "Oh, that's easy," as soon as you see it. These are easy to test, easy to debug, easy to maintain, and tend to perform better than complex solutions.

I didn't say overly complex. I said complex. I stand by that.

I take it that we could transcribe the catchy "extreme simplicity" to "go with the simplest possible solution". That's common sense.
The other edge of that sword however, is that an overly simplified solution may be getting in the way for a more sophisticated solution. I really think that flexibility is more important than simplicity, in a framework. Or at least that the ratio is different than with an application.

[33degrees]

All of the libraries demonstrated had been written at that point.

That may be true, but since nobody here has found or seen a way to make that particular example work in PHP5, you can't blame us from thinking that there may not be way of doing it without adding to the language itself, and so that there's actually no working code.

[sweatje]

To be fair, Chris has stated on his blog that he is involved with the Zend Framework, and I would suspect there is probably some kind of an NDA in place until it goes public. So you can take it with a grain of salt, but you may be getting a little bit of "insider insight" from his comments.

[shiflett]

Yes, if they keep the static method syntax it'll be interesting exactly how they solve it. debug_backtrace() & parse the source seems the only 100 % PHP solution.

I agree with your earlier prediction - that a change in PHP itself will be made, and an alternative syntax will be supported in order to cater to existing versions. Mike's public comments lend credibility to this prediction.

I seem to recall a bug in debug_backtrace() that made the following output myChild:

<?php
                                                                                
class myParent
{
    static public function myMethod()
    {
        $debug = debug_backtrace();
        echo $debug[0]['class'];
    }
}
                                                                                
class myChild extends myParent {}
                                                                                
myChild::myMethod();
                                                                                
?>

I can't remember when this was fixed, or if I'm just losing my mind. :-)

[Edited]

But pretending that the simplest possible solution will always be the best, and that it can't cause trouble ahead with more complex applications is just naive.

I don't think Zend has ever claimed that. Like I said, extreme simplicity is just a guiding principle.

Andi mentioned in the webcast that the framework achieves extreme simplicity in a number of ways, one of which is by not trying to solve every problem and by being flexible enough that PHP developers can still solve their more unique or complex problems themselves.

The other edge of that sword however, is that an overly simplified solution may be getting in the way for a more sophisticated solution. I really think that flexibility is more important than simplicity, in a framework.

I think these two characteristics can happily coexist. A simple solution only gets in the way when you try to use it to solve a problem it can't solve. Otherwise, it's just a few extra lines of code taking up space.

[Edited]

That may be true, but since nobody here has found or seen a way to make that particular example work in PHP5, you can't blame us from thinking that there may not be way of doing it without adding to the language itself, and so that there's actually no working code.

I don't blame you at all for thinking that.

[lastcraft]

Hi...

Keep in mind that it's very easy to underestimate a group of people who come to a different conclusion than you by assuming that they haven't thought of something you have.

What is it that everyone is missing? The people who are commenting on the broken syntax are all people who have implemented ActiveRecord or other persistence libraries before (I'm currently on my fourth, but didn't even spot the problem).

There is a mysterious silence if there is an easy fix at hand.

I'm certainly curious about this incident, because it does give an insight in what's happening behind the scenes.

This doesn't seem to have stopped you from providing feedback here. :-)

It's only feedback if the framework authors read this stuff .

I understand that you have to make some assumptions, since you can't try it for yourself yet, but does this really help? The framework is being written from the ground up.

Given the complete lack of information, and the high number of framework authors on this forum, you would expect speculation to fly.

Who are the current authors? Is anything know about their previous experience with frameworks, etc.

All of the libraries demonstrated had been written at that point.

Now the plot really thickens. How did they get Joshua's example to work?

A very good one. PHP has an existing culture. Many of us have been working with PHP for nearly a decade, and we appreciate its simple and direct approach to solving problems. Any framework that's going to be successful cannot stray too far from this path.

I think "extreme simplicity" is going to have several meanings for different camps. I think PHP suffers from "extreme crudeness". Abstractions are rarely completed and very leaky.

This may be simple for the implementors, but is a whole bunch of extra complications for users. I'd like to think the phrase means lot's of effort to make the interface simple. Hibernate is very sophisticated, but it is clearly written with extreme simplicity as a goal.

JMock is currently having a lot of influence. I was fortunate enough to be sitting in the pub with the developers in the early stages. I saw Nat Pryce offer four designs, all with "easy to use" as the goal. From what I remember the final design was a mixture of two of them and emerged sometime later. A lot of refinement work was invested to achieve simplicity.

I'd like to see thsi approach take hold, and for us to stray from the old PHP path as much as possible quite frankly.

If you want evidence, look at the number of PHP developers who dislike frameworks in general, prefer the procedural paradigm, never use PEAR, etc.

I would count PEAR as the extreme antithesis of JMock.

It serves the same purpose that a mission statement does for an organization.

What I love about this phrase is that Zend have handed us a huge great brickbat to hit them over the head with . How many blogs are going to quote this phrase when some part of PHP gets overblown? RecursiveIteratorIterator anyone?

It exists, so that part is wrong.

So what's going on with the broken static stuff? Claiming a mysterious trick up their sleeve, and then failing to produce it, doesn't cut it. If this code works, what's the trick? If there is no trick, then it doesn't work? Please resolve the contradiction.

I hope this was helpful.

Not yet, but I'm looking forward to your response .

Any chance of comments on other aspects of the framework? Who's involved? How do people take part? Who's testing it? What were the influences?

yours, Marcus

[seanf]

It is disappointing to see a good thread turn into such a childlike display. All offending posts have been removed. Any continuation of this stupidity will result in this thread being closed

Sean

[Dr Livingston]

The comments just made by Marcus don't help

I don't really know what all the noise is about; The framework isn't going to be published until it's complete. All this speculation isn't constructive, in fact it degrades the whole concept that Zend have gone to the trouble of developing the framework, even if needs must.

You will all just have to wait until it's released, so show some patience.

[seanf]

The comments just made by Marcus don't help

Marcus was perfectly civil and the points raised will continue this discussion. We do not remove posts just because they disagree with posts made by another member. Unfortunately, we are starting to take this thread off topic again, so lets leave this here.

Sean

[33degrees]

I think "extreme simplicity" is going to have several meanings for different camps. I think PHP suffers from "extreme crudeness". Abstractions are rarely completed and very leaky.

This may be simple for the implementors, but is a whole bunch of extra complications for users. I'd like to think the phrase means lot's of effort to make the interface simple. Hibernate is very sophisticated, but it is clearly written with extreme simplicity as a goal.

The more I think about it, "Extreme Simplicity" is a really poor choice of motto. Nobody sets out to make their designs complex, and as Marcus points out, simplicity is inherent in good design. So at best, the motto is stating the obvious. At worst, it insinuates that other frameworks are too complex (and therefor badly designed) or that PHP users need a framework that's dumbed down.

It's obvious that that's not what they meant, but it does go to show how poor a choice of phrase it is.

I don't really know what all the noise is about; The framework isn't going to be published until it's complete

I think the blame lies squarely on Zend for being so secretive about this project, and I think they have more to lose than to gain by doing so. Since there isn't a commercial incentive to keeping the source under wraps, one is led to think that maybe they have something to hide, or that they have a dim view of the common PHP programmer. Regardless of their reasons, I do think it shows a lack of understanding about how succesfull open-source projects work; Linux would definitely not be as ubiquitous as it is if Linus had kept the project to himself and some close collaborators until they felt all the bugs had been worked out.

[Dr Livingston]

I think the blame lies squarely on Zend for being so secretive about this project, and I think they have more to lose than to gain by doing so. Since there isn't a commercial incentive to keeping the source under wraps, one is led to think that maybe they have something to hide, or that they have a dim view of the common PHP programmer. Regardless of their reasons, I do think it shows a lack of understanding about how succesfull open-source projects work; Linux would definitely not be as ubiquitous as it is if Linus had kept the project to himself and some close collaborators until they felt all the bugs had been worked out.

On the points you've just made, I would have to agree with you completely; Though Zends framework is intended for the open source market, I still can't help but I get the feeling that there is to some extent, a commercial presence that resides behind the people who are backing Zend, in their endevour.

The secrecy of the framework, and therefore the lack of details may actually not lie at Zends door, if there are other parties that are involved, and that they have their say in the matter, or not. Anyway, there is nothing we can really do about it at the moment...

[shiflett]

What is it that everyone is missing? The people who are commenting on the broken syntax are all people who have implemented ActiveRecord or other persistence libraries before (I'm currently on my fourth, but didn't even spot the problem).

I think you're getting the topics crossed up a bit. My reply was to the following:

The desire for static calls is interesting. I know it has been discussed here that static calls are not that desireable. It makes me wonder how thoughtful the peer review is.

I see this type of statement on Slashdot all the time - one group of people assuming that those who come to a different conclusion have overlooked something obvious. It's certainly possible, but I don't think it's very common among software professionals.

Given the complete lack of information, and the high number of framework authors on this forum, you would expect speculation to fly.

I do expect it, and I don't fault anyone for it, unless they try to present their speculation as fact in a deliberate attempt to spread misinformation.

Who are the current authors? Is anything know about their previous experience with frameworks, etc.

An early list of contributors is here:

http://www.zend.com/collaboration/framework_overview

From this list, you can see developers from 100 Days (a company whose entire business model revolves around a PHP framework), Ning (David Sklar), OmniTI (George Schlossnagle and Wez Furlong), and CRMs such as Jambo and SugarCRM.

Other blog posts indicate that Davey Shafik (author of Cerebral Cortex) and Paul Jones (author of Solar and Savant) are contributing.

Of course, there are the big companies like Zend and Oracle involved as well.

How did they get Joshua's example to work?

Read Mike's comments here:

http://blog.joshuaeichorn.com/archiv...ord-cant-work/

This may be simple for the implementors, but is a whole bunch of extra complications for users.

You have it reversed. The use cases are intended to be simple, and any necessary complexity is handled in the framework. Achieving extreme simplicity is not "simple for the implementors."

I'd like to see thsi approach take hold, and for us to stray from the old PHP path as much as possible quite frankly.

Then you'll likely be disappointed with Zend's project. This is a company that caters to PHP developers who enjoy the "PHP way" of solving problems as simply and directly as possible. Although some Java development is migrating toward this approach (or migrating to an entirely different platform such as Ruby on Rails), I seriously doubt Zend is interested in making its framework stray too far from the status quo. Even if the "Java way" is better, it's not the approach that Zend's target audience prefers.

Most Java apologists I know blame all of the frameworks and related technologies for the problems in Java applications (unnecessary complexity, poor performance, lack of scalability, failed projects, etc.), so I think anyone implementing a PHP framework and wanting it to be widely adopted and successful needs to be careful when borrowing ideas from Java.

How many blogs are going to quote this phrase when some part of PHP gets overblown? RecursiveIteratorIterator anyone?

Do you mean to be speaking about PHP or the Zend Framework?

I assume you mean the framework, and I agree, but that's part of the point. By making this goal of extreme simplicity public, Zend has essentially made a promise to the community. You can be sure that this looms over the head of everyone contributing to this project. :-)

So what's going on with the broken static stuff? Claiming a mysterious trick up their sleeve, and then failing to produce it, doesn't cut it. If this code works, what's the trick? If there is no trick, then it doesn't work? Please resolve the contradiction.

There is no PHP trick, aside from some ugly hacks (some of which have already been mentioned). The code I posted earlier solves the problem a bit more elegantly, but it relies upon a bug in debug_backtrace() that has now been corrected, so it's no longer useful. :-)

Stated differently, there is no clean PHP solution. The only elegant way to solve this problem is with a C solution, a modification to PHP itself.

Hope that was more helpful. :-)

[shiflett]

I think the blame lies squarely on Zend for being so secretive about this project, and I think they have more to lose than to gain by doing so.

Perhaps the problem is that they're not being secretive enough. If no one knew about the framework, all of this speculation and criticism wouldn't exist. They could be like Apple and only announce something after it had been completed.

Another perspective is that Zend's announcement at ZendCon is no different than many of Apple's announcements at WWDC. For example, Apple announced its Intel plans last year. They wanted developers to be ready. Zend announced its framework plans last year. They wanted developers to be ready.

Regardless of their reasons, I do think it shows a lack of understanding about how succesfull open-source projects work; Linux would definitely not be as ubiquitous as it is if Linus had kept the project to himself and some close collaborators until they felt all the bugs had been worked out.

Linus gave us "release early, release often," but that doesn't mean he released Linux to the world before he was ready. There's also the fact that his project wasn't immediately popular - he still had very few contributors for the first year or two, and it took him more than two years to release 1.0. In other words, the conditions were entirely different.

Try to contribute a patch to the Linux kernel now, and see if you still think it's the best example to further your argument. The same goes for Apache, MySQL, Perl, and just about any other successful open source project.

In fact, PHP is known for having the most open development process of the major open source technologies, and this is often a source of criticism. This is the group of developers with which Zend is working, so I highly doubt they're blind to the advantages and disadvantages of their approach.

[lastcraft]

Hi...

I see this type of statement on Slashdot all the time - one group of people assuming that those who come to a different conclusion have overlooked something obvious. It's certainly possible, but I don't think it's very common among software professionals.

This is the "every opinion is equally valid" argument in a different guise. Actually opinion tends to converge with experience. When I talk to 5+ year OO developers, they avoid statics. It's the newbies who like them.

The only exception here is Java, where the one public class per file forces static factories all over the place.

I do expect it, and I don't fault anyone for it, unless they try to present their speculation as fact in a deliberate attempt to spread misinformation.

I don't think anyone did that.

An early list of contributors is here:

All PHPers then, and no company with an obviously OO background. I think Jeff is spot on - Zend need to hire an industry heavyweight. The skills are not present in the PHP community. One world class developer will out-perform a team of average joes.

Yes I know they are some great C developers in that list, but we are talking cohesive OO frameworks. No one builds class libraries and multiple frameworks full time.

This sounds like it will be just another framework, well slightly better given this will be everyone's second go, but with the Zend logo. That may be a good thing in itself looking inward at the PHP community, but it won't complete witth Ruby and Java. I guess taht will happen on the next round.

Other blog posts indicate that Davey Shafik (author of Cerebral Cortex) and Paul Jones (author of Solar and Savant) are contributing.

Paul Jones, bless him, has only just learned unit testing.

There's another little problem. Rails was built on top of the Ruby class library. PHP doesn't even have a standard class library yet. Could we not have that first?

Of course, there are the big companies like Zend and Oracle involved as well.

Er...Zend? How are Oracle involved? Are they lending a framework guru? How are they helping? Again, you have peeked my interest.

You have it reversed. The use cases are intended to be simple, and any necessary complexity is handled in the framework. Achieving extreme simplicity is not "simple for the implementors."

I was talking about the PHP history you were referring to as an influence. I don't see sticking to the PHP way as a good thing, I see "extreme simplicity" as a very good thing and well overdue. "Extreme simplicity" and the "PHP way" are not the same thing. Not the same thing at all .

This is a company that caters to PHP developers who enjoy the "PHP way" of solving problems as simply and directly as possible.

You misread what I said. The current "PHP way" is a complete mess, with many half completed features and ad hoc bolt ons. The broken static behaviour is just one example where the PHPer had to work around the language limitations.

Yes please to "extreme simplicity". No thanks to everything, but the kitchen sink. I really hope this is a turning point.

Although some Java development is migrating toward this approach

The more experienced Java developers have been using this approach for sometime. Check out "Java Open Source Programming" (Walnes, et al) for a big list of "simple" tools. The Java crowd are still ahead of the curve on "extreme simplicity". Rails is just one project.

... so I think anyone implementing a PHP framework and wanting it to be widely adopted and successful needs to be careful when borrowing ideas from Java.

No one is suggesting copying Java. We don't have to copy Rails either.

Do you mean to be speaking about PHP or the Zend Framework?

The phrase came from the "powers that be", and it will be used to harass both. Hell, I'm gonna' have great fun .

There is no PHP trick, aside from some ugly hacks (some of which have already been mentioned). The code I posted earlier solves the problem a bit more elegantly, but it relies upon a bug in debug_backtrace() that has now been corrected, so it's no longer useful. :-)

Right, so the code is broken. That was the conclusion I was expecting.

yours, Marcus