Re: [RFC] New .phpp File Type for Pure-Code PHP Scripts

On 13/04/12 15:13, Kris Craig wrote: > Again, the controller should NOT be a .phpp file. Likewise, your model > should NOT be hooking directly to the view. The controller hooks to the > model. The controller then sanitizes that and returns it to the view. > Alternatively, if you're not conforming to a pure MVC standard, the > controller can also hook to a regular .php file in the model and pass the > data to that. Either way, it all passes through the controller. The model > and view should never be interacting directly. MVC or not, that's just bad > architecture and there are zero advantages to using such an ad hoc approach. > > If a developer insists on using such a broken model, however, they're more MVC is a broken model/bad architecture? > than welcome to! That's what people love (and hate) about PHP. It's > flexible. They just won't be able to use a .phpp file upstream from that, > as it is by its very nature inherently incompatible with such a broken > model. The only way to force it to be compatible would be to make the > .phpp file essentially meaningless. > > So if you're writing good code structure, a .phpp file will help you make > it even better. If you're writing bad architecture, then just keep doing > what you're already doing and don't worry about using a .phpp file! This > will in no way stop you from being able to do what you can already do in > PHP. You're just insisting on wanting to use a pure code file for > something that it's not intended to be used for. Just like having object > orientation added in PHP 5 didn't stop you from writing procedural code if > you want to, introducing this in PHP 6 won't stop you from writing > disorganized code if you still want to. What this will do is provide a > valuable option for people who do feel that writing clean, role-segregated > code is important. So basically, the only parts that might be ok to write as .phpp are some model and utility classes? David