PHP Hibernate, OQL and other goodies

[lastcraft]

Hi...

/* load the objects, but don't store information about them */
$friends = $session->fetch($query, Query::IGNORE_CHANGE_TRACKING);
$tx = $session->beginTransaction(); 
foreach ($friends as $friend) {
  $friend->send($gift);
  /* do a manual update*/
  $session->update($friend);
}
$tx->commit(); 

I don't think a separate transaction ans session object are needed for PHP. Just one class for both would probably suffice. As a PHP script runs a single short lived process with no threads the most likely usage is a single transaction. If not then they can just create another with "new" as I doubt anything is shared between them.

yours, Marcus

[sike]

Hi,


just had time to catch-up with this interesting thread.

PHP4 or PHP5 ?
i would strongly vote for php5. the new object system is good
enough to scare me if i have to work on older php4 projects (;
another reason for me is that everyone posting here has a more or less different
understanding of how the "enduser"-api should look like. if we would use interfaces
for the business objects (or however you call them). additionaly we could provide a reference
implementation for less pedantic users (;

Meta
as laid out above i amadovating interfaces and so i had a go at it...
heres what i have so far (ideas, critics or other replys are very welcome) :

<?
/**
* Entitity Derscriptor
*
* @author   Christian
* @version  $Revision$
* @package  ORM
*/

  /**
  */

  /**
  * @author   Christian
  * @version  $Revision$
  * @package  ORM
  */
  interface IEntityDescriptorAggregate
  {
    /**
    * @return   IEntityDescriptor
    */     
    function getEntityDescription();
  }

  
  /**
  * @author   Christian
  * @version  $Revision$
  * @package  ORM
  */
  interface IEntityDescriptor
  {
    /**
    * @return        string        Tablename or Xpath or...
    */    
    function getNativeEntity();
    
    /**
    * @return   IEntityPrimaryKeyDescriptor
    */       
    function getPrimaryKey();
    
    /**
    * @return   Iterator         IEntityFieldDescriptor's
    */    
    function getFields();
    
    /**
    * @return   Iterator        IEntityFieldDescriptor's
    */        
    function getProxyFields();
    
    /**
    * @return   IEntityRelationDescriptor
    */        
    function getRelations();
  }
  

  /**
  * @author   Christian
  * @version  $Revision$
  * @package  ORM
  */
  interface IEntityFieldDescriptor
  {
    /**
    * @return   string
    */        
    function getName();
    
    /**
    * fieldname in datasource
    * 
    * @return   string
    */     
    function getMappedName();
    
    /**
    * @return   string        int, string, ... or constants?  
    */        
    function getType();

    /**
    * @return   bool  
    */      
    function getAutoGenerated();
  }
  
  
  /**
  * @author   Christian
  * @version  $Revision$
  * @package  ORM
  */
  interface IEntityPrimaryKeyDescriptor
  {
    /**
    * @return   Iterator        IEntityFieldDescriptor's  
    */      
    function getFields();
  }

  
  /**
  * @author   Christian
  * @version  $Revision$
  * @package  ORM
  */
  interface IEntityRelationDescriptor
  {
    /**
    * @return   Iterator        Key [self.field] = Value [related.field]
    */      
    function getFieldMap();
    
    /**
    * @return    string    OneToMany, OneToOne, ... or constants?
    */     
    function getType();
    
    /**
    * @return   bool  
    */      
    function getCascadeDelete();
  }          
?>

cheers,
Christian

[arborint]

I don't think a separate transaction ans session object are needed for PHP.

I agree that this thing should be all-in-one. I would suggest not naming it Session or Transaction because those names already have some meaning in PHP. How about calling it pHibernate? Keeps the data moving, good for the bowels of your program, just use it then flush()?

Christopher

[ponticelli]

PHP4 or PHP5 ?

I agree that PHP5 it's a better choice if we are talking about syntax and OOP, but in the reality we all know that PHP5 is far from being available for everyone and the situation will not change in the near future. I see a best bet in doing it PHP5 compatible... eventually a version 2 or 3 maybe PHP5 native... my 2 cents.

[lastcraft]

Hi.

If you call it Phibernate then it will have to be a Hibernate clone, at least on the public interface. To really work like Hibernate though, it might be an idea to start with persistent memory caching from the start. That is from the word go, make it a no compromise enterprise tool even at the expense of the small user. At least with the memory caching the Java Hibernate code could be used more freely. Otherwise the request driven architecture of PHP will clash with the application server style of Hibernate.

Just a thought.

yours, Marcus

[arborint]

Perhaps we are putting the code before the horse. Looking back over this thread I don't see a list of requirements other that what Selkirk posted for what WACT needs. What are some requiremants for this thing? Here are a few comments and question from the few posts to get started.

- PHP4 or PHP5?

- start with persistent memory caching?

- separate transaction ans session object are needed for PHP?

- there should also be an API to manually control transaction and persistence behaviour

- we need more granularity for controlling the behaviour of object graphs or large lists than just one commit operation that saves all changes

- a straight Hibernate port won't do because you don't want to keep things in memory longer than you have to (unless it includes a persistent memory cache)

- a commit method that can take an object as an optional parameter and so remove it from the IdentityMap

Christopher

[dylanegan]

I was planning a Hibernate clone, but when it came down to it, it wouldn't work too well in PHP, well atleast without a VM. Along came Marcus with his "Changes" library and it really provided what I was looking for, atleast for a base. Would it be easier to extend off of it?

[Brenden Vickery]

UnitOfWork is still not a very defined pattern and having pattern names in code is a bit dodgy. For example, what if this class wraps a UnitOfWork when it gets more complicated. Hibernate uses "Session", although "Transaction" should be fine to.

Agreed. Im a little bit wary of using Session but Transaction may fit better.

I have been dropping heavy hints that this is a big job...

You dont learn much sticking to the little jobs .

You have a global test example which wil get strained as you add more tests. Don't go there . For the unit tests I would have lot's of little mini examples with their own mini schemas. Makes the tests a lot easier to maintain and also makes them more readable. Especially if the schema actually appears in the test case...
Also you normally want at least as much test code as real code. Probably more in this case because DB data is usually mission critical.

Ok, that sounds very wise. As you can tell that code wasnt test driven. It was code from an older project, mixed with some new code. It was mostly PoEAA (Fowler) driven design .

There are all sorts of reasons why a straight Hibernate port won't do because you don't want to keep things in memory longer than you have to (unless it includes a persistent memory cache). For example when iterating through a large data set, you don't want to clone or keep a reference to every item.

You say "persistent memory cache" a couple of times, can you explain what you mean by this?

Is the problem that you and hantu are discussing that you dont think a UnitOfWork should always keep a reference and a clone(or serialized or whatever) of read objects in a "cleanObjects" array? Or do you think you shouldnt keep a reference in the IdentityMap? Or both?

Having a query object that returns "read only" (Objects that if changed would not be updated) objects wouldnt be difficult to implement.

How about calling it pHibernate? Keeps the data moving, good for the bowels of your program, just use it then flush()?

Thats funny. The puns are endless especially if its a crappy program.

[bdunlap]

The puns are endless especially if its a crappy program.

[hantu]

I don't think a separate transaction ans session object are needed for PHP. Just one class for both would probably suffice. As a PHP script runs a single short lived process with no threads the most likely usage is a single transaction. If not then they can just create another with "new" as I doubt anything is shared between them.

Ok, I completely agree it's unnecessary. After a bit of reading in the Hibernate docu, I recognized that they will anyway flush the session, when you commit the transaction.

One solution might be a commit method that can take an object as an optional parameter and so remove it from the IdentityMap

I don't think thats very intuitive. I would suggest to have special options when loading them and marking them per hand to be updated:

$friends = $session->createQuery(...)
                   ->fetch(Query::IGNORE_CHANGE_TRACKING);

foreach ($friends as $friend) {
  $friend->send($gift);
  $session->update($friend);
}

$session->flush(); 

[lastcraft]

Hi...

I don't think thats very intuitive. I would suggest to have special options when loading them and marking them per hand to be updated:

I think that is too risky. In the event of a mistake, that object could be passed to other code that updated it. The result would be a partial commit of all of the changes. That's corrupted data, the worst case scenario for a persistence layer. Of course the same issue exists with my scheme as well .

Another possibility is to pull the read only objects from another transaction that cannot be committed at all. At least that way, although the commit would fail, everything would be consistent. This still requires care, because information that is needed from the writeable transaction would be different from the read only one. That happens rarely though, and it would all be explicit in the code.

The persistent memory cache would be some shared memory that persisted between page requests. You could use the in memory objects for comparisons during commits and you could pull objects from the database much more aggressively. The downside is that you then take on the burden of transactions. However this is less severe for fast in-memory reads (just lock all the shared memory) on a simple cache. This is all terribly complicated.

One complication is ordered queries. Say you want all people with names in alphabetical order. You have to pull all of the database IDs first and keep track of the ordering. Then you have to start a query to pull the data proper, but just those that are not loaded already. As the iterator runs through you need to pull either the cached object or the new one (filling the cache as you go). All good fun, but at least you would be replicating an app. server, making the porting easier.

But then another complication is what to do in the event of a crash of the machine holding the shared memory.

This whole thread gets to a problem I have had with DataMappers and PHP for some time. There is a real clash of priorities between them. DataMappers want to leave the domain objects free of database code, whilst PHP wants to make intelligent update decisions without keeping things in memory. The only way out seems to be some invasive watch on the getters and setters (decorators don't cut it) and hook them to keep track of the dirty status. That means Aspects.

yours, Marcus

[Brenden Vickery]

How do we know creating a persistent memory cache wont create just as much overhead as keeping a clone/reference does anyway? This seems like creating a bigger problem than the original problem for some reason.

I think we should keep in mind that people shouldnt be using this as a way to get the fastest performing data access code possible. They should be using it to support a changing domain model and quicker development.

If the code is measurably slow in places once its working, we should start thinking about optimizations then.

[arborint]

This whole thread gets to a problem I have had with DataMappers and PHP for some time. There is a real clash of priorities between them. DataMappers want to leave the domain objects free of database code, whilst PHP wants to make intelligent update decisions without keeping things in memory. The only way out seems to be some invasive watch on the getters and setters (decorators don't cut it) and hook them to keep track of the dirty status. That means Aspects.

I'm not sure I exactly understand the "whilst PHP wants to make intelligent update decisions without keeping things in memory" part. Do you mean: PHP wants you to make intelligent update decisions?

I understand that everyone would like it to be transparent, but it is too much to ask that (for the objects you want to be persistent) to be required to build the "invasive watch" hooks into the object via inherited get,/set methods or some other mechanism. Once you go with the "without keeping things in memory" idea, I think it is reasonable to require the extra work. In some ways it makes it more explicit which is in the PHP style.

Christopher

[mjlivelyjr]

Wow, start a thread, leave it for a week and it turns into 3 pages of useful information.

I have read through alot of the posts and would like to share my thoughts:

Requirements
I think it is vital that we do not place a php4 requirement on this project. If you take a look at the other popular java clones that are being created they are all geared towards php5. If we limit ourselves to php4 we are denying ourselves of the OO capabilities that php5 provides. When tyring to port a java library the new OO "stuff" is vital.

Framework
Some talk has been made of building this around wact. While I don't think it would be a bad idea to get some integration examples for some of the more popular frameworks, I don't think it would be smart to make it dependant on a framework. For one, most established frameworks are still maintaining bc with php4. For two, I like flexibility.

unit of work/memory issues/a bunch of other things
I am just throwing this out as a brain storm so feel free to shoot me down and tell me I'm silly, it won't hurt my feelings. A few things have been mentioned specifically about how to handle the Unit of Work pattern (I'm calling it UOW now, i'm lazy.) The big concerns have been making sure domain models will NOT be dependant on the UOW. As well as the memory drawbacks of keeping domain objects resident using a UOW. What about instead of keeping the domain objects resident figuring out a way to notify the UOW when the domain object is no longer needed at which time the UOW can get the mapper to build the query to persist (or remove) the object to/from the database and then release the object and just store the needed query. Like I said, just a thought that popped in my head and it's too late for me to make any kind of sane judgement on this myself.

In any case I am going to put it on my list of things to think about so maybe I can make a more intelligent post tomorrow.

Project Organization
It has been mentioned that sourceforge would be a pain to work with due to the fact that they are still sitting on php4. I have access to a server that would provide plenty of musce for a test bed and could provide cvs/ftp and limited ssh access to those that want to get involved. We could also set up a forum as it is starting to get somewhat tedious discussing this all in a single thread. I would just go ahead and set it all up but I don't really want to set it up if no one wants to use it and I don't want to duplicate efforts if someone else is already working on it.

In any case it's late and I need sleep.

[hantu]

...If we limit ourselves to php4 we are denying ourselves of the OO capabilities that php5 provides.

...While I don't think it would be a bad idea to get some integration examples for some of the more popular frameworks, I don't think it would be smart to make it dependant on a framework.

I completely agree with that.

I have access to a server that would provide plenty of musce for a test bed and could provide cvs/ftp and limited ssh access to those that want to get involved. We could also set up a forum as it is starting to get somewhat tedious discussing this all in a single thread.

I'd be the first one to join We need to collect some opinions to this.

I would offer the usage of a project management tool I worked on for a company, it's like a very intelligent forum with task states, responsibilities, email notification, milestones ...

[dylanegan]

I think getting up a project page would be ideal. I would certainly like to be apart of it, but current time constraints are stopping me, although I could still possibly partake in some sort of way.

[ponticelli]

Why, insted of opening another forum, don't we simply prepend something like [phibernate] in the subject of new posts here in Sitepoint?
I think that many more users should give their opinions.

[MiiJaySung]

This certainly is proving to be interesting.

The one thing that arborint rightly mentioned is that we still have little in the way of specs. I guess this is because at the moment this seems to going in the direction of a hibernate port, and therefore the concepts are assumed to be tried and tested to some degree.

Without some sort of spec, it becomes hard to proritise certain features, and possible requirements are left out. It would be best to analyse how most people want to use this. For a start, I'm not keen on the idea of the persistent memory caching thingy. It kinda goes against the shared nothing architecure of PHP (though at the same time I ca see why this is persistent memory caching is needed). Maybe I'm interpretting things wrong, but for an effective cache to work, you need something that obviously persists between requests. This requires something outside of PHP to be made to deal with this (there was a mentioning of "another VM"). I know PHP has unix SHM (shared memory) extensions built in; but, does this work well under Winblows? Iwould assume it works un Windows NT, but I can't see it working under 9X (not that anyone cares as 9X is dead and is no good for any form of serious developer/enterprise)....

This leads on to another problem with using shared memory in an "enterprise" scenario, where you might have a dedicated DB server and a number of boxes working as web servers. This is that each web server will have an in memory cache reflecting part of the DB. Each of these caches are working independently from each other, and therefore this leads us to another "worst case scenario". This leads on to the idea, we can shove a singe cache on the same box as the DB server. This adds a new dimension of complexity as we now need to make a caching system use some form of network / socket protocol for communication ON top of all the complex stuff the cache already has to deal with.

I kind of think the persistent memory caching thing might be over complex, and to me is not suited to PHP. Perhaps we are putting the code before the horse

At the moment, the main PHP5 ORM tool seems to be Propel. I guess we could partly say Entity has some play in things too. We should look look at requirements and usage scenarios. I've played with Propel, and it's weaknesses are starting to show. Propel tends to assume you have very business objects that map nicely into DB tables. This is not the case in more complex projects.

Trees, Class inheritance, and things like eBay's attributes system are some example usage scenarios. (One of our clients is a national property letting / estate agent, and properties tend to have a number of attributes tied to them that vary on a property to property basis and therefore a property object can have any number of different attributes tend to them. This sort of system doesn't work well in Propel as you end up with a property object and property attribute object that is very data centric (reflects DB table structure). I want something that I can customise more because the way properties and attributes are used in code is very different from what Propel generates, so i end up with a load of bloated base classes that hold loads of data centric methods that I don't use and I end up coding loads of stuff in the classes that extend from the base peer/object classes.)

All in all Propel becomes problematic when you have complex relationships where your in memory objects don't tend to be a direct reflection of your tables. Propel's criteria system also is a little unflexible in places too. I can't do LEFT JOINS, and subqueries with it. Also the Basepeer class that compiles the criteria to code also can't handle things where you have column aliases when you deal with aggregate functions. This is because it tries to resolve the aliased column in it's DB table / column maps.

Looking at flaws in features in other ORM tools might be a good way to build up a specification to work, along with provide some usage cases.

Keeping discussion in this forum would be best. This sort of project needs input from a large user base to become sucessful.

I swing towards PHP5. PHP4 is too ugly, and I can't see PHP4 being used for many future enterprise apps. This project will take time to develop, and therefore PHP5 will be mainstream when this becomes usable.

[lastcraft]

Hi...

I'm not sure I exactly understand the "whilst PHP wants to make intelligent update decisions without keeping things in memory" part. Do you mean: PHP wants you to make intelligent update decisions?

Sorry, I've been wrestling with these issues for a while and so I tend to blurt things out in an abreviated form. Here is a longer version of what I see as the core philosophical problem...

Say you read a big lump of data, say by "select * ...", and start iterating through the results. As you go through the list you want to adjust a subset of these and write them back. The way to do this is to do the updates in the loop and then discard them ready for the next cycle. That way you don't run out of memory. It means that you need to commit() the items yourself.

Now, say you are working on a complicated object graph. Some of the domain objects are passed around to other methods, some are newly created and some are modified, but you cannot remember which ones. Clearly you need an identity map to keep track of this. To do that you have to keep a reference to everything and the commit()/flush() must be made by the UnitOfWork.

This is a flat out contradiction.

With the DataAccessor approach the visibility changes and it's all easy. The objects can just tell the UnitOfWork when they have changed. There is even another possibility. In PHP5 we actually have a big advantage over Java - destructors. The UnitOfWork doesn't even have to know about the objects and when the object is released it can tell the UnitOfWork when it commits itself. We lose the IdentityMap this way, otherwise the IdentityMap will keep the object alive (unless we get to see thereference count), but that may be an interesting tradeoff. If the IdentityMap is in a transaction then that becomes an option of the developer. Use a transaction for the object graph problem, skip the transaction when iterating.

Anyway, I digress. None of these options exist with a DataMapper because we cannot tamper with destructors or anything else.

Because construction happens with the mappers, how about a dynamic proxy keeps track of the information? An invisible spy on the domain object? Well that doesn't completely work...

class Employee {
    function setPay($pay) { ... }
    function getPay() { ... }
    function addYearlyRise() {
        $this->setPay($this->getPay() * 1.05);
    }
} 

We know that the getter and setter should set the dirty flag in the proxy, but how do we know that addYearlyRise() does? Once we go under the skin of the proxy all bets are off.

With an in memory cache you don't have to worry about any of these issues (but you do get different ones) because it acts as the identity map and dirty flag. You don't have to worry about pulling in every object because you can release them back into the pool.

Note to the objections above. If you are using Win98 then a tool on this scale is unlikely to be of interest. Also can you always write through the cache, so actually a system crash is not so serious. You don't need any kind of Deamon running either, it's just passive memory. The work is still done from within PHP. It's only a cache with a few extra IDs.

I understand that everyone would like it to be transparent, but it is too much to ask that (for the objects you want to be persistent) to be required to build the "invasive watch" hooks into the object via inherited get,/set methods or some other mechanism. Once you go with the "without keeping things in memory" idea, I think it is reasonable to require the extra work.

This comes back to the mission statement of the library again. If you are building a Hibernate clone then you want to do everything possible to minimies the impact of the domain objects whilst still allowing any schema. Hibernate is the Uber tool. It's a complicated, but no compromise option. If you are not doing that then you shouldn't call it Phibernate. That name should be left for someone else.

yours, Marcus

[bdunlap]

This certainly is proving to be interesting.

I agree.

For a start, I'm not keen on the idea of the persistent memory caching thingy.

Me neither. I cringe with fear everytime I hear mention of it . While I'm sure it can be done (by someone other than myself), to implement something like that effectively seems daunting, to say the least. Or perhaps not. But it still scares me. It would, however, seem to be a necessity for a true port of Hibernate. So I guess it really depends on whether or not that's where we're going with this.

Which leads us to....requirements. Requirements, however general (and likely to evolve), are a must at this point. arborint's list in a previous post seems like a good start.

And I also agree with everyone else who has stated the same - strict PHP5 should be a requirement, for obvious reasons.

I'm still soaking up the multitude of thoughts and ideas in this thread, so you'll pardon me if I don't have anything particularly unique to offer the discussion at this time. I am very interested in contributing in some capacity, whether it be actual design/dev work, documentation or testing.

[DougBTX]

It would, however, seem to be a necessity for a true port of Hibernate. So I guess it really depends on whether or not that's where we're going with this.

Looks like it is just a "take the good ideas which map well to PHP" project rather than a replication - if not, it would be shame to copy features just becuse someone else has them.

Douglas

[arborint]

This comes back to the mission statement of the library again. If you are building a Hibernate clone then you want to do everything possible to minimies the impact of the domain objects whilst still allowing any schema. Hibernate is the Uber tool. It's a complicated, but no compromise option.

I think I would vote for making a PHP persistence thingy rather than a Hibernate port. I think learn from them and then solve our problem in a way that makes sense in PHP.

On the other hand, I don't think the shared memory thing is that scary. You could build it so the basic version sits on top of PHP's built-in session library. That would allow you to use it out of the box or use one of the several available DB backends for multi-server shared memory.

[Brenden Vickery]

Here are some links people may find of interest. Im still trying to get my head around the cache issue and thought others might be aswell.

http://www.awprofessional.com/articl...53736&seqNum=5

Also note this page about inserts and hibernate:
http://www.awprofessional.com/articl...53736&seqNum=3

Hibernate has an evict method which removes an object from the session cache.

[lsmith]

Hi,

I am also very interested in the topic. I have tackled the query building part a bit with the recent LiveUser_Admin rewrite. We now generate the queries on the fly. Basically the user specifies the fields he wants to fetch, the filters (as in the where conditions), ordering etc and LiveUser_Admin_Storage determines the necessary joins automatically.

There are some limitations in that currently all that is allowed are AND'ed statements without any parenthesis. It also doesnt handle stuff like GROUP BY and HAVING yet. This was mainly done in order to give us a realistic shot at implementing an XML based storage container.

Also we are not using objects for all of the entities, but this is not really a requirement obviously and can easily adapted.

Here are the relevant links:
http://cvs.php.net/co.php/pear/LiveU...in/Storage.php
http://cvs.php.net/co.php/pear/LiveU...torage/SQL.php

We havent done much in detail analysis about the performance yet though, but its been working quite nicely for us.

Just as a showoff:

The following query is generated from this API call:

$params_groups = array(
  'fields' => array('group_id', 'right_id', 'name'),
  'filters' => array('perm_user_id' => '1')
);
$lu->perm->getGroups($params_groups)

SELECT liveuser_groups.group_id AS group_id, liveuser_grouprights.right_id AS right_id, liveuser_translations.name AS name
 FROM liveuser_groups, liveuser_groupusers, liveuser_grouprights, liveuser_translations
 WHERE liveuser_groupusers.perm_user_id = 1
     AND liveuser_groups.group_id = liveuser_grouprights.group_id
     AND liveuser_grouprights.right_id = liveuser_rights.right_id
     AND liveuser_rights.right_id = liveuser_translations.section_id
     AND liveuser_translations.section_type = 4

Also note that the implementation of getGroups() basically requires only a list of tables that should be included in the join of needed. The table from which the joins are to be made (in this case the liveuser_groups table) and then a single call to actually generate and execute the query.

function getGroups($params = array())
{
  $selectable_tables = $this->selectable_tables['getGroups'];
  $root_table = reset($selectable_tables);

  return $this->_makeGet($params, $root_table, $selectable_tables);
}

Anyways .. just wanted to provide this as some food for thought. Like I said I am interested in the project and I am not trying to offer LiveUser_Admin_Storage as the solution. :-)

As for the choice of PHP4 and PHP5. To me PHP5 is not really more advanced in terms of OO. The two real advantages boil down to more reliable interceptors (__get(), __set(), __call()) and not having to pass objects by references anymore. The other stuff is (useful) syntax sugar. One of the more useful syntax sugar additions are no doubt interfaces. These could proof to be a very useful addition to this project.

However I think it would be wise to attempt to write this thing in PHP4, making specific notes about things where we actually get hurt by a PHP4 limitation and then making a final decision later. For example interceptor support my in the end just make the API more convinient for users by making it possible to shorten API calls and lazy loading certain things. But shutting out PHP4 users when its not necessary is obviously worse than having a less convinient solution in PHP4 as long as it doesnt significantly diminish the usefulness in PHP5.

[lsmith]

There is some benefit in porting an existing java project. Mainly it helps people migrate. It also means that you can benefit from the literature. It also prevents you from larger API mistakes since its not that trivial to identify the good things and making sure they also end up in a PHP project with similar aims.

However there is the huge danger of ending up with an inferior clone that doesnt solve things in the best way possible for PHP. So again I would say there is nothing wrong with starting with a port as long as from day one nobody religiously tries to follow that API without always stepping back and asking: "Does this make sense for PHP too?"