Macros for Program Generation

Questions / Help
,
1

I watched a video in the forum (which I can’t find now) about someone generating pretend OOP code for Elixir as a joke and jab at OOP.

That video got me thinking…

Is it possible to use macros to roughly translate an OOP, web-framework, PHP application into Elixir?

I’m not talking generating 100% correct and compile-able Elixir but rather, a library of macros to do most of the heavy lifting of the conversion, followed by whatever amount of manual code clean-up is necessary to get the Elixir code compile-able/runnable?

Failing that, has anyone ever tried to convert a large PHP web application into Elixir? What were the gotchyas and pain points?

2

The library should be this: OOP.

OOP in the BEAM VM (and thus also Elixir) is mostly made possible by tuple calls. Relevant and good discussion: Tuple Calls.

However, Erlang OTP 21.0 is released and, well:

“Tuple calls” have been removed from the run-time system.

Not sure if the OOP library is making use of those; there should be other ways but IMO the OTP 21 release signals that the Erlang maintainers are not focused on supporting such mechanisms of the BEAM and thus, indirectly, are not interested in emulating OOP. I am not informed about the exact reason though (most likely a technical and not a conceptual one I’d guess), just giving you some pointers if you want to research further.

1 Like
3

I haven’t, but hopefully I’ll offer you some food for thought because I used to code PHP for a living years ago.

  1. Reliance on global state and data / logic / views / partial views already magically inserted in view or controller file before the interpreter even gets to the first line of code of the function that is supposed to serve the request. It would probably be extremely hard to track down everything that happens behind the curtains and emulate it with explicit function calls or Plugs. It might be possible with some find and awk (or sed) magic with shell scripting but success is not guaranteed at all. Your best bet for automation would be ad-hoc scripts that encode intimate knowledge of the PHP framework and the project’s structure plus utilize some text parsing, and even that is quite fragile…

  2. Implicit mutations of data would make it a nightmare to track data changes in big files. Consider this PHP code:

$x = 1;
echo $x . PHP_EOL;
// yields 1

$y = &$x;
echo $y . PHP_EOL;
// yields 1 again

// ...a lot of lines of code later...
$y = 123;

// ...some more lines of code later...
echo $x . PHP_EOL;
// yields 123 and not 1 as you would expect and you will be "WTF?!"

Try it online here if you like: http://sandbox.onlinephpfunctions.com/

Such patterns are extremely common in imperative languages that offer pass-by-reference (or pointers) and tracking all the data changes inside your brain is very taxing and error-prone. You will inevitably make a mistake. :frowning:

  1. Many legacy PHP websites rely exclusively on MySQL; ORM-less MySQL statements are plastered everywhere. It would be quite the endeavor to convert that to Ecto code.

I am not saying it’s impossible but it’s tricky and slow. And that’s a show-stopper for most businessmen.

4

Thanks for your answer.

I wasn’t looking to mimic OOP behavior in Elixir, but rather take PHP code that happened to be in a OOP paradigm and rewrite all of the PHP code (ignoring the mechanics that enables the OOP to work correctly) into Elixir code.