come up time and time again, and its still not done. So WTF.
Well there are a few reasons why it hasn't been done yet, and while I
totally understand that people requesting this feature don't care and
that's fine. But I'll list them out anyways:
* Backwards compatibility - There is simply no way to maintain
backwards compatibility and provide hydrated objects back from the
database. A few people have tried and failed.
* This kind of change requires basically rewriting/reworking all
aspects of the framework. Behaviors, Components, Controllers,
Helpers, Views, all interact with models and their data in some way.
Changing the representation affects the full stack. This means all
userland code has to change, because of this there can be no smooth
transition when upgrading.
* Its really hard. Building an ORM is hard, harder than most expect.
This is another reason it hasn't been done yet. No one has spent the
time to actually think about what such a subsystem should look like
and actually build it. Instead we get threads every few months about
how its insane that it's not already done.
Those are just a few of the reasons why this hasn't already been
done. That by no means implies it will never change. My hope is that
the 'big release' after 2.0 will have a rebuilt sane model system that
returns magical unicorn powered objects.
-Mark
On Jul 4, 4:39 pm, stephenrs <ssgro...@gmail.com> wrote:
> Version:1.0 StartHTML:0000000149 EndHTML:0000004220 StartFragment:0000000199
> EndFragment:0000004186 StartSelection:0000000199 EndSelection:0000004186 Over
> the course of about 3 years, I built then lead a team to extend a fairly
> large CakePHP-based project. Over the past 4 years or so I've built several
> small to quite large systems based on Symfony. Recently, I've inherited a
> fairly mature CakePHP-based project to take over...boy do I miss Symfony.
>
> Refreshing my Cake memory...In all the discussions I've read recently
> regarding Cake's insistence on effectively forcing us to use arrays rather
> than properly hydrated objects to handle data, no one has stated the
> obvious: treating application entities (or objects) as arrays actually makes
> it *harder* to write proper MVC applications - it was simply a bad core
> design decision. It largely defeats the purpose of the active record
> pattern, leads to difficult to read and maintain code (filled with hideous
> expressions like $myFoo["myBar"]["myProperty"], rather than the much more
> elegant and easier to understand and work with
> $myFoo->myBar->getMyProperty(), for example).
>
> Keeping track of complex data structures and relationships as deeply nested
> arrays is a nightmare now that I've gotten used to doing "real" Object
> Oriented Programming...and an ORM is called that for a reason - instead of
> being called an "Array Relational Mapper"...returning objects for your
> application logic to work with is kinda the point...
>
> So, what the original poster wants to do makes perfect sense in an OOP/MVC
> context. He simply wants to add a $person->getAge() method properly to his
> model, where the getAge method looks something like:
>
> public function getAge()
> {
> // Assuming birth_date is stored as a unix timestamp.
> // Of course you'd want to display this in a human-readable format, but
> you get the idea...
>
> return time() - $this->birth_date;
>
> }
>
> ...then controllers, views, elements, etc all have access to it (although
> you should be thoughtful about where you access it from)...in case you're
> wondering, this is how Symfony works...
>
> The ability to treat your models as objects encourages you to write fat
> models. If your models are not much different than array
> transformation/manipulation utility classes, I can understand people's
> confusion...
>
> The point of this post is not to slam CakePHP, it's a fine framework (so
> hopefully I'm not inviting a flame war), but if you're looking to write
> Object Oriented code instead of Array Oriented code, then perhaps Cake is
> not for you. Don't let anyone tell you different: programming with objects
> will make your life (and your company's/client's) life easier than working
> with arrays - and it will make your projects more solid and easy to
> maintain...and it's how advanced professionals do things, for what it's
> worth. As I mentioned, I've done both extensively...but please tell me if
> I'm missing something.
>
> If someone replies with the usual mantra that arrays are better for
> performance than objects, I think I'll hang myself - in this day and age of
> computing, the antiquated "better performance" rationale just doesn't hold
> water. With all the potential performance bottlenecks that can pop up in a
> complex application, the core datatype transport being used might not even
> make it on to your top 20 items to optimize - because it's ultimately just
> not that important, relatively speaking...it's like worrying about where to
> put a coffee cup when you begin to move into a new home - you should
> probably be thinking about where to put the sofa first...using arrays
> instead of objects was a neat idea in 2004, but now it's just a
> counter-productivity pain...
>
> I suppose I'll have to get used to thinking in terms of arrays instead of
> actual objects for the project I'm working on...and it's said that human
> beings can get used to just about anything...but it just feels like I'm
> going "backwards"...
>
> Happy coding to all...and always choose the right tool for the job :)
>
> -SS
--
Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions.
To unsubscribe from this group, send email to
cake-php+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
No comments:
Post a Comment