Avoiding the creation of a meta programming language

PHP
41

It’s very hard to read this thread and not to chime in… Quite the opinions floating around already! :slight_smile:

Michael, to respond to your OP, it comes down to this - which level of abstraction do you want to work in. The larger your codebase gets at the initial level of abstraction, the more you have to repeat yourself, and the more code you write (think of building a massive tower). Building up is not always good. There comes a point where it becomes more efficient and manageable to build more and more foundation to support the growth. The language you describe this in usually becomes more of your domain knowledge - or at least tied to the relevant domain / layer you’re working at. Building blocks make sense in the context of Magento or layouts. It’s English and readable. Defining routes as configuraiton makes a lot of sense, and is a lot more convenient and maintainable than writing the generated code manually.

By creating another layer, in this case the meta programming - essentially configuration - you can replace a lot of the repetitive code with something much much more readable. This adds a lot of complexity to the library code, but it keeps your actual application simple to read which is the primary goal.

Now, the other question - is it actually necessary. It depends… if you don’t like it, then you should probably use a framework or tool that’s not as configurable. These tools are meant to be highly configurable (configuration over convention). In the examples given, the resulting functionality is nothing alike.

$baseUrl . '/posts/?id=x

vs

{{ _path('_posts_view', post) }}

The latter is configurable. You can modify how routes are generated - you can even change the URLs entirely. You can apply SEO rewriting (if it wasn’t done yet, etc.) Same for Javascript / CSS includes. Using assetic or similar tools is also massively different from not - you can automatically combine assets, apply filters (minification, obfusication, etc.) at (first-)run-time. You can easily append unique version identifiers and set your cache expiry years ahead of time and never worry about cache expiration woes. You can easily add more JS or CSS dynamically, and also apply these factors.

All these functionalities are added or applied externally. This is the difference. It’s not necessary most of the time, but when you work on larger projects, it’s extremely beneficial. Symfony2 and Magento especialy are targetted towards people who want to configure or modify them quite extensively.

Just my 2c.

42

vs…


makePath('post',$postNumber);

Which is why these ‘metalanguages’ are just stupid… in most cases adding a complex parser on top of the language instead of just SHOCK using the existing language – it’s almost like people are afraid of functions and methods, and would rather have needlessly cryptic one letter variables and even more cryptic/nonsensical nesting of oddball characters.

43

The no-framework PHP MVC framework
is a simple example of how you can use PHP as-is, without additional complex external layers, to apply an MVC approach with clean and simple views and still have all the goodness of fancy Web 2.0 features. If you think I am out to personally offend you and your favourite framework, then you have the wrong idea. I just happen find most of them too complex for my needs and this is a proposed alternative. If you have found a framework that works for you, great.

Sounds familiar? http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html

A little more research: http://negative11.com/

It has already been taking care of, no need for another vanilla MVC. Not that some good frameworks out there forbid you to make the choice of also go vanilla on them, views, templates and the works. And it’s not like it’s been impossible to do if not: implements, extends. You know, OOP keywords. No, they just offer a choice for something else beside vanilla PHP. Which is good… because you have a choice now… as opposed to having but one choice… which is not so good.

And I agree. PHP should be enough. No need for metalanguages like HTML or CSS. Enough! (HI: The author is being ironic)

N.B. HI Humor impaired

44

It should be called Inner Platform Repair. PHP is not perfect, it could be called itself a poor replica of another language or be looked at as a beast of two worlds, both qualities and flaws.

FIX IT! (HI: SNL’s Oscar Rogers FIX IT!)

<hr>

Programming doesn’t have to suck, especially with high level languages, which are specifically designed for a larger audience than your medium level programmer; it’s for low level, amateur programmers or even non-programmers.

Which is not to say that using PHP makes for a low level programmer. Sometimes there is no other alternative for medium to high level programmers. Maybe that’s why we see so many variants, because PHP is tackled by so many various individuals having various professional levels.

N.B. HI Humor impaired

45

“no-framework”


  <script type="text/javascript" src="/yui/YAHOO.js"></script>
  <script type="text/javascript" src="/yui/dom.js"></script>
  <script type="text/javascript" src="/yui/event.js"></script>
  <script type="text/javascript" src="/yui/connection.js"></script>
  <script type="text/javascript" src="/yui/animation.js"></script>

Right…

“model”


protected function fatal_error($msg) {
    echo "<pre>

Right…

“controller”


  echo json_encode

Right…

Wow, that was good for a laugh.

46

I only brought it up because the author seems to have the same reasoning as the OP, and the same goal, that is teaching over functionality: it’s in his toy page.

He also means no-PHP framework and he is honest about what he uses:

The main pieces are:

PHP 5
Yahoo! User Interface Library
JSON

being that he also engineered for Yahoo! at the time. And he is “Original author of the PHP scripting language”.