I've stumpled across a new framework called xyster and it's not surprising that behind the fancy web 2.0 website is lurking something evil.
Xyster is an extension to Zend Framework and extends ACL, MVC with some features and uses the Database Layer for an ORM package. So what is the evil in xyster? Evil is the Xyster_Collection package. Everyone who knows Java's collection mess. Everyone who envied languages with object oriented array's. Will have some (good or bad) emotion now. But this is not the point. The points are interoperability and simplicity. It isn't easy nor fun to convert from/to collection Foo, again and again. Indeed, in Java this is common, but Java sucks exactly for this reason (and some others)! PHP does better, just hand over some native array's that work everywhere. And if you really need a fancy collection-like-something, create an highly specialized version and integrate it in the specific domain.
There is one small chance to create a collection framework for PHP that is interoperable. Write an RFC. Write an native extension. Start an petition. Pray. An don't forget to become a landowner, in case rasmus comes around and kills you with a roundhouse kick.
This fact would be a great disadvantage, if i had a need for xyster (or any other framework with the same flaws).
Friday, February 29, 2008
deconstructing xyster
Labels:
antipattern,
framework,
interoperability,
php,
phpism,
programming,
rant,
xyster
Subscribe to:
Post Comments (Atom)
2 comments:
Hi, Elias. I'm Double Compile, the project lead for Xyster.
I'm glad you took the time to check out the framework enough that you can give us some feedback. I understand your frustration with the Java concept of collections. I don't think ours is exactly in that vein, but it's close.
We really needed collection objects that hooked into PHP's SPL interfaces. Several things in the framework needed strongly-typed sets and sortable entries.
How would you do it differently? Can you think of any suggestions? You can e-mail me if you'd like.
Thanks!
-DC
Hi Jonathan,
thanks for your response! My suggestion is to stick to native array's as long as possible. You can solve anything without a collection-like-something. Testability and readability are reasons for me to bring a specialized array object into the game. I like all the SPL stuff, but ie ArrayAccess has to many drawbacks to adapt it on a broad range. It's just not fool proof. Further i don't want to learn another API. I know how array_merge() etc. works and i have easy access to the php documentation. But an array object may have an equivalent called $o->join() (and not merge) with a slight different implementation. I have to learn a new interface for problems that i already know how to solve.
Why take so many drawbacks and dispel one of the great powers of php?
e.
Post a Comment