Re: [PHP-DEV] Refactored magic methods

2013-08-29 Thread Julien Pauli
On Thu, Aug 29, 2013 at 5:59 PM, Levi Morrison wrote:

> On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov wrote:
>
>> On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli  wrote:
>>
>> > 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
>>
>
> 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


Re: [PHP-DEV] Refactored magic methods

2013-08-29 Thread Levi Morrison
On Thu, Aug 29, 2013 at 5:00 AM, Nikita Popov  wrote:

> On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli  wrote:
>
> > 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
>

I think I like Nikita's version better. Fewer macros are nicer in my
opinion.


Re: [PHP-DEV] Refactored magic methods

2013-08-29 Thread Nikita Popov
On Fri, Aug 2, 2013 at 6:47 PM, Julien Pauli  wrote:

> 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


Re: [PHP-DEV] Refactored magic methods

2013-08-05 Thread Julien Pauli
On Fri, Aug 2, 2013 at 9:55 PM, Levi Morrison wrote:

> 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)?
>

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 an `ELSE`, 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


Re: [PHP-DEV] Refactored magic methods

2013-08-02 Thread Levi Morrison
>
> 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.


[PHP-DEV] Refactored magic methods

2013-08-02 Thread 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


Julien.Pauli