tags:

views:

539

answers:

4

I have a very large Ruby on Rails application that I would like to port to PHP 5.2 or maybe PHP 5.3 (if 5.3 ever gets released).

I've been looking for a some way of automatically converting the simple stuff like simple classes and the ERB templates. I would expect that I'd have to do the more complicated stuff myself in cases where the languages are just too dissimilar.

Can anyone suggest an approach for doing this? Or a script that can automate some of it?

EDIT:

There is a business case for doing this. Whether it is a sound business case is another issue which I don't care to discuss here. We have a framework that is similar enough to Rails - the real issue is conversion from Ruby to PHP rather than Rails to PHP. I'm not really looking for something that will magically do all the work, just something simple that will give a headstart. Even if all it did was change:

def somemethod somearg
  some.ruby.code
end

to:

public function somemethod($somearg) {
  // some.ruby.code
}

and left the innards as ruby in php comments that would still make the job easier.

Ideally there would be something out there that does this or similar already. Otherwise I might have to the write tool myself.

+6  A: 

It's a non-trivial effort to port applications between any two languages. In this case, it's even worse, because of the dissimilarities between php and ruby. You can't hope to get any kind of automated process for this.

If you need to do this (And the why is a different story on its own), you could try to use one of the php-frameworks that are closest in design to rails. The best candidates are probably either Symfony or Maintainable PHP Framework.

I wonder though - What are your reason for this undertaking?

EDIT:

In php, a lot of symbols are global and immutable, once defined. For example, classes and functions can't be redefined, and there is no namespace support either. In ruby, it is possible - and very commonly used - to manipulate classes at runtime. This is impossible to convert automatically, and in many cases just plain out impossible to do. Even if you hacked around it with phps magic methods (__get/__set/__call), the performance penalty would be so severe, that it would render your application unusable. The only way to do this, is by hand.

You could perhaps use a tool, such as rumld to give you a starting point. See also this, for more ruby-to-uml tools.

troelskn
+1  A: 

I completely agree with troelskn, this is a massive undertaking and I think that you'll have very little luck finding any form of automated process for porting the app.

Your best bet is finding a framework that is very similar in design and porting all the classes one by one.

The most tedious thing here will be where the database is involved. As far as I know, there is still no ORM solution for PHP that comes even close to Rails' ActiveRecord. You'll have to write a lot of the database code glue code yourself, and write all the model findersm, etc yourself. There may have been some improvements in this area since last time I checked, but PHP by nature has some problems with the ActiveRecord design pattern.

Again, I have to echo what I am sure a lot of people are thinking... why on Earth would you want to port an app from RoR to PHP. It sounds like an expensive thing to consider, both in time and money, with no clear advantage -- unless of course you've hit a wall with Ruby where it simply can not do something PHP can do. And I find this hard to believe.

bjeanes
+2  A: 

Let me tell you a story about automated program conversion...

A few years ago I worked for an educational institution. This educational institution ran an $ENTERPRISE_DB_VENDOR-based ERP system, and had been doing so for about 20 years. The original system was written in COBOL & some $ENTERPRISE_DB_VENDOR reporting tool/language. Over the years, the reporting tool was deprecated (and C was added). At some point, $ENTERPRISE_DB_VENDOR killed off the tool. Unfortunately, there were still important components written with it.

The 'easiest' solution was for some brilliant developer at $ERP_VENDOR to write a conversion tool that translated the report tool into C. Nearly indecipherable, obviously generated by a computer but still perfectly functional C. From what I understand, the plan was that this was going to be a stopgap measure to get the product working now but, these things would be rewritten, manually, 'soon'.

Jump forward 10 years... one of my first assignments was to put some report on the web - a report that had originally been written in the old report language. It had then been converted to C. It had never been rewritten - people simply made 'little changes' to add small features or fix bugs. Yes. They were going in and making changes to the computer-generated C.

Think about this for a minute before you consider trying to write an automated conversion tool.

Sean McSomething
I want to believe that you're making this up, but deep inside I know that you aren't.
troelskn
A: 

Just a random brainwave that might help

Use JRuby to obtain the JVM intermediate language code and then generate the PHP code from that.

I'll leave it to you to work out the details!

Noel Walters