Hello,
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.
I would be able to write the RFC and later on implement this new
exception by myself, in case people share my opinion.
Best regards
Benjamin Schneider
I'd suggest to be IllegalStateException then.
But +1 on adding it. =)
On Thu, Oct 17, 2013 at 9:30 AM, Benjamin Schneider <
benjamin.schneider.de@gmail.com> wrote:
Hello,
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.I would be able to write the RFC and later on implement this new
exception by myself, in case people share my opinion.Best regards
Benjamin Schneider--
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.
Exceptions are one part of the SPL that are a nasty, poorly thought-out
mess (no offense to anyone who worked on it; this stuff is harder than
people realize). I am -1 on simply adding another exception to our mess,
but if we can clean it up then I might support it, depending on details.
Levi,
I'd love to listen your ideas/suggestions. Maybe we can implement an RFC to
make it better.
Without exposure to problems, there are no problems at all.
I'm not saying it's perfect, but would love ideas on how we can improve it.
=)
Cheers,
On Thu, Oct 17, 2013 at 10:33 AM, Levi Morrison morrison.levi@gmail.comwrote:
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.Exceptions are one part of the SPL that are a nasty, poorly thought-out
mess (no offense to anyone who worked on it; this stuff is harder than
people realize). I am -1 on simply adding another exception to our mess,
but if we can clean it up then I might support it, depending on details.
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.Exceptions are one part of the SPL that are a nasty, poorly thought-out
mess (no offense to anyone who worked on it; this stuff is harder than
people realize). I am -1 on simply adding another exception to our mess,
but if we can clean it up then I might support it, depending on details.I'd love to listen your ideas/suggestions. Maybe we can implement an RFC
to make it better.
Without exposure to problems, there are no problems at all.I'm not saying it's perfect, but would love ideas on how we can improve
it. =)
As an example of my idea of progress:
https://github.com/morrisonlevi/Ardent/blob/master/Exceptions.md
- DomainException
- FunctionException
- LookupException (The two sub-classes here may be unnecessary; just one
may do)- IndexException
- KeyException
- StateException
- EmptyException
- FullException
- TypeException
Of course, this is not backwards compatible. It does, however, include a
StateException that is relevant here. I'm not implying that my exceptions
hierarchy is complete, but a good deal of thought and use has gone into
them so far.
On Thu, Oct 17, 2013 at 4:33 PM, Levi Morrison morrison.levi@gmail.comwrote:
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.Exceptions are one part of the SPL that are a nasty, poorly thought-out
mess (no offense to anyone who worked on it; this stuff is harder than
people realize). I am -1 on simply adding another exception to our mess,
but if we can clean it up then I might support it, depending on details.
if somebody wonders what Levi is referring to:
https://wiki.php.net/rfc/spl-improvements
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc,
How much of this is PHP willing to take as BC break?
Like changing from one Exception to another (UnderflowException to
RuntimeException) and removing OutOfRangeException because it is ambiguous
seems very hard fro PHP to take in a PHP 5.6 for example.
I may have some time to try something, but I wouldn't spend time just for
the sake of doing if it's gonna be rejected later.
Cheers,
On Thu, Oct 17, 2013 at 4:33 PM, Levi Morrison <morrison.levi@gmail.com
wrote:
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.Exceptions are one part of the SPL that are a nasty, poorly thought-out
mess (no offense to anyone who worked on it; this stuff is harder than
people realize). I am -1 on simply adding another exception to our mess,
but if we can clean it up then I might support it, depending on details.if somebody wonders what Levi is referring to:
https://wiki.php.net/rfc/spl-improvements--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Thu, Oct 17, 2013 at 4:43 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Ferenc,
How much of this is PHP willing to take as BC break?
Like changing from one Exception to another (UnderflowException to
RuntimeException) and removing OutOfRangeException because it is ambiguous
seems very hard fro PHP to take in a PHP 5.6 for example.I may have some time to try something, but I wouldn't spend time just for
the sake of doing if it's gonna be rejected later.Cheers,
The current release process (https://wiki.php.net/rfc/releaseprocess)
wouldn't allow it in 5.6, but one could argue that:
1, the usage of these exceptions not that wide-spread
2, the upgrade path (in your example) is pretty simple, replace every
occurance of UnderflowException to RuntimeException in your codebase, (I
would also argue to not remove OutOfRangeException, but rename it as we
already have that used in spl and php code out there could also use it
already), we could even provide tools to help the migration.
but, this is really a hard topic, because it is more of a semantic issue,
and that is a bit weak argument for breaking BC, so this would require a
really thought-out RFC and the voters could still say no.
I think the actual implementation/patch would be really simple, so the hard
part of the task is to figure out the proper naming and hierarchy.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
@Ferenc: Ok, so let's try to wrap all these suggestion in the SPL RFC you
pointed out and vote.
@Levi: I'd suggest to minimize BC breaks if you're willing to get this
merged.
Dunno how to proceed here, but that should be the focus.
On Thu, Oct 17, 2013 at 4:43 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:Ferenc,
How much of this is PHP willing to take as BC break?
Like changing from one Exception to another (UnderflowException to
RuntimeException) and removing OutOfRangeException because it is ambiguous
seems very hard fro PHP to take in a PHP 5.6 for example.I may have some time to try something, but I wouldn't spend time just for
the sake of doing if it's gonna be rejected later.Cheers,
The current release process (https://wiki.php.net/rfc/releaseprocess)
wouldn't allow it in 5.6, but one could argue that:
1, the usage of these exceptions not that wide-spread
2, the upgrade path (in your example) is pretty simple, replace every
occurance of UnderflowException to RuntimeException in your codebase, (I
would also argue to not remove OutOfRangeException, but rename it as we
already have that used in spl and php code out there could also use it
already), we could even provide tools to help the migration.but, this is really a hard topic, because it is more of a semantic issue,
and that is a bit weak argument for breaking BC, so this would require a
really thought-out RFC and the voters could still say no.
I think the actual implementation/patch would be really simple, so the
hard part of the task is to figure out the proper naming and hierarchy.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
As a reminder, we do not top-post :)
@Ferenc: Ok, so let's try to wrap all these suggestion in the SPL RFC you
pointed out and vote.
In case you didn't notice, I started that RFC quite some time ago ^^
Everything still applies.
@Levi: I'd suggest to minimize BC breaks if you're willing to get this
merged.
Dunno how to proceed here, but that should be the focus.
I think major BC breaks can still make it in, we'd just have to go a
different route. I was thinking something along the lines of another
extension and eventually deprecate the SPL. I do agree that smaller BC
breaks have a better chance of making it in, as well as making it in
sooner. I suppose I'll compromise to some degree and compile a list of
BC-safe changes and list them in the RFC.
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.Exceptions are one part of the SPL that are a nasty, poorly thought-out
mess (no offense to anyone who worked on it; this stuff is harder than
people realize). I am -1 on simply adding another exception to our mess,
but if we can clean it up then I might support it, depending on details.if somebody wonders what Levi is referring to:
https://wiki.php.net/rfc/spl-improvements
Also, I have a specific one for exceptions:
https://wiki.php.net/rfc/spl-improvements/exceptions
I am already updating it with content appropriate to this thread.
Hello,
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.I would be able to write the RFC and later on implement this new
exception by myself, in case people share my opinion.
I'm a strong believer in "what hasn't to be in core should not be" and
these exceptions can easily be implemented in PHP. They have to be in C
when internal things should throw those.
True, doing this in PHP outside the core won't make those available
everywhere, but I believe that doing this in userland allows to simplify
adoption to changing needs in longterm and tools like Composer make it
possible to distribute even such small libraries in a good way with way
less trouble than a few years back.
johannes
On Thu, Oct 17, 2013 at 11:54 AM, Johannes Schlüter
johannes@schlueters.dewrote:
Hello,
I would like to propose the introduction of an 'InvalidStateException'
into the SPL extension. Within the existing exceptions I am not able
to find a type that would represent a state error, throwable if a
method has been invoked at an illegal or inappropriate time.I would be able to write the RFC and later on implement this new
exception by myself, in case people share my opinion.I'm a strong believer in "what hasn't to be in core should not be" and
these exceptions can easily be implemented in PHP. They have to be in C
when internal things should throw those.
I agree, Johannes. However, there are actually times where the SPL should
internally throw these exceptions. A work-in-progress can be at found
https://github.com/morrisonlevi/php-src/tree/StateExceptions. There are
actually way more use-cases for StateException than I originally believed.
I agree, Johannes. However, there are actually times where the SPL
should internally throw these exceptions. A work-in-progress can be at
found https://github.com/morrisonlevi/php-src/tree/StateExceptions.
There are actually way more use-cases for StateException than I
originally believed.
Then this should be proposed in combination.
johannes