Improved template variable handling

[anlutro]

PHP magic methods can be used to imitate getting/setting of public variables on objects. This gets rid of the ugly $internal property, which means $template->internal is no longer a reserved variable name, and the Template code is a lot clearer.

[coveralls]

Coverage decreased (-0.55%) when pulling 9a4656f on alprs:fix/variables into 8733232 on thephpleague:master.

[anlutro]

Also, unless I'm missing something, this should make #9 trivial.

extract($this->variables, EXTR_REFS);
// render template
foreach (array_keys($this->variables) as $key) unset($key);

The unset bit is probably not even necessary.

[reinink]

At first glance this looks good. Unfortunately it doesn't help with issue #9—the challenge there isn't extracting the variable available before you render, but rather those created while rendering.

Nonetheless, this looks like an improvement. I'm going to have a closer look, and unless I find any issues I'll pull it in. Thanks for your interest and help on this project!

[anlutro]

You mean in terms of <?php $this->title = 'foo'; ?> being available as $title?

[reinink]

Exactly, and those variables created while using sections.

[reinink]

@anlutro You have me thinking about this now. Some things have changed with Plates over the last year, and handling variables that way may actually now be possible.

Edit: I'm going to continue this discussion in #21.

[anlutro]

I don't know why this didn't cross my mind until now, but because the include is being called inside a class method, the protected variables are still available as $this->engine etc. in the template file - which kinda makes this change more pointless than I assumed :(

[reinink]

Haha, yeah, I was going to say that earlier, but you actually led me to removing the need for $this before all template variables (see #21), so while this change isn't going to help Plates 2.x, it was the first step towards Plates 3.0.