Hello,
Before you crucify me, let me explain what I am trying to do.
There is a methodology named Defense Programming, an approach that
implements what is usually known as Poka-Yoke (from Japanese, wiki:
http://en.wikipedia.org/wiki/Poka-yoke).
First of all, it's not Pokemón, ok?
This methodology try to close all opened doors and just remain one
door opened, the right (and correct) one.
I am implementing this approach in PHP, overwriting superglobals
variables and delivering to end-programmer the encapsulated PokeYoke
object.
The package implements ArrayAccess at the first glance, but maybe I'll
extend to ArrayIterator in a next stage. I want to break the
possibility of the user to directly access the value, storing it in an
object which contains the right rules to retrieve data, in the correct
type and even including filter support.
So, every $_SUPER['offset'] is an instance of PokaYokeDataHolder, and
$_SUPER is an instance of PokaYoke class.
Currently, you display data using ie. $_GET['offset'], which in my
case will call __toString method of class PokaYokeDataHolder. I do not
want to allow this, since this can contain unsafe data and it would
break the entire intention described by Shigeo Shingo. The right
accessor must be something like: $_GET['offset']->getInteger(), which
assures the value is an integer and not an array, for example.
So, I disallow it by throwing a PokaYokeException inside __toString.
All the exceptions are controlled by a globalExceptionHandler, which
mails me useful information to debug the error.
The idea is perfect, but the current OO implementation of PHP do not
allow to throw exceptions inside the __toString. That is a language
limitation, that should not exist in my humble opinion. =)
Imagine converting a complex Object structure into a simple
__toString, maybe involving a Database connection. An exception can be
fired because the RDBMS is overloaded and cannot complete this
connection. So... is it wrong? The application should deal with this
its way, and the only limitation in my concept is that the method must
return a string value.
If something went wrong and the application must be noticed about it,
let the application control it, not the language interpreter.
If you are interested to lose some time and take a look at my
Poka-Yoke implementation, I uploaded a ZIP package:
http://blog.bisna.com/files/PokaYoke.zip
I am interested to listen a feedback from you.
Best regards,
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil
Hi,
casts to string happen in quite different places in the engine. For
different reasons we can't assure that an exception throw in these
situations would be handled correctly by the engine. This won't change
until great parts of the engine are rewritten.
Please check the archives - there were prior discussions about these
problems.
johannes
Hello,
Before you crucify me, let me explain what I am trying to do.
There is a methodology named Defense Programming, an approach that
implements what is usually known as Poka-Yoke (from Japanese, wiki:
http://en.wikipedia.org/wiki/Poka-yoke).First of all, it's not Pokemón, ok?
This methodology try to close all opened doors and just remain one
door opened, the right (and correct) one.
I am implementing this approach in PHP, overwriting superglobals
variables and delivering to end-programmer the encapsulated PokeYoke
object.The package implements ArrayAccess at the first glance, but maybe I'll
extend to ArrayIterator in a next stage. I want to break the
possibility of the user to directly access the value, storing it in an
object which contains the right rules to retrieve data, in the correct
type and even including filter support.
So, every $_SUPER['offset'] is an instance of PokaYokeDataHolder, and
$_SUPER is an instance of PokaYoke class.Currently, you display data using ie. $_GET['offset'], which in my
case will call __toString method of class PokaYokeDataHolder. I do not
want to allow this, since this can contain unsafe data and it would
break the entire intention described by Shigeo Shingo. The right
accessor must be something like: $_GET['offset']->getInteger(), which
assures the value is an integer and not an array, for example.So, I disallow it by throwing a PokaYokeException inside __toString.
All the exceptions are controlled by a globalExceptionHandler, which
mails me useful information to debug the error.The idea is perfect, but the current OO implementation of PHP do not
allow to throw exceptions inside the __toString. That is a language
limitation, that should not exist in my humble opinion. =)Imagine converting a complex Object structure into a simple
__toString, maybe involving a Database connection. An exception can be
fired because the RDBMS is overloaded and cannot complete this
connection. So... is it wrong? The application should deal with this
its way, and the only limitation in my concept is that the method must
return a string value.
If something went wrong and the application must be noticed about it,
let the application control it, not the language interpreter.If you are interested to lose some time and take a look at my
Poka-Yoke implementation, I uploaded a ZIP package:
http://blog.bisna.com/files/PokaYoke.zipI am interested to listen a feedback from you.
Best regards,
Ok,
Thanks for the explanation Johannes.
I worked around it by throwing a fatal error.
__toString does not accept exceptions, but they accept trigger_errors!
Thanks for the explanation... I will take a look at history.
Best regards,
Hi,
casts to string happen in quite different places in the engine. For
different reasons we can't assure that an exception throw in these
situations would be handled correctly by the engine. This won't change
until great parts of the engine are rewritten.Please check the archives - there were prior discussions about these
problems.johannes
Hello,
Before you crucify me, let me explain what I am trying to do.
There is a methodology named Defense Programming, an approach that
implements what is usually known as Poka-Yoke (from Japanese, wiki:
http://en.wikipedia.org/wiki/Poka-yoke).First of all, it's not Pokemón, ok?
This methodology try to close all opened doors and just remain one
door opened, the right (and correct) one.
I am implementing this approach in PHP, overwriting superglobals
variables and delivering to end-programmer the encapsulated PokeYoke
object.The package implements ArrayAccess at the first glance, but maybe I'll
extend to ArrayIterator in a next stage. I want to break the
possibility of the user to directly access the value, storing it in an
object which contains the right rules to retrieve data, in the correct
type and even including filter support.
So, every $_SUPER['offset'] is an instance of PokaYokeDataHolder, and
$_SUPER is an instance of PokaYoke class.Currently, you display data using ie. $_GET['offset'], which in my
case will call __toString method of class PokaYokeDataHolder. I do not
want to allow this, since this can contain unsafe data and it would
break the entire intention described by Shigeo Shingo. The right
accessor must be something like: $_GET['offset']->getInteger(), which
assures the value is an integer and not an array, for example.So, I disallow it by throwing a PokaYokeException inside __toString.
All the exceptions are controlled by a globalExceptionHandler, which
mails me useful information to debug the error.The idea is perfect, but the current OO implementation of PHP do not
allow to throw exceptions inside the __toString. That is a language
limitation, that should not exist in my humble opinion. =)Imagine converting a complex Object structure into a simple
__toString, maybe involving a Database connection. An exception can be
fired because the RDBMS is overloaded and cannot complete this
connection. So... is it wrong? The application should deal with this
its way, and the only limitation in my concept is that the method must
return a string value.
If something went wrong and the application must be noticed about it,
let the application control it, not the language interpreter.If you are interested to lose some time and take a look at my
Poka-Yoke implementation, I uploaded a ZIP package:
http://blog.bisna.com/files/PokaYoke.zipI am interested to listen a feedback from you.
Best regards,
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Carlos - SP/Brazil