I'd like to address the most obvious issues I see with moving on to PHP 6.
First, there has already been a lot of discussion on PHP 6 since as
early as 2007, if I recall correctly. Albeit, a lot of this has died
down over the years, but there are probably still a lot of books and
people out there
Stas,
> I like this idea. array_first_key would be nice too
>
> I am probably missing something, but what those would allow to do that
> rewind/end+key() doesn't do?
>
The big thing that it does that end()+key() doesn't do is really what it
doesn't do (update the internal pointer).
end() modifie
Yeah, it would allow you to do this in one function call instead of three.
If you are going to have an array_last_key() function, it makes sense to
also have an array_first_key() function. After all, you could just do this:
foreach ( $array as $key => $v ) {}
echo $key;
On Fri, Jul 13, 2012 at 9
Hi!
> I like this idea. array_first_key would be nice too
I am probably missing something, but what those would allow to do that
rewind/end+key() doesn't do?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime De
Hi!
> So, I've not been inside the engine so in practice this may make no
> sense at all, but what about looking at it the other way around? Vis,
> instead of making objects more and more like arrays, make arrays an
> object that happens to implement ArrayAccess, Iterator, and whatever
That'
I like this idea. array_first_key would be nice too
On Fri, Jul 13, 2012 at 7:45 PM, Andrew Faulds wrote:
> Changed, it now takes just an array.
>
> Function signature:
>
> mixed array_last_key(array $array)
>
> On 13 July 2012 23:31, Andrew Faulds wrote:
> > Hi there,
> >
> > I'm proposing
2012/7/13 Ángel González :
> The codebase does no global exception handling (because it doesn't throw
> exceptions itself),
> and also nobody configured the server not to show errors/exceptions
> (some say it was
> purposely setup to show them).
> password_verify() "errors" if the parameters are no
On 7/13/12 12:30 PM, Stas Malyshev wrote:
Hi!
Yep, today we have :
- arrays
- Object implementing ArrayAccess
- Objects implementing Traversable (Iterator)
- array_() functions not working with ArrayAccess' objects
- Iterator API not working with arrays (ArrayIterator needed)
- ... I forget
Changed, it now takes just an array.
Function signature:
mixed array_last_key(array $array)
On 13 July 2012 23:31, Andrew Faulds wrote:
> Hi there,
>
> I'm proposing a function called array_last_key(), that takes a
> reference to an array, and returns the key of its last item. This is
> use
Hi there,
I'm proposing a function called array_last_key(), that takes a
reference to an array, and returns the key of its last item. This is
useful for finding out the key of the last item pushed to an array.
Here's the pull request: https://github.com/php/php-src/pull/131
This is the first PHP
On 13/07/12 12:28, Ryan McCue wrote:
> Somewhat off-topic, but is there a reason why not? It seems to me that
> introducing a new API without using PHP's best method of error handling
> (IMHO) is a little silly.
I don't really trust exception throwing near password-managing functions.
Consider the
Hi!
> Yep, today we have :
> - arrays
> - Object implementing ArrayAccess
> - Objects implementing Traversable (Iterator)
> - array_() functions not working with ArrayAccess' objects
> - Iterator API not working with arrays (ArrayIterator needed)
> - ... I forget things
>
> There sure is some
Hi!
> Has the requirement for a truly clean unicode version of PHP actually gone
> away?
The requirement hasn't, but nobody is willing to lead the task. And it's
not an easy one. IMHO variable names are by far the least important part
of it - I don't know of any code that can't be done using ASC
Hi!
> I wouldn't call it ad hoc, actually, but more a recognition of what practices
> and patterns are now occurring. A few years ago, I'd have type-hinted on array
I do not think strict typing is a right way to do it. Strict typing has
specific meaning in many languages, including (unfortunately
Anthony Ferrara wrote:
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
Has the requirement for a truly clean unicode version of PHP actually gone away?
Yes on the whole the existin
>
>
> 4. Rewrite the entire parser completely. I keep hearing about how bad PHP's
> parser is, and how it's growing out of control. Perhaps this is a good time
> to rewrite it (perhaps changing semantics slightly) to be better adapted
> towards future changes...
>
>
I'm bored so I'm gonna poke the
On Fri, Jul 13, 2012 at 6:11 PM, Andrew Faulds wrote:
> Hi there,
>
> I saw this bug report (feature request): https://bugs.php.net/bug.php?id=48542
>
> The person there proposes that array_shift and array_pop should have
> an optional second parameter, which can be passed a reference to a
> varia
On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara wrote:
> Hey all,
>
> I know that 6.0 was originally supposed to be the unicode conversion of the
> engine. However it appears that all progress on that has stopped for quite
> some time.
>
> So, I was curious if we could start a conversation around
Hi there,
I saw this bug report (feature request): https://bugs.php.net/bug.php?id=48542
The person there proposes that array_shift and array_pop should have
an optional second parameter, which can be passed a reference to a
variable in which the key can be returned, so you can pop the key and
va
Anthony Ferrara wrote:
> 1. Change the error handling system from the current E_* system to typed
> exceptions for everything but advisory errors (E_STRICT, E_NOTICE,
> E_DEPRECATED). Why? Because the current error system encourages ignoring or
> not checking what the error was, and it makes defens
Hey all,
I know that 6.0 was originally supposed to be the unicode conversion of the
engine. However it appears that all progress on that has stopped for quite
some time.
So, I was curious if we could start a conversation around what 6.0 would
look like if we didn't go the unicode route. What wou
On Fri, Jul 13, 2012 at 3:55 PM, Matthew Weier O'Phinney
wrote:
> On 2012-07-13, David Muir wrote:
>> On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
>> > On 2012-07-12, Sara Golemon wrote:
>> > > --e89a8f235453d7a80104c4975c55
>> > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara
>> > > w
On 2012-07-13, "Eugene Leonovich" wrote:
> I'm a bit confused by the "class" keyword in the syntax ClassName::class.
> We already have the magic constant __CLASS__ which does exactly the same
> class name resolving, if you refer it within the class.
>
> So why to introduce a new keyword instead o
On 2012-07-13, David Muir wrote:
> On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
> > On 2012-07-12, Sara Golemon wrote:
> > > --e89a8f235453d7a80104c4975c55
> > > On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara
> > > wrote:
> > > > One thing to keep in mind when doing this is to think abou
On 2012-07-12, Rasmus Lerdorf wrote:
> On 07/12/2012 09:30 AM, Stas Malyshev wrote:
> > > Would it be worth while adding a new type hint that checks for this
> > > condition? I'd propose Iterable:
> >
> > I see more and more multiplication of weird ad-hoc type checks. First we
> > had "callable",
On 2012-07-12, Stas Malyshev wrote:
> > For non-interchangeable types it is already strict by definition. I
> > don't see a problem with type hints that make life easier on both the
> > caller (by generating better error messages) and the callee (by having
> > to write less boilerplate type verifi
I'm a bit confused by the "class" keyword in the syntax ClassName::class.
We already have the magic constant __CLASS__ which does exactly the same
class name resolving, if you refer it within the class.
So why to introduce a new keyword instead of using __CLASS__, like
ClassName::__CLASS__?
Eug
> -Original Message-
> From: Nikita Popov [mailto:nikita@gmail.com]
> Sent: 11 July 2012 23:17
> To: PHP internals
> Subject: [PHP-DEV] Internal iteration API
>
> Hi internals!
>
> Currently PHP does not have an internal iteration API that
> supports both arrays and Traversable o
Anthony Ferrara wrote:
> I want exceptions here too. But PHP doesn't use exceptions in its standard
> library (aside from SPL), and I'm not sure this is a compelling enough case
> to implement the first... I could be swayed, but I'm not sure the rest of
> the team would.
Somewhat off-topic, but is
Op 12-07-12 19:02, Ángel González schreef:
On 12/07/12 17:30, Johannes Schlüter wrote:
Hi,
On Thu, 2012-07-12 at 17:09 +0200, Jille Timmermans wrote:
An implementation is quite simple:
https://github.com/Jille/php-src/commit/31a1aa384c29487e077ccf3fd067eca188cf1201
Without looking at the func
30 matches
Mail list logo
