Yes, I'm agree with Will Fitch.
Handling this problem with PHP is a good idea and beneficial to programmer.
2012/2/23 Ángel González
> On 22/02/12 15:57, Michael Morris wrote:
> > Before writing up a full RFC I want to put out a feeler on something.
> > Currently we have several input paramet
Hi !
First, thanks for all your replies.
I'll try to answer all questions, it'll be long.
#1. Should PHP have an enum implementation (not especially mine) ?
I think yes. We do not require it, there's nothing we can't do without.
However I think we need an intuitive and expressive syntax for thi
Hi!
Sidenote, according your examples above on how you want call
functions: Considered using normal constants?
How can I do type hinting with them?
You should not. PHP is not a strictly typed language, so if you want
strictly typed function you'll get in trouble, for the same reasons why
st
Hi!
For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum, and
why certain things are better with enums.
http://j
On 22/02/12 23:13, Kris Craig wrote:
> While I'm a huge fan of Github, why did you decide to host your RFC there
> instead of on the PHP wiki? (...)
Samuel doesn't have a wiki accout.
I agree he should get one and continue the proposal there.
--
PHP Internals - PHP Runtime Development Mailing Li
Am 22.02.2012 22:30, schrieb Sebastian Krebs:
> Am 22.02.2012 22:22, schrieb Ángel González:
>> I want to call it doSomething(FOO) or doSomething(MyEnum::FOO),
>> not doSomething(new MyEnum(MyEnum::FOO));
>
>
> // The class file
> class MyEnum {
> public static $FOO;
> public static $BAR;
While I'm a huge fan of Github, why did you decide to host your RFC there
instead of on the PHP wiki? I realize there's an older proposal there
right now, but that's from 2010 and seems to be dead in the water. Even if
yours is just a draft, the wiki is designed to be able to accommodate
progress
For those who keep saying "but this can already be done in php", here is a
pretty good article.
Long time ago enums were not available in Java also, so this article
explains that yes, thigs can technically could be done before the enum, and
why certain things are better with enums.
http://javarev
On 22/02/12 15:57, Michael Morris wrote:
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and legacy code someti
Am 22.02.2012 22:22, schrieb Ángel González:
On 22/02/12 09:37, Sebastian Krebs wrote:
class MyEnum {
const FOO = 'foo';
const BAR = 'bar';
private $value;
public function __construct ($value) {
if (!in_array($value, array(self::FOO, self::BAR)) throw new
UnexpectedV
> From: Ferenc Kovacs [mailto:tyr...@gmail.com]
> Sent: Wednesday, February 22, 2012 3:55 PM
> To: John Crenshaw
> Cc: Peter Lind; Larry Garfield; internals@lists.php.net
> Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal
> (desired feature?)
>
> don't forget that we
On 22/02/12 09:37, Sebastian Krebs wrote:
> class MyEnum {
> const FOO = 'foo';
> const BAR = 'bar';
> private $value;
> public function __construct ($value) {
> if (!in_array($value, array(self::FOO, self::BAR)) throw new
> UnexpectedValueException;
> $this->value =
>
>
> I've been following this discussion pretty closely and it seems to me that
> all the arguments in favor of adding this are actually good arguments for
> converting ALL fatal errors to exceptions. I see no compelling reason to
> change just this one type of error to an exception, and in fact,
Hi,
Am 22.02.2012 20:04, schrieb Larry Garfield:
On 2/22/12 12:37 PM, Peter Lind wrote:
I would also support this. There's a myriad reasons why something may
return NULL or FALSE when you expect it to return an object, some of them
even legitimate. Any function/method whose documentation line
> -Original Message-
> From: Peter Lind [mailto:peter.e.l...@gmail.com]
> Sent: Wednesday, February 22, 2012 1:37 PM
> To: Larry Garfield
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal
> (desired feature?)
>
> On Feb 22, 2012 7
On 22 February 2012 20:04, Larry Garfield wrote:
> On 2/22/12 12:37 PM, Peter Lind wrote:
>
>>> I would also support this. There's a myriad reasons why something may
>>
>> return NULL or FALSE when you expect it to return an object, some of them
>> even legitimate. Any function/method whose docu
On 2/22/12 12:37 PM, Peter Lind wrote:
I would also support this. There's a myriad reasons why something may
return NULL or FALSE when you expect it to return an object, some of them
even legitimate. Any function/method whose documentation line is "returns
the foo object, or NULL if someone s
On Feb 22, 2012 7:05 PM, "Larry Garfield" wrote:
>
> On 2/21/12 5:45 PM, Tjerk Meesters wrote:
>>
>> On 22 Feb, 2012, at 2:03 AM, Ralf Lang wrote:
>>
> I see no reason why it would be not desirable to have PHP raise the
> exception rather than putting more or less repeating code snippets
On 2/21/12 5:45 PM, Tjerk Meesters wrote:
On 22 Feb, 2012, at 2:03 AM, Ralf Lang wrote:
I see no reason why it would be not desirable to have PHP raise the
exception rather than putting more or less repeating code snippets all
around the place. That is why I am asking.
You must be returning
On Wed, 2012-02-22 at 09:57 -0500, Michael Morris wrote:
> Before writing up a full RFC I want to put out a feeler on something.
> Currently we have several input parameter objects, chief among them
> $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
> of them are arrays and le
On Wednesday, February 22, 2012 at 10:10 AM, Michael Morris wrote:
> $_REQUEST does nothing of the sort, and it's use is dangerous in
> RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
> and $_COOKIE, in that order but the php.ini directive can change it.
> Hence there's no way
What Dmitri said is more than relevant!
We see these coming back often, and would rather see a list of these
«wants» and a discussion what on that list should/shouldn't be
implemented and why.
We can all see the advantage of having such features when we come
across that "want" moment, where havin
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET,
Personally, I don't like this. We already have $_REQUEST which can accommodate
GET, POST, and COOKIE. I believe it should be up to framework/API authors to
implement there own methodologies behind accessing this data. Additional
functionality such as setting filters would be a part of that as
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only ob
I think that your proposal looks good, but I'd like to suggest a few
changes. First of all, I'd like to see the association with integers
removed. An enum instance shouldn't just be a name for an integer, it
should be more like a singleton instance of a special kind of class
that can only ever have
This is just one of the many features that available in Java and "would be nice
to have" in php.
Maybe we should put togher a list of features that exist in Java and people
want to see in php (obviousle exclude all concurrency related topics)
Dmitri Snytkine
Web Developer
Ultra Logistics, Inc.
On Wed, 22 Feb 2012 10:18:17 +0100, Stas Malyshev
wrote:
Hi!
I'm sure most (all?) of these changes are in 5.4:
diff -uw branches/PHP_5_4/UPGRADING trunk/UPGRADING | grep ^+
The second grep is very misleading. Check the actual UPGRADING file -
all that stuff is there. Or at least most o
On 02/22/2012 07:29 AM, Rasmus Lerdorf wrote:
complicated optimization passes or any of those things
Would such things be welcome/needed in the engine or as an extension?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
I'm sure most (all?) of these changes are in 5.4:
diff -uw branches/PHP_5_4/UPGRADING trunk/UPGRADING | grep ^+
The second grep is very misleading. Check the actual UPGRADING file -
all that stuff is there. Or at least most of it that I could check quickly.
--
Stanislav Malyshev, Softw
On Wed, 22 Feb 2012 10:05:16 +0100, Stas Malyshev
wrote:
Hi!
I'll add this information to UPGRADING once the mess it's in is sorted
out
(there are parts that refer to 5.4 changes that are not merged in 5.4's
UPGRADING).
Which parts are those?
I'm sure most (all?) of these changes are
Hi!
I'll add this information to UPGRADING once the mess it's in is sorted out
(there are parts that refer to 5.4 changes that are not merged in 5.4's
UPGRADING).
Which parts are those?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP
Hi
In the spirit of "commit first, ask questions later once urged by other
parties", I'm informing internals I've dropped the streams pooling API
from trunk. This was never used in PHP in 8 years, neither in any of the
PECL extensions in SVN. A Google search came up with nothing elsewhere
What about SplEnum? (http://php.net/splenum)
It's part of the SPL types extension, but it could probably be also
moved to core.
Nikita
On Wed, Feb 22, 2012 at 5:45 AM, Samuel Deal wrote:
> Hi all,
>
> I really missed enums in PHP,
> So after reading I tryed to synthetise the various views.
>
>
My point is that *although* it's certainly possible to do almost everything I
want already, I should not have to write all that boilerplate for each enum.
I would much prefer to write something like 'enum { A, B, C }' rather than
write a full class for the enum, duplicate each enum value multipl
2012/2/22 Charlie Somerville
> Right, but enums could possibly be a lot richer than class constants are
> now.
>
> They could be a type where the only values are what's defined in the enum.
> This could be used with type hinting:
>
>enum Foo {
>A,
>B,
>C
>}
>
>
36 matches
Mail list logo
