Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If laravel is the best we have were fucked.

Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.



Symfony is better at handling backward compatibility and managing deprecation.

Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.


Can you share some of the BC breaking changes you've seen? I personally haven't seen any in quite a while, but I'm not using all parts of the framework.


Read the migration notes for the last few releases. Anything that requires you to change your code is a breaking change and the reason you can't skip versions.


Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?


I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability.

Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.

One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.

That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).


Yes, they are supposed to.

The problem is that it gets taken to extremes when it's done at the framework level.

The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.

Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.

If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.

IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.

The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.

Within modules usual namespacing and new constructors were used liberally.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: