Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:28621
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.185 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding;
        b=Kt2dLWU/l2thexzKb4g4DyuqXfZDvDFbM2DnuzIo3Nj9smXoNAk8fPrzKKT/y1bzvMOmPMbpXIa9wuvgVqqrdVt5Yka28CZIZNJkIarqr5wIcUq9jurMNLG8Um95SWOJoHKpS87MRT/LQxsBnxHZnpc80vTfbs+CU0znmg1mBjk=
To: Jeff Moore <jeff@procata.com>
Cc: internals@lists.php.net
In-Reply-To: <DA30D4CB-C150-4AF5-9EA0-9D2889C34488@procata.com>
References: <1174134488.8667.33.camel@lena>
	 <45FC74A5.6080307@pooteeweet.org>	 <1174231834.12274.110.camel@lena>
	 <45FEBD70.2090000@zend.com>	 <1174330743.9134.2.camel@lena>
	 <41721.216.230.84.67.1174341117.squirrel@www.l-i-e.com>
	 <1174342387.14657.86.camel@lena>
	 <bcb7aa500703200643n5c5cf0d5x2c3794d2906c531f@mail.gmail.com>
	 <46004829.7080200@pooteeweet.org>
	 <DA30D4CB-C150-4AF5-9EA0-9D2889C34488@procata.com>
Content-Type: text/plain; charset=utf-8
Date: Wed, 28 Mar 2007 00:27:39 +0200
Message-ID: <1175034459.10691.27.camel@lena>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] google SoC - dbobj
From: thefirstofall@gmail.com (Adam Banko)

2007. 03. 27, kedd keltezéssel 16.55-kor Jeff Moore ezt írta:
> 
> Hi,
> 
> Sorry, I'm coming to this discussion a bit late and perhaps I don't  
> understand the all issues, but I think the scope of creating an ORM  
> for PHP is probably too large.  Let me suggest a smaller project that  
> could lead to better ORM.
Yes a bit late ... as the application submission deadline has already
passed. (for SoC)

> PHP has several  methods of serializing and unserializing objects to  
> different formats:
> 
> PHP serialization format using serialize/unserialize (with __sleep,  
> __wakeup and the Serializable interface)
> PHP code using var_export and eval (with __set_state)
> JSON using json_encode and json_decode
> Partial support for DB Records using mysql_fetch_object or  
> PDOStatement->fetchObject()
> 
> Its safe to assume that other serialization formats are possible.
> 
> All of these methods have to address the same issues with objects:
> 
> How to handle protected and private properties?
> To call or bypass the constructor on unserialization?
> Can objects become involved with their own serialization? (such as  
> __sleep, __wake, __set_state, and Serializable)
> Must objects become involved with their own serialization (such as  
> with var_export and __set_state) or can you serialize unaware objects?
> Are object relationships and identity preserved? (only true for  
> serialize/unserialize right now)
> How are classes loaded? (unserialize_callback_func and __autoload?)
> 
> I think a more limited scope project would be to attempt to address  
> these core object serialization issues across the multiple formats  
> that PHP already provides in some consistent way.  Of course, not  
> every capability is possible or necessary with every format.

The SoC application is over, but this could also be done outside of SoC.
I think this is a good project, rethinking the serialization /
unserialization support in PHP would be beneficial for many. However
don't wait for me to do it, because I won't.

> Before implementing ORM in C, which would be relatively less flexible  
> than a PHP implementation, perhaps it would be a good idea to profile  
> the existing PHP ORM solutions and look for opportunities to  
> implement key functions in C, while leaving the majority to user space.

I think I've already explained my opinion on this idea. Your idea is not
bad, and I think many agrees with you, but I see things a bit
differently.

> A possible example of such an opportunity might be some equivalent to  
> extract() and compact() only for converting between arrays and object  
> properties instead of arrays and local variables.

I generally don't like the idea of converting an object to array and
back as it violates most OO principles. Don't convert an object to an
array, because than there's no problem with private properties and so
on. If someone wants arrays from the database, then he/she souldn't use
ORM because it's Object-relational mapping, not Array-relational
mapping!

> Rather than implement a full blown ORM extension, perhaps  
> implementing some object serialization enhancements would be a good  
> alternative, or at least a good first step? Perhaps some user space  
> ORM profiling would be a good way to find the second step?
Maybe ... but that is someone else's project, not mine. To see what my
goals are how I plan to achieve them, see the archives. I think I've
explained a lot on the list.

However, if you find any problems with my proposed solution, please
don't hesitate to share it with us.

> 
> Best Regards,
> 
> Jeff
> 

Thank you,
	Adam