View variables are surprising, (bug or feature?)

<?php $a = 2; ?>
<?= $this->partial("path/view", ["a" => 1]) ?>
<?= $a ?>

Surprisingly that prints 1, instead of 2, is this a feature? or a bug?

The local variables in the views behaves like globals

This in php7.0 and phalcon 3.x

I think this is happening only in php 7 due to changes to symbol table.


Any solution other than preffixing the variables with the view name?

It adds a lot of work to name variables like $path_view_a.

Why zephir is not executing the require as php does? (in the context of the method)

I am not sure if this is a bug in zephir or a "new feature"

This is not about require. This is about render:

As i told you, symbol tables where changed on php 7. There must be changes done to zephir in order to support what you want to achieve in php 7. On php 5.6 your code will work correctly. If you want you can create issue on zephir about this.


As I told you, it is a problem in the scopes (or the stack)

See this page:

But is not setting them to the local scope.

2 possibles explanations: Zephir is setting locals as static locals or globals (because it is still referencing to the same value in memory, even if it is in a different function call.

Said this, this is a new not documented feature or a bug.

All of this, or require doesn't execute in the function scope and execute in a global scope.

So, if a team member can confirm that indeed this is a bug, and not a feature, the bug can be created

edited Oct '16

As i already told you. This is because of PHP 7 and zephir. On PHP 5 it works fine. Just this is broken for php 7 and is not working correctly. Anyway, i will check it to be sure in home. But latest i was talking with some team member this symbol tables changes and not yet changed properly zephir is creating issue like yours.

Well btw anyway variables names like $a is really bad :D


Yes, you are partially right. Like path and view are bad names for a directory name and view name. But in the example context , those names are excellent ;) (Anyway, this is bikeshedding, I guess you were trolling)

Yes, I get the idea, it is creating the table. But in the zephir documentation is written this should happen anyway

All variables declared are locally scoped to the method where they were declared

or (the title refers to the local scope, but "current PHP symbol table", so aren't they the same?)

Yes - and it's working fine for php 5. But as i told you there were some changes in symbol table for php 7. Zephir is not updated for it yet, it needs some changes to work properly with this example of your - this is why it's not working. Check your code on php 5. It should be fine.

Hi there,

Has this been fixed yet ? It's quite an important problem...

Thank you

This one just bit me. print_r to the rescue and jaw dropped. Hopefully this can be cleaned up for Phalcon 4.

Its unfortunate that Phalcon has almost $13k now and development is stagnant. Meanwhile pull requests just sit there waiting for a particular single person to have time and the new strategy of handling issues is simply to delete them after three months of inactivity. Seeing how almost nothing is being done to the project you can easily predict the fate of a new issue. The level of community involvement in actual code is incredibly "meh" at best and who can blame them. Other than docs and a forum this project is not a community effort, its a play thing of the core Phalcon team to do as they please, or not to do. They get tired and utterly burnt out leaving delapated code without having contigency plans in place such as the having other people who can authority and competency to affect change. Phalcon is always going to suffer from this because the core team holds their cards too close to the chest.

I agree, we should hire some c programmer with knowledge of php and zend engine to fix those issues.

The project is asleep at the wheel after heavy boozing. Its not too late to wake up after running over the center dividers and just round it out as a big night.

This might have been fixed in Phalcon 3.4.2.