Re: [PHP-DEV] Aspect Oriented Programming in PHP
Your argument is a general issue when refactoring code. Whenever you change the name of a method/class, you need to change it in all the places that use it, even in the AOP definitions if you have it of course. The advice is just a PHP callable so it works in the same way. 2012/8/23 Sebastian Krebs krebs@gmail.com Hi, From my users point of view: I would like to see it. Maybe not in this implementation/syntax, especially because it hasn't a special syntax (but imo it should to make the impact more obvious/prominent). With the joint points as string and the common function call I can imagine it can get hard to find out, where a specific advise where attached, or which were attached at all, or just how many. For example I rename a method/class and I will not recognize, that a security advise gets lost, I may realize it as soon as I find my data on pastebin ;) But I have no idea how it could look like Regards, Sebastian Am 23.08.2012 16:36, schrieb Peter Nguyen: Hi, AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programminghttp://en.wikipedia.org/wiki/Aspect-oriented_programming) when used correctly, can make your application really modular. I've seen several implementations but they all require compiling of code beforehand. There is however a PECL extension now (https://github.com/AOP-PHP/**AOPhttps://github.com/AOP-PHP/AOP) that enable AOP in PHP directly. I was wondering if there are any interests/possibility to include AOP into the PHP core? Best regards, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aspect Oriented Programming in PHP
2012/8/24 Peter Nguyen pe...@likipe.se Your argument is a general issue when refactoring code. Whenever you change the name of a method/class, you need to change it in all the places that use it, even in the AOP definitions if you have it of course. The advice is just a PHP callable so it works in the same way. I talked about refactoring the joint points, not the advises, but thats not the point. If I refacter an identifier my IDE (I use PhpStorm, but the others should be that powerful too) supports me by searching for every occurence of the identifier, or even without the need to refactor stuff I can call find usage. With a string like $ 'Classname::method()' or $ 'Classname-method()' I need at least text search, that should work reliable, when no dynamic strings occur, because with $ 'Classname::' . $method it's getting hard, if not even impossible. One default case (it's mentioned in the quickstart of the extension) are the wildcards $ 'Classname::do*() I guess this would take much effort. Just refactoring is not that easy anymore. Don't get me wrong: I like AOP as idea and as concept, but I'm afraid, that it could lead to scary construction, where noone can trace, what happens when and why. Also as I mentioned I don't even have any better idea ;) Regards, Sebastian 2012/8/23 Sebastian Krebs krebs@gmail.com Hi, From my users point of view: I would like to see it. Maybe not in this implementation/syntax, especially because it hasn't a special syntax (but imo it should to make the impact more obvious/prominent). With the joint points as string and the common function call I can imagine it can get hard to find out, where a specific advise where attached, or which were attached at all, or just how many. For example I rename a method/class and I will not recognize, that a security advise gets lost, I may realize it as soon as I find my data on pastebin ;) But I have no idea how it could look like Regards, Sebastian Am 23.08.2012 16:36, schrieb Peter Nguyen: Hi, AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programminghttp://en.wikipedia.org/wiki/Aspect-oriented_programming) when used correctly, can make your application really modular. I've seen several implementations but they all require compiling of code beforehand. There is however a PECL extension now (https://github.com/AOP-PHP/**AOPhttps://github.com/AOP-PHP/AOP) that enable AOP in PHP directly. I was wondering if there are any interests/possibility to include AOP into the PHP core? Best regards, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Aspect Oriented Programming in PHP
Well, you just have to know and check for the aspects I guess, if you're using wildcards in the joint points. It's no difference than knowing what PHP functions/classes/variables not to overwrite/overload. Besides, you can always debug_backtrace to find out which joint points was executed... Another option is not to use wildcards and define the joint point explicitly. 2012/8/24 Sebastian Krebs krebs@gmail.com 2012/8/24 Peter Nguyen pe...@likipe.se Your argument is a general issue when refactoring code. Whenever you change the name of a method/class, you need to change it in all the places that use it, even in the AOP definitions if you have it of course. The advice is just a PHP callable so it works in the same way. I talked about refactoring the joint points, not the advises, but thats not the point. If I refacter an identifier my IDE (I use PhpStorm, but the others should be that powerful too) supports me by searching for every occurence of the identifier, or even without the need to refactor stuff I can call find usage. With a string like $ 'Classname::method()' or $ 'Classname-method()' I need at least text search, that should work reliable, when no dynamic strings occur, because with $ 'Classname::' . $method it's getting hard, if not even impossible. One default case (it's mentioned in the quickstart of the extension) are the wildcards $ 'Classname::do*() I guess this would take much effort. Just refactoring is not that easy anymore. Don't get me wrong: I like AOP as idea and as concept, but I'm afraid, that it could lead to scary construction, where noone can trace, what happens when and why. Also as I mentioned I don't even have any better idea ;) Regards, Sebastian 2012/8/23 Sebastian Krebs krebs@gmail.com Hi, From my users point of view: I would like to see it. Maybe not in this implementation/syntax, especially because it hasn't a special syntax (but imo it should to make the impact more obvious/prominent). With the joint points as string and the common function call I can imagine it can get hard to find out, where a specific advise where attached, or which were attached at all, or just how many. For example I rename a method/class and I will not recognize, that a security advise gets lost, I may realize it as soon as I find my data on pastebin ;) But I have no idea how it could look like Regards, Sebastian Am 23.08.2012 16:36, schrieb Peter Nguyen: Hi, AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programming http://en.wikipedia.org/wiki/Aspect-oriented_programming) when used correctly, can make your application really modular. I've seen several implementations but they all require compiling of code beforehand. There is however a PECL extension now (https://github.com/AOP-PHP/**AOP https://github.com/AOP-PHP/AOP) that enable AOP in PHP directly. I was wondering if there are any interests/possibility to include AOP into the PHP core? Best regards, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Error handling brainstorming
** The overall mood seems to be that since PHP has an error handler, everyone is free to handle errors any way they want. 2) When everyone starts handling errors in their own way with error handlers, you can't reliably use third party code. You are in your own universe. I think that's the main point that makes any change to the way PHP currently handles errors difficult: The current behavior is to continue the execution flow (except for fatal errors of course) whereas an exception always breaks it. Throwing an exception, either in a custom or in a new internal handler, introduces a major portability + backward compatibility issue. But do you think it could be possible to introduce a per script declaration of the way it has been coded regarding error handling ? We could imagine for example that any script that is coded assuming exceptions instead of errors could be force to declare with a : ?php declare(throw_errors=1); ? or maybe : ?php declare(throw_errors=E_WARNING | E_NOTICE /* | ...*/); 1) PHP Errors come with a severity code and a string message. You want to handle specific errors in a specific way? You better start writing giant regexes parsing the string messages. This is a problem that could also be addressed with the current error handling mechanism: that would require that any error comes with some unique number for example. Is this possible? Independently of the exception vs classical error discussion, that would be amazing. Regards, Nicolas
Re: [PHP-DEV] BC Break in PHP 5.3.16 Reflection API
hi! On Thu, Aug 23, 2012 at 4:24 PM, Laruence larue...@php.net wrote: Hi: this bug has been fixed, just because it has two commits, thus our RMs didn't pick them all to 5.3.16.. so, I think it is no need to re-open it. thanks On Thu, Aug 23, 2012 at 8:47 PM, Benjamin Eberlei kont...@beberlei.de wrote: I get reports from Doctrine users, that apparently the Reflection API is broken in 5.3.16 and everything else than BC: https://bugs.php.net/bug.php?id=62715 Has been closed, but wrongly. Can this be opened up and handled? Or is a follow up bug appropriate here? Re-assigned to the 5.4 RM. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC Break in PHP 5.3.16 Reflection API
hi! On Thu, Aug 23, 2012 at 4:24 PM, Laruence larue...@php.net wrote: Hi: this bug has been fixed, just because it has two commits, thus our RMs didn't pick them all to 5.3.16.. so, I think it is no need to re-open it. I re assigned it to the 5.3 RM. Thanks for the head up! Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Morgan L. Owens wrote: I accept your point about not caring about how the data was created, but on the other side, if the data creation is handling a lot more data than the consumer needs there is an amount of processing time that is wasted. The quick way of doing something does not equate to the best way of doing it. Only if the producer does work unnecessary for determining the next datum required by the consumer. It doesn't have to create all the data at once (if it did you might as well stuff it all in a big array and use that). I think my only point here was that a 'generic' producer many benefit from additional work to make it more efficient, but it's only the consumer end that knows what it needs? This is the problem with a lot of the database 'abstraction' ... there are a lot of additional processes carried out to make the abstraction stuff work which could be optimised a lot easier if they weren't wrapped up away so well. The iterator/generator approach to work flow is going down the same path which is fine for some applications but not so flexible for others? BOTH approaches to workflow have a place, it's working out at what point one is better then the other? Currently we do not have any real basis to compare things :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Generators
Morgan L. Owens wrote: I suppose if you're lucky the consumer doesn't need to remember any state between one notification and the next, and it can treat every dataum like it's the first. But that is hardly the general case. Actually 75% of my 'producers' are simply reading the next line from a file. Which is why the example given in the RFC got my goat so much - I don't recall ever trying to read the whole file into an array ;) . Wrapping that in an iterator gives me nothing and neither does 'yield' I think. My 'producer' simply needs to open the file and read it ... either as a raw line of text or a CSV conversion. Which the 'consumer' part of the relevant object simply processes. The rest of my produces are data feeds from the database ... which already have a 'next' etc ... wrapping them in an iterator seems pointless as well? And essentially they already 'yield' ? ( Thanks for the links ... The php samples in sourcemaking.com look interesting ) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aspect Oriented Programming in PHP
AOP is the future and a very awesome complement to OOP. It is a shame that very few are doing it and I think this would attract some good attention to PHP after traits (both are horizontal reuse mechanisms). On Fri, Aug 24, 2012 at 2:01 AM, Peter Nguyen pe...@likipe.se wrote: Well, you just have to know and check for the aspects I guess, if you're using wildcards in the joint points. It's no difference than knowing what PHP functions/classes/variables not to overwrite/overload. Besides, you can always debug_backtrace to find out which joint points was executed... Another option is not to use wildcards and define the joint point explicitly. 2012/8/24 Sebastian Krebs krebs@gmail.com 2012/8/24 Peter Nguyen pe...@likipe.se Your argument is a general issue when refactoring code. Whenever you change the name of a method/class, you need to change it in all the places that use it, even in the AOP definitions if you have it of course. The advice is just a PHP callable so it works in the same way. I talked about refactoring the joint points, not the advises, but thats not the point. If I refacter an identifier my IDE (I use PhpStorm, but the others should be that powerful too) supports me by searching for every occurence of the identifier, or even without the need to refactor stuff I can call find usage. With a string like $ 'Classname::method()' or $ 'Classname-method()' I need at least text search, that should work reliable, when no dynamic strings occur, because with $ 'Classname::' . $method it's getting hard, if not even impossible. One default case (it's mentioned in the quickstart of the extension) are the wildcards $ 'Classname::do*() I guess this would take much effort. Just refactoring is not that easy anymore. Don't get me wrong: I like AOP as idea and as concept, but I'm afraid, that it could lead to scary construction, where noone can trace, what happens when and why. Also as I mentioned I don't even have any better idea ;) Regards, Sebastian 2012/8/23 Sebastian Krebs krebs@gmail.com Hi, From my users point of view: I would like to see it. Maybe not in this implementation/syntax, especially because it hasn't a special syntax (but imo it should to make the impact more obvious/prominent). With the joint points as string and the common function call I can imagine it can get hard to find out, where a specific advise where attached, or which were attached at all, or just how many. For example I rename a method/class and I will not recognize, that a security advise gets lost, I may realize it as soon as I find my data on pastebin ;) But I have no idea how it could look like Regards, Sebastian Am 23.08.2012 16:36, schrieb Peter Nguyen: Hi, AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programming http://en.wikipedia.org/wiki/Aspect-oriented_programming) when used correctly, can make your application really modular. I've seen several implementations but they all require compiling of code beforehand. There is however a PECL extension now (https://github.com/AOP-PHP/**AOP https://github.com/AOP-PHP/AOP) that enable AOP in PHP directly. I was wondering if there are any interests/possibility to include AOP into the PHP core? Best regards, Peter -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- github.com/KingCrunch
Re: [PHP-DEV] Aspect Oriented Programming in PHP
dukeofgaming wrote: AOP is the future and a very awesome complement to OOP. It is a shame that very few are doing it and I think this would attract some good attention to PHP after traits (both are horizontal reuse mechanisms). That is a bold statement! Do you have time to convert one of the CMS frameworks to use it? THAT would be a good example of how good it is ;) Seriously, there are a lot of styles of programming and many of us are stuck in our ways and are more than happy for all these extra bolt on features are kept where they are best placed in the likes of PECL. It's difficult enough keeping existing code up to date without looking to change the entire code base style we are using :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
2012/8/24 Nicolas Grekas nicolas.grekas+...@gmail.com:
**
The overall mood seems to be that since PHP has an error handler, everyone
is free to handle errors any way they want.
2) When everyone starts handling errors in their own way with error
handlers, you can't reliably use third party code. You are in your own
universe.
I think that's the main point that makes any change to the way PHP
currently handles errors difficult:
The current behavior is to continue the execution flow (except for fatal
errors of course) whereas an exception always breaks it. Throwing an
exception, either in a custom or in a new internal handler, introduces a
major portability + backward compatibility issue.
I think we should talk first over the general handling and then go
into the details (how to handle the different types of errors/warnings
etc.)
Maybe I repeat some things. What do we want?
A) Handling errors with exceptions instead error-handler
B) handling warnings/notices in some way.
That are 2 completely different things...
For A: Errors (something which stops execution) could be just handled
as an exception. I see no problem with this: If not handled, they
behave like now.
For B - the warnings etc. - I suggest something like this:
// This is pseudocode:
abstract class WarningAbstract implements Exception
{
public function __construct()
{
error_log($this-message()..);
unset($this); // I just want to say, that the exception is
destroyed in any way and so not handled any more
}
...
}
// A warning looks like this - this is created by PHP for example when
turning on E_WARNING in php.ini
class Warning extends WarningAbstract
{
}
// and when created it does this:
if (class_exists('Warning')) {
$warning = new Warning();
if (isset($warning)) {
throw $warning;
}
}
Logically, when the exception is created the constructor is called. In
this example (by default) PHP could handle a warning etc. (write
something into a error-log) and then destructs itself, to stop the
handling. (Of course this doesn't work now, when unseting myself the
object is not unseted; I wrote this code only so that PHP-programmers
could understands what I mean.)
[Not so important: could be configured like now. If E_WARNING is
turned on in the php.ini, PHP creates the default handler for this
class itself. If not, the class doesn't exists and so nothing happens.
Or I create my own Warning class, and implement my own way to handle
the warnings.]
This has the big advantage, that we don't need to care about the
mentioned different handling of the different type of errors (see
above: A, B). I think it is important, that the way how it is done is
for every kind of error the same.
Now the details:
A file-error is defined
abstract class FileHandlerWarningAbstract extends if exists Warning //
of course if exists is no PHP - just to explain that it should work
as a hint for the compiler to create the hierarchy
{
}
The code to create the exception needs to recursively look up: If no
FileHandlerWarning exists it must know the hirarchy of it's abstract
(in this case the Warning) and look if that class exists. And so on.
So you can handle file-errors different from all other warnings
without try/catch everything. Not perfect for now, and I think a
little bit too complicated, but this is a brainstorming.
--
Alex Aulbach
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aspect Oriented Programming in PHP
In addition, I think that the hook syntax has to be changed into the call_user_func one (instead of... $obj-foo() do array($obj, 'foo') ) I think the current syntax is fine. Keep in mind, you can use wildcards in that syntax, I do in my application, for example: // before all controller actions aop_add_before( 'MySite\Controller\UserController-*Action()', array($this, 'adviseUserController') ); Also, the object has not been created yet (there is no $obj), but I know I want to catch particular objects by a particular type. I do not know what currently happens if I keyed on an instanceof instead of an exact type. I don't think you can successfully translate a wildcard match to a callable array and have the same meaning conveyed as clearly. What I don't want is a more complex syntax than that is already supported. -ralph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Aspect Oriented Programming in PHP
Just a pedantic note here. You don't need any special functionality to do
AOP style programming in PHP. In fact, this use-case is the exact
definition of a Decorator.
Instead of hooking in with a function call and cut-points, you would just
decorate the object you want to interact with, and you're set. Then just
add your functionality where it's needed.
class Foo {
public function sayIt() {
echo world;
}
}
class Bar {
protected $foo;
public function __construct(Foo $foo) {
$this-foo = $foo;
}
public function sayIt() {
echo Hello ;
$this-foo-sayIt();
}
}
(new Bar(new Foo))-sayIt(); //Hello World
Now, I know that this AOP extension allows you to decorate all instances of
a class without even having an instance to decorate (since it's done by
class name, instead of object instance). So it's not exactly the same, but
from a design perspective both achieve the same thing.
In fact, the decorator can be more flexible due to the fact that you can
control if (and when) you call the wrapped object's method.
Note that I'm not saying that I'm against adding AOP hooks. I'm just saying
that it's not really an OOP construct. In fact, it's *not* an OOP
construct. That's fine, that doesn't diminish its usefulness. Just that
it's not strictly necessary as you can already do the same thing with
traditional OOP constructs...
Anthony
On Fri, Aug 24, 2012 at 11:34 AM, dukeofgaming dukeofgam...@gmail.comwrote:
AOP is the future and a very awesome complement to OOP. It is a shame that
very few are doing it and I think this would attract some good attention to
PHP after traits (both are horizontal reuse mechanisms).
On Fri, Aug 24, 2012 at 2:01 AM, Peter Nguyen pe...@likipe.se wrote:
Well, you just have to know and check for the aspects I guess, if you're
using wildcards in the joint points. It's no difference than knowing what
PHP functions/classes/variables not to overwrite/overload. Besides, you
can
always debug_backtrace to find out which joint points was executed...
Another option is not to use wildcards and define the joint point
explicitly.
2012/8/24 Sebastian Krebs krebs@gmail.com
2012/8/24 Peter Nguyen pe...@likipe.se
Your argument is a general issue when refactoring code. Whenever you
change the name of a method/class, you need to change it in all the
places
that use it, even in the AOP definitions if you have it of course.
The
advice is just a PHP callable so it works in the same way.
I talked about refactoring the joint points, not the advises, but thats
not
the point. If I refacter an identifier my IDE (I use PhpStorm, but the
others should be that powerful too) supports me by searching for every
occurence of the identifier, or even without the need to refactor
stuff I
can call find usage. With a string like
$ 'Classname::method()'
or
$ 'Classname-method()'
I need at least text search, that should work reliable, when no dynamic
strings occur, because with
$ 'Classname::' . $method
it's getting hard, if not even impossible. One default case (it's
mentioned
in the quickstart of the extension) are the wildcards
$ 'Classname::do*()
I guess this would take much effort. Just refactoring is not that
easy
anymore.
Don't get me wrong: I like AOP as idea and as concept, but I'm afraid,
that
it could lead to scary construction, where noone can trace, what
happens
when and why. Also as I mentioned I don't even have any better idea ;)
Regards,
Sebastian
2012/8/23 Sebastian Krebs krebs@gmail.com
Hi,
From my users point of view: I would like to see it. Maybe not in
this
implementation/syntax, especially because it hasn't a special syntax
(but
imo it should to make the impact more obvious/prominent). With the
joint
points as string and the common function call I can imagine it can
get
hard
to find out, where a specific advise where attached, or which were
attached
at all, or just how many. For example I rename a method/class and I
will
not recognize, that a security advise gets lost, I may realize it as
soon
as I find my data on pastebin ;) But I have no idea how it could
look
like
Regards,
Sebastian
Am 23.08.2012 16:36, schrieb Peter Nguyen:
Hi,
AOP (http://en.wikipedia.org/wiki/**Aspect-oriented_programming
http://en.wikipedia.org/wiki/Aspect-oriented_programming)
when used
correctly, can make your application really modular. I've seen
several
implementations but they all require compiling of code beforehand.
There
is
however a PECL extension now (https://github.com/AOP-PHP/**AOP
https://github.com/AOP-PHP/AOP)
that enable
AOP in PHP directly. I was wondering if there are any
interests/possibility
to include AOP into the PHP
Re: [PHP-DEV] Aspect Oriented Programming in PHP
This is exactly the problem that AOP solves. I think the decorator
pattern is just a solution for the shortcoming of the language itself. What
if you want multiple advices at that joint point, do you create decorator
on decorator, call another class inside the decorator, or use the observer
pattern? Do you need to decorate all your classes before hand just to be
futureproof? What do you do if you stumple upon code you need to hook into
with no decorator?
AOP solves this in a nice way without the need to pollute your code. Just
think of the possiblities, not having to deal with do_action/add_action
again or to think about all the possible events that you need to support
in your code for it to be modular. With AOP, you can just write your class
and feel safe that there will be a way to hook into your methods without
modifying it if you ever need to.
2012/8/24 Anthony Ferrara ircmax...@gmail.com
Just a pedantic note here. You don't need any special functionality to do
AOP style programming in PHP. In fact, this use-case is the exact
definition of a Decorator.
Instead of hooking in with a function call and cut-points, you would just
decorate the object you want to interact with, and you're set. Then just
add your functionality where it's needed.
class Foo {
public function sayIt() {
echo world;
}
}
class Bar {
protected $foo;
public function __construct(Foo $foo) {
$this-foo = $foo;
}
public function sayIt() {
echo Hello ;
$this-foo-sayIt();
}
}
(new Bar(new Foo))-sayIt(); //Hello World
Now, I know that this AOP extension allows you to decorate all instances
of a class without even having an instance to decorate (since it's done by
class name, instead of object instance). So it's not exactly the same, but
from a design perspective both achieve the same thing.
In fact, the decorator can be more flexible due to the fact that you can
control if (and when) you call the wrapped object's method.
Note that I'm not saying that I'm against adding AOP hooks. I'm just
saying that it's not really an OOP construct. In fact, it's *not* an OOP
construct. That's fine, that doesn't diminish its usefulness. Just that
it's not strictly necessary as you can already do the same thing with
traditional OOP constructs...
Anthony
On Fri, Aug 24, 2012 at 11:34 AM, dukeofgaming dukeofgam...@gmail.comwrote:
AOP is the future and a very awesome complement to OOP. It is a shame that
very few are doing it and I think this would attract some good attention
to
PHP after traits (both are horizontal reuse mechanisms).
On Fri, Aug 24, 2012 at 2:01 AM, Peter Nguyen pe...@likipe.se wrote:
Well, you just have to know and check for the aspects I guess, if you're
using wildcards in the joint points. It's no difference than knowing
what
PHP functions/classes/variables not to overwrite/overload. Besides, you
can
always debug_backtrace to find out which joint points was executed...
Another option is not to use wildcards and define the joint point
explicitly.
2012/8/24 Sebastian Krebs krebs@gmail.com
2012/8/24 Peter Nguyen pe...@likipe.se
Your argument is a general issue when refactoring code. Whenever you
change the name of a method/class, you need to change it in all the
places
that use it, even in the AOP definitions if you have it of course.
The
advice is just a PHP callable so it works in the same way.
I talked about refactoring the joint points, not the advises, but
thats
not
the point. If I refacter an identifier my IDE (I use PhpStorm, but the
others should be that powerful too) supports me by searching for every
occurence of the identifier, or even without the need to refactor
stuff I
can call find usage. With a string like
$ 'Classname::method()'
or
$ 'Classname-method()'
I need at least text search, that should work reliable, when no
dynamic
strings occur, because with
$ 'Classname::' . $method
it's getting hard, if not even impossible. One default case (it's
mentioned
in the quickstart of the extension) are the wildcards
$ 'Classname::do*()
I guess this would take much effort. Just refactoring is not that
easy
anymore.
Don't get me wrong: I like AOP as idea and as concept, but I'm afraid,
that
it could lead to scary construction, where noone can trace, what
happens
when and why. Also as I mentioned I don't even have any better idea ;)
Regards,
Sebastian
2012/8/23 Sebastian Krebs krebs@gmail.com
Hi,
From my users point of view: I would like to see it. Maybe not in
this
implementation/syntax, especially because it hasn't a special
syntax
(but
imo it should to make the impact more obvious/prominent). With the
joint
points as string and the common function call I can imagine it can
get
hard
to find out, where a
Re: [PHP-DEV] Aspect Oriented Programming in PHP
Peter,
On Fri, Aug 24, 2012 at 2:36 PM, Peter Nguyen pe...@likipe.se wrote:
This is exactly the problem that AOP solves. I think the decorator
pattern is just a solution for the shortcoming of the language itself.
Actually, I think it's the other way around. Think about this for a second.
With the AOP functionality proposed, it applies to *all* instances of a
class. That's fine, except when you only want to add the functionality to
one instance.
What if you want multiple advices at that joint point, do you create
decorator on decorator, call another class inside the decorator, or use the
observer pattern? Do you need to decorate all your classes before hand just
to be futureproof? What do you do if you stumple upon code you need to hook
into with no decorator?
No, you just decorate each piece of functionality onto the class. That's
the point of a decorator. You don't need to worry about it, you just wrap
whatever was there. So you can put decorator on top of decorator. You
compose the functionality in layers.
And decorate all your classes before hand just to be futureproof? tells
me you haven't worked with decorators much, as that's a bit of a silly
comment. You decorate to change behavior in a specific way. Let's take
a canonical example:
interface Coffee {
public function getPrice();
}
class BlackCoffee implements Coffee{
public function getPrice() { return 1; }
}
class Cream implements Coffee {
protected $coffee;
public function __construct(Coffee $coffee) {
$this-coffee = $coffee;
}
public function getPrice() { return 0.25 + $this-coffee-getPrice(); }
}
class Sugar implements Coffee {
protected $coffee;
public function __construct(Coffee $coffee) {
$this-coffee = $coffee;
}
public function getPrice() { return 0.50 + $this-coffee-getPrice(); }
}
$creamAndSugar = new Sugar(new Cream(new BlackCoffee));
$creamOnly = new Cream(new BlackCoffee);
$sugarOnly = new Sugar(new BlackCoffee);
I didn't de-deuplicate (by creating an abstract decorator) to illustrate
the concept of what's going on.
So no, you don't create a decorator for every class. You create one for
each class you need to add functionality to, when you need to add
functionality to it.
If you want to hook into code without a decorator, you write a decorator.
It's that simple.
AOP solves this in a nice way without the need to pollute your code.
Just think of the possiblities, not having to deal with
do_action/add_action again or to think about all the possible events that
you need to support in your code for it to be modular. With AOP, you can
just write your class and feel safe that there will be a way to hook into
your methods without modifying it if you ever need to.
Actually, I'd argue this the AOP addition is polluting code more, because
it's always global. And global is the antithesis to flexibility (which is
the entire point of AOP after all). If it worked on a per-object level, I
could see that argument. But seeing as it's global at the class level, I
don't think that argument flies.
Now, as I said in my prior post, I am actually in favor of this change. I
think it can make patching existing architectures and legacy code much
easier. But I wouldn't write new code with it. And I wouldn't say that it's
a good compliment to OOP. It can help in certain situations, but it also
can cause a lot of pain (due to the global nature, and the fact that it is
really just spooky-action-at-a-distance).
http://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)
Anthony
Re: [PHP-DEV] Aspect Oriented Programming in PHP
Anthony,
2012/8/24 Anthony Ferrara ircmax...@gmail.com
Peter,
On Fri, Aug 24, 2012 at 2:36 PM, Peter Nguyen pe...@likipe.se wrote:
This is exactly the problem that AOP solves. I think the decorator
pattern is just a solution for the shortcoming of the language itself.
Actually, I think it's the other way around. Think about this for a
second. With the AOP functionality proposed, it applies to *all* instances
of a class. That's fine, except when you only want to add the functionality
to one instance.
You should of course use the right tool for the job, there's nothing
stopping you from using any OOP pattern together with AOP.
What if you want multiple advices at that joint point, do you create
decorator on decorator, call another class inside the decorator, or use the
observer pattern? Do you need to decorate all your classes before hand just
to be futureproof? What do you do if you stumple upon code you need to hook
into with no decorator?
No, you just decorate each piece of functionality onto the class. That's
the point of a decorator. You don't need to worry about it, you just wrap
whatever was there. So you can put decorator on top of decorator. You
compose the functionality in layers.
And decorate all your classes before hand just to be futureproof? tells
me you haven't worked with decorators much, as that's a bit of a silly
comment. You decorate to change behavior in a specific way. Let's take
a canonical example:
I was of course exaggerating trying to make my point. Taking a look at your
example, it is not really a use case for AOP. For example, you don't apply
the Cream class to the User class or the Company class, because it doesn't
make sense. But what do you do, when you want to apply a Logging class to
all the database actions? Do you really want to decorate all the classes
that uses the database? It's even worst when it's somebody else's project.
Another thing is that you need to change the calling code to use your new
decorator class, what if that code is scattered in your project? You don't
need to worry about that if AOP is available.
interface Coffee {
public function getPrice();
}
class BlackCoffee implements Coffee{
public function getPrice() { return 1; }
}
class Cream implements Coffee {
protected $coffee;
public function __construct(Coffee $coffee) {
$this-coffee = $coffee;
}
public function getPrice() { return 0.25 + $this-coffee-getPrice(); }
}
class Sugar implements Coffee {
protected $coffee;
public function __construct(Coffee $coffee) {
$this-coffee = $coffee;
}
public function getPrice() { return 0.50 + $this-coffee-getPrice(); }
}
$creamAndSugar = new Sugar(new Cream(new BlackCoffee));
$creamOnly = new Cream(new BlackCoffee);
$sugarOnly = new Sugar(new BlackCoffee);
I didn't de-deuplicate (by creating an abstract decorator) to illustrate
the concept of what's going on.
So no, you don't create a decorator for every class. You create one for
each class you need to add functionality to, when you need to add
functionality to it.
If you want to hook into code without a decorator, you write a decorator.
It's that simple.
AOP solves this in a nice way without the need to pollute your code.
Just think of the possiblities, not having to deal with
do_action/add_action again or to think about all the possible events that
you need to support in your code for it to be modular. With AOP, you can
just write your class and feel safe that there will be a way to hook into
your methods without modifying it if you ever need to.
Actually, I'd argue this the AOP addition is polluting code more, because
it's always global. And global is the antithesis to flexibility (which is
the entire point of AOP after all). If it worked on a per-object level, I
could see that argument. But seeing as it's global at the class level, I
don't think that argument flies.
Saying that because it's global, it's a bad thing doesn't seem to be a
valid point in my opinion. There are many global concepts in programming,
like Logging/Authorization/Database connections etc. In fact it is one of
the strong argument for AOP, because it will not be of much use if you only
can point cut the execution of one class don't you think? But I'm in favor
of being able to organize aspects into namespace though, it will be a nice
addition to the proposal.
Now, as I said in my prior post, I am actually in favor of this change. I
think it can make patching existing architectures and legacy code much
easier. But I wouldn't write new code with it. And I wouldn't say that it's
a good compliment to OOP. It can help in certain situations, but it also
can cause a lot of pain (due to the global nature, and the fact that it is
really just spooky-action-at-a-distance).
http://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming)
Anthony
Re: [PHP-DEV] Aspect Oriented Programming in PHP
On Fri, 24 Aug 2012 19:18:40 +0200, Anthony Ferrara ircmax...@gmail.com wrote: Just a pedantic note here. You don't need any special functionality to do AOP style programming in PHP. In fact, this use-case is the exact definition of a Decorator. Instead of hooking in with a function call and cut-points, you would just decorate the object you want to interact with, and you're set. Then just add your functionality where it's needed. I think you're missing the fundamental difference between decorators and AOP or interceptors. Decorators augment the object with domain-specific additions, while interceptors are more appropriate for orthogonal concerns. CDI (JSR 299/346) has both. Their interceptors are slightly different from traditional AOP in that you don't have the usual pointcut syntax, and decoration is done is done automatically upon injection. You might want to take a look nevertheless; this is the weld (CDI reference implementation) documentation: * http://docs.jboss.org/weld/reference/latest/en-US/html/interceptors.html * http://docs.jboss.org/weld/reference/latest/en-US/html/decorators.html -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Combined assignment operator for short ternary
Hi, Just want to push my thread ^^ Nobody interested? Too stupid? I need to learn C (:X)? Too complicated? To much impact (on something)? Too less sense? BC? Anything not mentioned here? To point that out: I _don't_ want to change the behaviour, which means | $foo['xy'] ?:= 'bar'; would trigger a notice like | $foo['xy'] = $foo['xy'] ?: 'bar'; would do. Regards, Sebastian Am 17.08.2012 23:41, schrieb Sebastian Krebs: Hi, Don't know, how complicated this is (and also someone (not me) must implement it, because I can't :X), but to be in sync with the operators the short ternary operator should be usable in conjunction with the assignment like the other binary operators. Don't know, if anybody understands me :D So here is an example // instead of $foo = $foo ?: 'default'; // Just $foo ?:= 'default'; I have many of this default assigments and yes: This is just syntactic sugar. Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Combined assignment operator for short ternary
On Fri, Aug 17, 2012 at 11:41 PM, Sebastian Krebs krebs@gmail.comwrote: Hi, Don't know, how complicated this is (and also someone (not me) must implement it, because I can't :X), but to be in sync with the operators the short ternary operator should be usable in conjunction with the assignment like the other binary operators. Don't know, if anybody understands me :D So here is an example // instead of $foo = $foo ?: 'default'; // Just $foo ?:= 'default'; would this trigger a notice if $foo is not defined? if yes, then it would be different from the current behavior of the ternary operator. if no, then I would never use this. I mean if I have to set the variable before the check, then I would put the check into the assignment. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Implicit isset in ternary operator
On Fri, Aug 3, 2012 at 12:26 AM, Alex Aulbach alex.aulb...@gmail.comwrote: 2012/8/2 Andrew Faulds a...@ajf.me: Hi, Also in JavaScript if in strict mode. Legacy non-strict mode JS doesn't cause an error though. JS's || operator supresses this error though, which is great for e.g. x = x || new Object(); Could be cool to make this in PHP with the 'or' operator (or not ||)... Which brings us back to the subject... -- Alex Aulbach -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php most/some of the ideas here were brought up before, there is a proposal and a nice history of mailing list discussions (albeit not up-to-date) at https://wiki.php.net/rfc/ifsetor personally I would really like an ifsetor/coelesce kind of language construct. accepts any number of arguments, won't trigger notice on unset variables, and returns the first non-null argument. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Default input encoding for htmlspecialchars/htmlentities
El 23/08/12 18:06, Rasmus Lerdorf escribió:
htmlspecialchars(), htmlentities(), html_entity_decode() and
get_html_translation_table() all take an encoding parameter that used to
default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This
is a much more sensible default and in the case of the encoding
functions more secure as it prevents invalid UTF-8 from getting through.
If you use 8859-1 as the default but your app is actually in UTF-8 or
worse, some encoding that isn't low-ascii compatible then
htmlspecialchars()/htmlentities() aren't doing what you think they are
and you have a glaring security hole in your app.
I don't see how passing utf-8 as latin1 gets into a security hole. The
characters
you want to replace (') in utf-8 are the same as in latin1, and it
can't
get trickied with synchronizations. If it was passing latin1 to a function
expecting utf-8 or some encoding that isn't low-ascii compatible then
I see the hole, but not here.
So do we create a new default_input_encoding ini directive mid-stream in
5.4 for this? Of course with the longer-term in mind that this will be
part of a unified set of encoding settings in 5.5 and beyond.
Yes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Default input encoding for htmlspecialchars/htmlentities
On 08/24/2012 02:23 PM, Ángel González wrote:
El 23/08/12 18:06, Rasmus Lerdorf escribió:
htmlspecialchars(), htmlentities(), html_entity_decode() and
get_html_translation_table() all take an encoding parameter that used to
default to iso-8859-1. We changed the default in PHP 5.4 to UTF-8. This
is a much more sensible default and in the case of the encoding
functions more secure as it prevents invalid UTF-8 from getting through.
If you use 8859-1 as the default but your app is actually in UTF-8 or
worse, some encoding that isn't low-ascii compatible then
htmlspecialchars()/htmlentities() aren't doing what you think they are
and you have a glaring security hole in your app.
I don't see how passing utf-8 as latin1 gets into a security hole. The
characters
you want to replace (') in utf-8 are the same as in latin1, and it
can't
get trickied with synchronizations. If it was passing latin1 to a function
expecting utf-8 or some encoding that isn't low-ascii compatible then
I see the hole, but not here.
In 8859-1 no chars are invalid so anything that doesn't get encoded will
get passed through as-is. For example the byte 0xE0 is a perfectly valid
8859-1 character (à), but if the page is actually UTF-8 then this
becomes the first byte of a 3-byte UTF-8 character. IE is famous for
having a really weak Unicode parser and at least IE6/7 would see the
0xE0 and combine it with the next 2 bytes to form the UTF-8 char.
So, if you had code like this:
$str = htmlspecialchars($str); // Assuming iso-8859-1
echo 'a href='.$str.'';
You now have a problem because if the last byte of $str was character
0xE0 now IE will swallow the closing and characters in your output
leaving you in a very weird state. IE still thinks you are inside an
attribute in the a tag, but you think you are outside in regular HTML
mode and whatever you output next will now be filtered with the wrong
context and you have a potential XSS.
When htmlspecialchars() is in UTF-8 mode it will not allow invalid UTF-8
byte sequences through and you are safe from this particular problem.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Combined assignment operator for short ternary
Hi! To point that out: I _don't_ want to change the behaviour, which means | $foo['xy'] ?:= 'bar'; would trigger a notice like | $foo['xy'] = $foo['xy'] ?: 'bar'; Then I personally don't see much point in it. Saving a couple of keystrokes IMHO is not really worth it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Combined assignment operator for short ternary
Am 24.08.2012 23:11, schrieb Ferenc Kovacs:
On Fri, Aug 17, 2012 at 11:41 PM, Sebastian Krebs krebs@gmail.com
mailto:krebs@gmail.com wrote:
Hi,
Don't know, how complicated this is (and also someone (not me) must
implement it, because I can't :X), but to be in sync with the
operators the short ternary operator should be usable in conjunction
with the assignment like the other binary operators. Don't know, if
anybody understands me :D So here is an example
// instead of
$foo = $foo ?: 'default';
// Just
$foo ?:= 'default';
would this trigger a notice if $foo is not defined?
if yes, then it would be different from the current behavior of the
ternary operator.
Couldn't believe it, thus I tested it myself
$ php -a
Interactive mode enabled
?php
$f = $f ?: 'bar';
PHP Notice: Undefined variable: f in - on line 2
PHP Stack trace:
PHP 1. {main}() -:0
Notice: Undefined variable: f in - on line 2
Call Stack:
8.9779 619512 1. {main}() -:0
Don't know, what you are talking about, but the notice _is_ the current
behaiour and therefore: No difference.
if no, then I would never use this.
I mean if I have to set the variable before the check, then I would put
the check into the assignment.
The main thought about it was
function foo ($bar = null) {
$bar = $bar ?: 'default';
}
I _always_ use 'null' as default
- If you want to omit a parameter, but want to set one after that, you
don't need to look whats the default: It's 'null'
- Ive often enough seen something like
function foo ($limit = 10) { /* code */ }
// Somewhere else
function bar ($limit = 50) { /* code */ $foo($limit); /* code */}
// Even somewhere else
bar();
Imagine there are some other methods and functions in between it's quite
annoying.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Combined assignment operator for short ternary
Am 25.08.2012 01:00, schrieb Stas Malyshev: Hi! To point that out: I _don't_ want to change the behaviour, which means | $foo['xy'] ?:= 'bar'; would trigger a notice like | $foo['xy'] = $foo['xy'] ?: 'bar'; Then I personally don't see much point in it. Saving a couple of keystrokes IMHO is not really worth it. Hi, It's like with any other compound operator: A _real_ reason isn't there. But saying It's not worth it is something I can live with (even if I don't know how much effort it would take ;)). I just asked myself: '?:' is (a kind of?) binary operator and every other binary operator is available as compound operator, so why not '?:', so I don't have to repeat the variable? Regards, Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Combined assignment operator for short ternary
On Sat, Aug 25, 2012 at 1:49 AM, Sebastian Krebs krebs@gmail.com wrote: Hi, It's like with any other compound operator: A _real_ reason isn't there. But saying It's not worth it is something I can live with (even if I don't know how much effort it would take ;)). I just asked myself: '?:' is (a kind of?) binary operator and every other binary operator is available as compound operator, so why not '?:', so I don't have to repeat the variable? No, every other binary operator is not available. If I interpret this right one could say that all short-circuiting operators are not available. E.g. you also can't write $foo = $bar; or $foo ||= $bar. The ?: operator also falls in this category of short-circuiting logical operators. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session Id Collisions
Hi, I was willing to add collision detection to session module after session adoption patch is merged. What's the status of session adoption patch? I've created patches for all 3 versions and I think Stats is going to merge it to master and PHP 5.4. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/8/24 Sherif Ramadan theanomaly...@gmail.com: Hi Rasmus, Many thanks for the information. It would be great if this information can be added to the docs: http://www.php.net/manual/en/session.configuration.php#ini.session.entropy-file Please open a documentation bug at https://bugs.php.net/ for this so that we have a record of the issue and I'll be sure to follow up on the ticket. I can confirm the default configuration directives from 5.4: http://lxr.php.net/xref/PHP_5_4/ext/session/session.c#725 and 5.3: http://lxr.php.net/xref/PHP_5_3/ext/session/session.c#807 So I will update the docs accordingly to reflect the change. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
