zephir
zephir copied to clipboard
zephir-lang
Add support for traits.
@phalcon
Notify about use newer version? 5.3 is not supported at the global community EQL
http://php.net/archive/2014.php#id2014-08-14-1
Does Zend Core support traits? As I know (from opcodes), traits just merges methods into class definition. So we can do the same thing at least in php5.3.
It's a different class type, only available in PHP >= 5.4
http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.h#161
@phalcon so we could merge trait's methods into every class that uses it for 5.3.
Yeah, implementing traits would be easy as you describe, I mean exposing traits as part of the extension will not be possible. They will look as standard classes.
:-1: There is more important part to implement, like references. I think it would be more interessting to stabilize the language before adding this type of feature.
Trait is an usefull and powerfull feature, though it's only compatible with 5.4 and latter, it mays be used. Trait are very new in php and people dont use it a lot, mainly cause of 5.3 not being compatible, but i mays change over the years
And we cant just merge trait method in the class that use it at the compilation because we wont be able to use the trait from the php code.
I'm up to implement it because it's now in the core of php
I tend to agree with what fezfez said. We might want to stabilize zephir before adding new features. With php parser and abstract syntax tree, we will always be able to merge the code in trait into individual classes.
By only merging traits into classes, you wlil break the API. Traits are not used only inside the library, they are also usable outside a library. Better no implement them rather than merge methods.
I mean Zephir giving up support for PHP 5.3. There are problems when running Zephir extensions on PHP 5.3, which I can hardly trace. By giving up support for PHP 5.3, Traits are reasonable features for Zephir.
In my tool PHP-To-C-Ext, it now allows using trait to build zephir based php extensions. Under the hood it just merge all functions in the trait into individual classes.
https://github.com/jimthunderbird/php-to-c-extension#example-07
Traits are not aimed to be merged into class. If you want zephir to support this feature , just create another type specific to zephir, and call it mixin for instance.
A php class that uses a trait is NOT compatible with php 5.3 and so should go for zephir. You should see traits as a part of the public API, not as something used internaly in the library.
Sometimes traits are even not used internaly in the library, they are just utilities available for everyone that use the library.
Believe me or not, but merging traits into classes and throwing them away from the final extension will bring a lot of confusions.
Judging by this infographic http://php.net/supported-versions.php Soon we will lose the support of 5.4. Maybe it's time to use Traits? :)
It would be nice if zephir support trait as a built-in structure, if not, right now I am still going the method merging ways, developers have options not to use trait. https://github.com/jimthunderbird/php-to-c-extension
I figure there are three ways to use traits within Zephir:
- As Zephir traits to add functionality for Zephir classes
- As PHP traits to add functionality for PHP classes
- As a combination of both
I think no.3 is powerful, but confusing. I think no.1 is nice, but I think most useful would be no.2? Best would be both no.1 and no.2, where 1 trait is not both for Zephir and PHP.
Like suggested it would be good to make them distinct: mixin for Zephir (no.1), trait for PHP (no.2). No.3 would be implicit be no.1 and no.2. That is confusing. I think if functionality is shared, a no.2 that implements no.1 for example would be better maintainable.
@aschwin zephir is like a layer on top of C with zend Api. Imo it would be best to make it as transparent as possible so that a class in zephir is a class in php and a trait in zephir a trait in php. If you want to hide stuff from php it would be best to use a technique like optimizers. This technique could probably be extended with more funtionality (on the part of the zephir programmer), but implementing this can be much harder. For example if you want to hide a zephir class from php, because all the classes are registered with the zend api, it would require custom logic so that they can not be used in php.