Перенос приложения Ruby / Rails на PHP 5

У меня есть очень большое приложение Ruby on Rails, которое я хотел бы перенести на PHP 5.2 или, может быть, на PHP 5.3 (если 5.3 когда-нибудь будет выпущена).

Я искал способ автоматического преобразования таких простых вещей, как простые классы и шаблоны ERB. Я ожидал, что мне придется самому делать более сложные вещи в тех случаях, когда языки слишком разнятся.

Может ли кто-нибудь предложить подход к этому? Или сценарий, который может кое-что из этого автоматизировать?

Обновлено:

Для этого есть экономическое обоснование. Другой вопрос, который я не собираюсь обсуждать здесь, - это разумное экономическое обоснование. У нас есть фреймворк, достаточно похожий на Rails - реальная проблема заключается в преобразовании из Ruby в PHP, а не из Rails в PHP. На самом деле я не ищу что-то, что волшебным образом сделало бы всю работу, просто что-то простое, что даст толчок. Даже если бы все изменилось:

def somemethod somearg
  some.ruby.code
end

к:

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

и оставил внутренности рубиновыми в комментариях php, что все равно упростило бы работу.

В идеале должно быть что-то, что уже делает это или подобное. В противном случае мне, возможно, пришлось бы самому писать инструмент.

Я не хочу обидеться, спрашивая это, мне просто любопытно, почему вы хотите это сделать?

Tom 23.01.2009 09:37

Это нетривиальная задача, даже если вы портировали на фреймворк Rails-clone. Я не завидую вам и не советовал бы делать это любой ценой (особенно если это просто что-то глупое, например, ваш новый общий хост, не имеющий поддержки Rails - найдите другой)

J Cooper 23.01.2009 09:49

Я с Thaggie, я не могу придумать ни одной причины, по которой кто-то в здравом уме обменял бы RoR на php

Robert Gould 23.01.2009 10:32

Производительность может быть причиной или ноу-хау. На данный момент на рынке труда больше людей, которые могут (или думают, что могут :)) кодировать PHP, чем рельсы.

Skaldrom Y. Sarg 23.01.2009 13:04
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
3
4
3 201
5
Перейти к ответу Данный вопрос помечен как решенный

Ответы 5

Перенести приложения между любыми двумя языками - нетривиальная задача. В этом случае все еще хуже из-за различий между php и ruby. Вы не можете надеяться получить для этого какой-либо автоматизированный процесс.

Если вам нужно это сделать (а Зачем - это отдельная история), вы можете попробовать использовать один из php-фреймворков, наиболее близких по дизайну к рельсам. Лучшими кандидатами, вероятно, являются Symfony или Поддерживаемый PHP-фреймворк.

Но мне интересно - в чем причина этого начинания?

Обновлено:

В php многие символы являются глобальными и неизменяемыми после определения. Например, классы и функции нельзя переопределить, а также нет поддержки пространства имен. В Ruby можно - и очень часто - управлять классами во время выполнения. Это невозможно преобразовать автоматически, а во многих случаях просто невозможно. Даже если вы взломаете его с помощью магических методов phps (__get / __set / __call), снижение производительности будет настолько серьезным, что сделает ваше приложение непригодным для использования. Единственный способ сделать это - вручную.

Возможно, вы могли бы использовать такой инструмент, как шарить, чтобы дать вам отправную точку. См. Также это, чтобы узнать больше об инструментах ruby-to-uml.

Ответ принят как подходящий

Я полностью согласен с troelskn, это масштабное мероприятие, и я думаю, что вам очень мало удастся найти какую-либо форму автоматизированного процесса для переноса приложения.

Лучше всего найти фреймворк, который очень похож по дизайну, и портировать все классы один за другим.

Самое утомительное здесь будет там, где задействована база данных. Насколько мне известно, до сих пор нет ORM-решения для PHP, которое даже близко подошло бы к ActiveRecord Rails. Вам придется самому написать большую часть связующего кода кода базы данных и самостоятельно написать все средства поиска моделей и т. д. С момента последней проверки в этой области могли быть некоторые улучшения, но PHP по своей природе имеет некоторые проблемы с шаблоном проектирования ActiveRecord.

Опять же, я должен повторить то, что, я уверен, многие люди думают ... почему на земля вы хотите переносить приложение с RoR на PHP. Это звучит как дорогостоящая вещь, как по времени, так и по деньгам, без явного преимущества - если, конечно, вы не натолкнулись на стену с Ruby, где он просто не может делать то, что может сделать PHP. И мне трудно в это поверить.

Позвольте мне рассказать вам историю об автоматизированном преобразовании программ ...

Несколько лет назад я работал в учебном заведении. Это учебное заведение использовало ERP-систему на основе $ ENTERPRISE_DB_VENDOR и использовало ее уже около 20 лет. Исходная система была написана на COBOL и на каком-то инструменте / языке отчетности $ ENTERPRISE_DB_VENDOR. С годами инструмент отчетности устарел (и был добавлен C). В какой-то момент $ ENTERPRISE_DB_VENDOR отключил инструмент. К сожалению, на нем все еще были написаны важные компоненты.

«Самым простым» решением было для какого-нибудь блестящего разработчика из $ ERP_VENDOR написать инструмент преобразования, который переводил бы инструмент отчета на C. Почти не поддающийся расшифровке, явно сгенерированный компьютером, но все еще отлично работающий C. Насколько я понимаю, план состоял в том, что это должно было стать временной мерой, чтобы заставить продукт работать сейчас, но эти вещи будут переписаны вручную, «скоро».

Перенесемся на 10 лет вперед ... одним из моих первых заданий было разместить в сети какой-нибудь отчет - отчет, который изначально был написан на старом языке отчетов. Затем он был преобразован в C. Он никогда не переписывался - люди просто вносили «небольшие изменения», чтобы добавить небольшие функции или исправить ошибки. Да. Они входили и вносили изменения в сгенерированный компьютером C.

Подумайте об этом на минуту, прежде чем подумать о попытке написать инструмент автоматического преобразования.

Я хочу верить, что вы это выдумываете, но глубоко внутри я знаю, что это не так.

troelskn 24.01.2009 01:16

Подобные сумасшествия с компаниями, цепляющимися за свои старые приложения на COBOL, были чрезвычайно распространенным явлением. Многие гигантские компании никогда не хотели нанимать команду, чтобы все переписать.

JamesHoux 17.11.2012 14:14

Просто случайная мозговая волна, которая может помочь

Используйте JRuby для получения кода промежуточного языка JVM, а затем сгенерируйте из него код PHP.

Я оставлю это вам, чтобы проработать детали!

Этот рубиновый драгоценный камень утверждает, что может конвертировать рубин в php. Не тестировал, но стоит попробовать. https://rubygems.org/gems/php http://php.rubyforge.org/

Другие вопросы по теме