Re: On how a little knowledge is completely useless.

Inline response: On 9/17/10 1:57 PM, Jonathan Bond-Caron wrote:

On Fri Sep 17 01:06 PM, Guilherme Blanco wrote:

Another good example is to map your persistence data into your Entities. Doctrine 2 implements this and I think that way you can compare easily with the PHP code alternative. I'd like to ask you to compate the same Entity mapped through Annotations emulator and using raw PHP code: CmsUser using Annotations: http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ M odels/CMS/CmsUser.php CmsUser using PHP code: http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php

You're basically bundling (M: Model, data& configuration, C: Control, business logic / code) into a single class while the MVC pattern is all about separating M,V and C.

Jonathan, I think you are misinterpreting this code. There is no Controller (Front controller, or parameter mapping from $_POST or $_GET) nor View responsibilities (echo) here. These are all Model concerns: how is data persisted, how is it mapped to the persistence layer, how are entities created and how are their dependencies injected, etc. By using doctrine, you are adopting & subscribing to Doctrines philosophy of how tool based modeling should work. The code doesnt run without doctrine in the mix anyway (you'd have their entity manager in play at all times). How they (the Doctrine project) decide to manage mappings is up to them, and you'd be free to either consume their ORM framework, or not. It is both a development time and production time tool.

What's wrong with a simple configuration file? Caching the parsed config in shared memory?

There is nothing wrong with that, but that is only a single approach. Alot of times, developers want a close relationship between the metadata and the code it is about. That means not in separate files, but inside the same file. This is why projects like *Hibernate are so popular in enterprise software. No one wants to develop an ORM, they just want a way to persist their objects.. and a little penalty in performance is a sound trade-off.

One important flaw rarely mentioned with annotations config: your code now depends on framework X to read the annotations instead of a simple configuration file (.xml, .ini., ...)

Doctrine, Symphony DI, even ZF.. and include to that the non PHP solutions.. none of these are frameworks you can adpot in less than 5 minutes. It takes some investment of time to understand their philosophy and also decide how it best fits into your personal code toolkit. That means that you'd have understood how said framework plans and does use these annotations.

Sorry if I might sound harsh but configuration through annotations is terrible. You'll find many .net or java developers that agree, I'd say it's 50-50 if not more 70-30. Does this discussion still belong in internals? We could argue about this for months, java astronauts don't even agree how annotations are useful: http://www.javaworld.com/community/node/2613

Arguments like this will always exist. But that's less the point. The point is is that there are many developers that exists that have taken the time to adopt a persistence framework like *Hibernate, and no one can argue that they do not get their job done, and annotations have certainly helped them get there and create maintainable code. -ralph