Hi,
I'd like to help you in this working draft, but I don't have too much experience with C/C++ to holp with code, but... I can try something. Also, I suggested you that white paper since it supports almost everything expected from a robust ORM tool. I still believe that your performance gain will be less than expected, but I still like the idea. I even spoke with Mr. Manuel Lemos (PHPClasses.org author) almost an year ago in a PHP event here in Brazil exactly about the same thing. Our conclusion reached that the performance would not justify the implementation. But, I still believe this is an important feature to be bundled with PHP and, if not, at east be a separated supported project of PHP (like Smarty). Currently, in a MVC/MVP perspective, PHP already supports the View layer, but misses the Model (sorry, they helped a lot with PDO talking about DB Abstraction) layer. I believe that PHP should have a bundled feature that can even support OO approach for OO enthusiasts (like me) and also Structural. If not bundled, support the project like Smarty, something like http;//orm.php.net As I mentioned before, the best ORM tool I've notice is Doctrine, but it has some issues that I can list if necessary. The point is not to start a discussion about why Propel, MetaStorage, ezComponents, ADODB_ActiveRecord or any other is better or not; the point is that different implementations has some good points and bad points. Tony Bibbs already started a mailing list with already implemented ORM tool authors, that can be a great starting point. I have to say that your idea is good enough to even be out of Google SoC. This could be a separate project, and should already exist for years. If the only needed starting point is SoC, that's ok. But you have to understand that this project should already exist in PHP land. Java already has a lot of ORM tools, and Hibernate is the most known. PHP should have a similar thing. I am not part of Core Team, but I'll deliver my proposal to everyone here. If we group ORM authors, generate a draft and implement it, I think we can reach a commom sense. As I already mentioned, this is out of SoC scope. Please, do not ignore the idea. An answer that this does not belong to PHP land is going against your own principles, since you're trying to bring PHP more OO. I am opened to start a dialog about this subject. If you want to add me to your MSN/GTalk/Yahoo!/Skype: MSN: [EMAIL PROTECTED] GTalk/Yahoo!/Skype: guilhermeblanco Best regards, On 3/19/07, Bankó Ádám <[EMAIL PROTECTED]> wrote:
2007. 03. 19, hétfő keltezéssel 16.51-kor Richard Lynch ezt írta: > I don't think you'd want the RAM/performance hit of that, even in C... > [shrug] > > OTOH, I don't think I'd even want to use an ORM, so feel free to > ignore me completely. :-) > Hi! I think a code is more manageable if it's more structured. This additional structure however means "unoptimal" code, that will run slower, and consume more memory. Some balance point should be found, where the project is still manageable, but the resource overhead is minimal. Managing C code with limited structure (for bigger projects than hello word) is hell. This is why structured programming and then the OOP was invented. Having a separate object for every data value is a bit idealistic (it would be best, if it wouldn't have the object construction / destruction overhead. But it has. I choose to implement this "idealistic" approach when I started to see switch-case blocks in my code, that did not fit in my screen (about 50 lines). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
-- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com São Carlos - SP/Brazil
