Hi internals.
I started a work of refactoring magic methods from internals.
The first goal was to never write ourselves things like "__get", but use
macros for those names. (get, set, invoke, etc...).
A second goal was to rewrite some parts of the compiler which looked like
code duplication which could benefit from macro refactoring.
I did that.
All tests pass.
It may look uglier for people who dont like having more macros, but anyway,
we can cherry pick some commits, etc...
If you have ideas or things to say, I'm listening.
https://github.com/jpauli/php-src/compare/macroing
Julien.Pauli
If you have ideas or things to say, I'm listening.
https://github.com/jpauli/php-src/compare/macroing
Is there a reason you switched from names like __toString to __tostring
(https://github.com/jpauli/php-src/compare/macroing#L2R12)?
Visually the macros clean things up a lot and better convey the intent
behind the if / else if chain. However, I don't really like having a macro
that works off of an ELSE, it just feels wrong. I don't have a better
suggestion though.
On Fri, Aug 2, 2013 at 9:55 PM, Levi Morrison morrison.levi@gmail.comwrote:
If you have ideas or things to say, I'm listening.
Is there a reason you switched from names like
__toStringto
__tostring(https://github.com/jpauli/php-src/compare/macroing#L2R12)?
Yes because I use the same word for structure members access and for error
message. That makes the refactoring takes place actually, if I had to
change just one letter to capitalize it for just one method, that would add
lots of code just for treating that particular case :-p
Visually the macros clean things up a lot and better convey the intent
behind the if / else if chain. However, I don't really like having a macro
that works off of anELSE, it just feels wrong. I don't have a better
suggestion though.
Yes elses inside macros are not a good idea, I pushed a different
implementation having elses out of macro definitions.
Julien.Pauli
Hi internals.
I started a work of refactoring magic methods from internals.
The first goal was to never write ourselves things like "__get", but use
macros for those names. (get, set, invoke, etc...).A second goal was to rewrite some parts of the compiler which looked like
code duplication which could benefit from macro refactoring.I did that.
All tests pass.It may look uglier for people who dont like having more macros, but anyway,
we can cherry pick some commits, etc...If you have ideas or things to say, I'm listening.
https://github.com/jpauli/php-src/compare/macroing
I'm not really a fan of heavy macro usage, so here an alternative
suggestion:
https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409
Basically, instead of going through all the magic methods manually we
define a structure holding information on magic methods and then loop
through it doing generic checks.
The above example only changes zend_check_magic_method_implementation, but
the idea can be generalized to the other occurances of magic method checks
(making the structure a global constant so they can all make use of the
information in there.)
Nikita
Hi internals.
I started a work of refactoring magic methods from internals.
The first goal was to never write ourselves things like "__get", but use
macros for those names. (get, set, invoke, etc...).A second goal was to rewrite some parts of the compiler which looked like
code duplication which could benefit from macro refactoring.I did that.
All tests pass.It may look uglier for people who dont like having more macros, but
anyway,
we can cherry pick some commits, etc...If you have ideas or things to say, I'm listening.
https://github.com/jpauli/php-src/compare/macroingI'm not really a fan of heavy macro usage, so here an alternative
suggestion:https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409
Basically, instead of going through all the magic methods manually we
define a structure holding information on magic methods and then loop
through it doing generic checks.The above example only changes zend_check_magic_method_implementation, but
the idea can be generalized to the other occurances of magic method checks
(making the structure a global constant so they can all make use of the
information in there.)Nikita
I think I like Nikita's version better. Fewer macros are nicer in my
opinion.
On Thu, Aug 29, 2013 at 5:59 PM, Levi Morrison morrison.levi@gmail.comwrote:
On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov nikita.ppv@gmail.comwrote:
Hi internals.
I started a work of refactoring magic methods from internals.
The first goal was to never write ourselves things like "__get", but use
macros for those names. (get, set, invoke, etc...).A second goal was to rewrite some parts of the compiler which looked
like
code duplication which could benefit from macro refactoring.I did that.
All tests pass.It may look uglier for people who dont like having more macros, but
anyway,
we can cherry pick some commits, etc...If you have ideas or things to say, I'm listening.
https://github.com/jpauli/php-src/compare/macroingI'm not really a fan of heavy macro usage, so here an alternative
suggestion:https://github.com/nikic/php-src/commit/375bd7911fd117696b8b5d63c104fd588d69c409
Basically, instead of going through all the magic methods manually we
define a structure holding information on magic methods and then loop
through it doing generic checks.The above example only changes zend_check_magic_method_implementation, but
the idea can be generalized to the other occurances of magic method checks
(making the structure a global constant so they can all make use of the
information in there.)Nikita
I think I like Nikita's version better. Fewer macros are nicer in my
opinion.
I like yes, I think we can mix both by having a global containing all magic
method infos, and some macros to use them.
I'll propose another patch based on that ;-)
Thank you,
Julien.Pauli