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() modifies
Gustavo,
Why is the last key special? Why not a function to get the first or the
penultimate key?
How would such a function look?
Of course, there is one aspect where the first and last keys are special
-- if you have some algorithm where you pop or shift the array
successively. But in
Check out the conversation around it.
Specifically: http://marc.info/?t=13308247243r=1w=2
But also: http://marc.info/?t=13302683324r=1w=2
So basically it just stopped. But that doesn't mean that it can't
be resurrected or continued...
Anthony
On Sun, Jul 15, 2012 at 11:48 AM,
Alex,
On Sun, Jul 15, 2012 at 7:19 PM, Alex Aulbach alex.aulb...@gmail.comwrote:
Ok. I think, I go too much off topic. Sorry.
But I want to repeat
- we never know in which context the program will run. And good
security means, thait it shouldn't care, in which context it runs.
Could you
Daniel,
On Sun, Jul 15, 2012 at 8:20 PM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Anthony:
But I agree with your larger point. The only problem with it is that it
would take an engine wide shift to do.
How does using exceptions in this new extension require an engine
Ferenc,
On Mon, Jul 16, 2012 at 8:25 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
The recent
http://www.mail-archive.com/internals@lists.php.net/msg59301.html
discussion
made me wonder why did we decide not supporting the final keywords for
properties as it would provide an easy way for
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson ww.ga...@gmail.com
wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw
I like the concept in principle. But implementing it is non trivial.
First, you need a base-conversion function that will allow you to convert
between arbitrary bases (base_convert() won't work, because it only works
on fixed bases, and on numbers INT_MAX)... Here's a utility class that
does
Raymond
On Mon, Jul 16, 2012 at 9:30 PM, Raymond Irving xwis...@gmail.com wrote:
Hi Anthony,
Thanks for the feedback. I do get your point about escaping for JavaScript
but the example shown was just to highlight the entity substitution issue
which could lead to unexpected results. In this
I dislike this idea from the ground up.
While I think having a legacy implementation is definitely worth while, it
needs to be in core. So PHP6 would introduce the new syntax, and include
the legacy functionality in as close to 100% backwards compatible way as
possible. From there, we'd only
Rafael,
One point of clarity:
On Wed, Jul 18, 2012 at 10:15 AM, Rafael Dohms lis...@rafaeldohms.com.brwrote:
Hey Everyone,
With the syntax improvements for 5.4 and some of the de-referencing work,
code looks so much sleeker then before, but there is still one use case
that really bugs me.
Laruence,
On Wed, Jul 18, 2012 at 9:53 PM, Laruence larue...@php.net wrote:
Hi:
I saw you two vote against for this RFC.
could you explain why? then maybe I can improve it.
thanks
The reason that I voted against it is simple. It's sugar to make it harder
to understand what the
Hey all,
So I've been thinking about this for a while. Here's what I've come up with:
1. We want to maintain loose typing, so implementing a different API on
string than on int types would be bad.
2. We want to retain backwards compatibility to some extent with the legacy
API.
3. We want the
Andrew,
On Mon, Jul 23, 2012 at 9:26 AM, Andrew Faulds a...@ajf.me wrote:
(resending because of broken formatting)
Hi there,
I apologise for my previous email. It was a disorganised mess that didn't
really
make the case for that function very well. So here's a proper proposal
(perhaps
Johannes,
On Tue, Jul 24, 2012 at 9:48 AM, Johannes Schlüter
johan...@schlueters.dewrote:
On Tue, 2012-07-24 at 19:20 +0800, Laruence wrote:
Hi:
As the previous threads disscussed, I make a implemention.
here is the RFC: https://wiki.php.net/rfc/finally
any suggestions?
Gustavo,
On Mon, Jul 30, 2012 at 1:31 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
https://wiki.php.net/rfc/**incompat_ctxhttps://wiki.php.net/rfc/incompat_ctx
An RFC for deprecating and removing $this from incompatible context.
Comments are welcome.
A few points.
1. Finally! It's
Jonathan,
On Tue, Jul 31, 2012 at 8:32 AM, Jonathan Bond-Caron jbo...@openmv.comwrote:
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron jbo...@openmv.comwrote:
RFC:
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
Again, I have
Jonathan,
On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron jbo...@openmv.comwrote:
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron HYPERLINK
I strongly disagree with this, the 'pepper' IMHO is a best practice
for web
Peter,
On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:
*snip*
Also, be aware that BCrypt only uses the first 72 characters of the
password field. So if you use a hex encoded sha512 output
Lester,
On Thu, Aug 2, 2012 at 8:49 AM, Lester Caine les...@lsces.co.uk wrote:
rich gray wrote:
OK
No discussions on why register_globals has been removed we all
understand why
and now have to live with that ... I'm not winging here!
The question is Does anybody have an 'elegant' fix to
Yahav,
On Thu, Aug 2, 2012 at 7:26 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
I do think that some of the runkit features should not be included in PHP
core but I wish to focus on extending classes with extension methods,
constants, traits and members.
Just like all other complicated
Levi et al:
On Mon, Aug 6, 2012 at 8:55 PM, Levi Morrison morrison.l...@gmail.comwrote:
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again,
Stas,
On Tue, Aug 7, 2012 at 1:46 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
circumstance. If it's not, you should be checking for existence first
(via file_exists() or is_readable(), etc)...
This is exactly how we got into this mess with $x =
isset($a['x'])?$a['x']:null;
We're
Hey all
I've posted before about adding the ability to do dynamic decorators
before. I think I have come up with a method to do so in core.
Basically, the problem is that I can't create a decorator for a class at
all. I would have to extend that class (with all of the coupling issues
that
Brian,
On Sun, Aug 12, 2012 at 4:08 PM, Brian Moon br...@moonspot.net wrote:
Hi Nikita,
I admit, I have ignored these threads as there was no RFC. So, some of
this may have been covered.
There was an RFC in those posts... It was just being iterated over.
Do you have a good example usage
help to simplify benchmarking code also.
On Mon, Aug 13, 2012 at 4:16 PM, Nils Adermann nader...@naderman.de
wrote:
On 08/12/2012 08:17 PM, Anthony Ferrara wrote:
Thoughts?
Yes, please. I think this would be a great simplification for all kinds
of extensibility / plugin mechanisms
Levi,
On Tue, Aug 14, 2012 at 9:51 AM, Levi Morrison morrison.l...@gmail.comwrote:
On Tue, Aug 14, 2012 at 1:46 AM, Stan Vass sv_for...@fmethod.com wrote:
I've felt the need for this for some time.
Proposed syntax:
-
$x = (InterfaceName) $container-service;
Ralph,
On Tue, Aug 14, 2012 at 12:49 PM, Ralph Schindler
ra...@ralphschindler.comwrote:
In general, I think it would be nice to have something that does this for
you, but I am not necessarily a fan of changing the meaning of instanceof.
That's a lot of boilerplate for each possible
Ralph,
On Tue, Aug 14, 2012 at 3:30 PM, Ralph Schindler
ra...@ralphschindler.comwrote:
Well, I like it at first glance. There are two main problems that I see
with it:
1. It still requires a separate decorator class for every combination of
interfaces you want to decorate. So, for example
Ralph,
to write. This is one of the reasons that traits are so heralded.
Because problems that are easy to solve with decorators (in general) are
difficult to solve with PHP, so people wind up writing copy/paste
If what you're trying to do is decorate an instance of a particular
concrete
Stan,
On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote:
Hi!
I agree with you. The one case where this syntax may be very useful is if
we want to implement class casting. So introduce a pair of magic methods
I do not think we want to implement class casting. I'm not
On Sun, Aug 19, 2012 at 10:29 AM, Raymond Irving xwis...@gmail.com wrote:
Hello,
What could have cause PHP to start out so great but then slows to a crawl?
Could it be the GC?
Number of iterations Node.js PHP
---
100
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
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.
Hello all,
Since the discussion has died down around the concept, I have updated the
RFC and moved it into Proposed (under discussion) status.
I have updated the RFC to include a section on discussion points
containing points that I know were raised but I felt were not closed (there
was
Ferenc,
Not for PHP 5.5 (if that's happening?), but for PHP 6 I think a lot of
things should become exceptions.
From the impression that I get from reading through the mailing list
threads and the irc discussions I think that there aren't that many things
that could turn into exceptions.
Hi all,
There's been a lot of discussion around whether or not to include
exceptions for core (no class implementations) errors or not. There's been
a lot said on both sides. However, I'd like to pose the question from a
different angle.
Right now, I see the biggest problem with errors currently
Andrew:
I don't wish to derail this thread from the get-go, but what's your
opposition to moving to exceptions?
I'm absolutely for moving to exceptions. I asked this question as a
thought exercise to see 1. If the current error system can be improved, or
2. To identify if it can't, and
Derick,
On Sun, Sep 2, 2012 at 1:12 PM, Derick Rethans der...@php.net wrote:
On Sun, 2 Sep 2012, Anthony Ferrara wrote:
I don't wish to derail this thread from the get-go, but what's your
opposition to moving to exceptions?
I'm absolutely for moving to exceptions. I asked
Hello all,
I'm opening the vote for the simplified password hashing API indicated here:
https://wiki.php.net/rfc/password_hash
Please vote,
Thanks,
Anthony
Stas,
On Thu, Sep 6, 2012 at 5:25 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Well, apart from perhaps leaving them with a simpler language that
doesn't have the inconsistencies and corner cases that currently exist
(and documented ad nauseum) not because of any design decision
Hannes,
On Sun, Sep 9, 2012 at 12:23 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
On Tue, Sep 4, 2012 at 3:16 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I'm opening the vote for the simplified password hashing API indicated
here:
https://wiki.php.net/rfc
Pierre,
On Mon, Sep 10, 2012 at 1:54 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Sep 10, 2012 at 6:28 PM, jpauli jpa...@php.net wrote:
Based on our recent discussion on #pecl , I'd like we clarify what we
think is a BCB (Backward Compatibility Break) as well as what only
Pierre,
it does not break code, also that happens only and only from 5.x to
5.x+1 and should not happen from 5.x.y to 5.x.y+1 for example (or on
very rare cases).
I agree it should not happen from 5.x.y to 5.x.y+1. But it definitely does
break code... Not all, but at least some...
I
Pierre,
On Tue, Sep 11, 2012 at 2:14 AM, Pierre Joye pierre@gmail.com wrote:
hi Stas,
On Tue, Sep 11, 2012 at 12:23 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
OTOH, PECL module that can be built in 5.3/5.4 too might be nice. Not
everybody is going to upgrade to 5.5 soon, so
Hannes,
First off, this has been discussed on the list for literally months. Why
wait until the day before voting can end before bringing this up?
So commenting is strictly forbidden during votes?
Not in the least. Just pointing out that this discussion could have been
better if it was
Scott,
On Wed, Sep 12, 2012 at 12:57 PM, Scott MacVicar sc...@macvicar.net wrote:
Concerns about the RFC after talking with someone (Alok) on our security
team at work.
There is no requirement for them to be cryptographically secure.
What stops the salt from being cryptographically secure?
Nicolas:
On Thu, Sep 13, 2012 at 7:33 AM, Nicolas Grekas
nicolas.grekas+...@gmail.com wrote:
Hi,
What do you think about adding PHPass compatibility to the password hashing
API ?
We could add two new algos : PASSWORD_MD5 and PASSWORD_EXT_DES.
That way, existing password crypted using
Stas,
On Thu, Sep 13, 2012 at 4:58 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I would expect $variable::class to work (like late static bindings).
What this would mean? ClassName::class has a clear meaning - ClassName
is a name of the class (possibly aliased) and class is the
Paul
On Tue, Sep 18, 2012 at 7:32 AM, Paul Dragoonis dragoo...@gmail.com wrote:
Hi Paddy,
Couldn't this just be a new option for the filter_var() function?
$clean = filter_var($_POST['someVar'], XSS_CLEAN);
- Paul.
Not without losing significant semantic meaning. There's a huge
Stas,
On Tue, Sep 18, 2012 at 12:51 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I've written an RFC for PHP over at: https://wiki.php.net/rfc/escaper.
The RFC is a proposal to implement a standardised means of escaping
data which is being output into XML/HTML.
We already have
Stas,
On Tue, Sep 18, 2012 at 1:09 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
No it's not. A filter removes, but escaping lets the original content
pass through unchanged, with the necessary in-band signalling to make
sure that its content is not treated as in-band signalling.
Julien,
Implementing this to Core may be very nice, but as well very hard to do.
String escaping is a pain to implement in C. One would tell : once
it's done, it's OK, but unfortunately, that's not the case, as XSS
rules evolve throught time as the attacks evolve.
See the escape modules web
Bryan et al,
On Tue, Sep 18, 2012 at 1:58 PM, Bryan C. Geraghty br...@ravensight.orgwrote:
Hello everyone,
Paddy is correct here. The purpose of this API is output ENCODING which is
a
very good thing. This discussion provides a very good case for a point I
made via Twitter this morning: In
Stas,
On Tue, Sep 18, 2012 at 2:21 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Filter has already gone down this road--I doubt the value added by
having a second, much
more verbose way to call htmlspecialchars()--but I don't see why we must
continue down
that path.
So, you
Bryan,
On Tue, Sep 18, 2012 at 2:52 PM, Bryan C. Geraghty br...@ravensight.orgwrote:
Antony,
** **
I’ll concede that the term “escaping” is improperly used in many places;
even in the OWASP documentation.
** **
But I’ll point out that the CWE document is identifying a
Lester,
Basically if you are STORING XSS intrusions then you have badly designed
code as there is no reason that it would be stored. If you want to
'display' suspect code, then it is 'escaped' before it is stored so
preventing a potential problem if another viewer accesses the raw data!
I
Bryan,
“You hit the nail on the head here. You cannot black-list convert
ISO-8859-1 to UTF-8. However, when we talk about escaping, we're talking
about a context where the encoding is already correct, we're just
preventing special characters from imparting special meaning. In that case,
Yes, it's fairly trivial to write a function for this. I wrote a pair of
them in about 2 minutes:
http://codepad.viper-7.com/rqVlqL
On Sun, Sep 30, 2012 at 7:56 AM, Charlie Somerville
char...@charliesomerville.com wrote:
I'm struggling to imagine how such a function would be useful
On Oct 12, 2012 10:59 AM, Christian Kaps christian.k...@mohiva.com
wrote:
At the moment it isn't possible to restrict/define the arguments for a
closure which is defined as parameter for a method. Please look at this
small example.
interface Broker {
public function scan(Request
Lester,
But a vote NOT to include it should still be one of the options!
No it should not.
Comments like this are not helpful, and are quite destructive. Please stop
running that circle.
As far as the particular implementation goes, I'd vote against it right
now. Not because it's bad, but
Stas,
On Sun, Oct 21, 2012 at 12:51 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
Hello, list. I want to propose generics.
Please no. If you need Java, you know where to find it. Java has a set
of great tools, great books, great community. And it's completely free.
Anybody who needs
All,
On Thu, Oct 25, 2012 at 3:14 AM, Guillaume Rossolini
g.rossol...@gmail.comwrote:
On Thu, Oct 25, 2012 at 8:36 AM, Kris Craig kris.cr...@gmail.com wrote:
What if, instead of changing the behavior, we have it throw a notice or
warning if a boolean value is passed here? Because this is
If there are no objections, I'll go ahead and draft an RFC for the
notice/docs idea later today. If anyone would like to co-author it with
me, please drop me an email and I'll send you the wiki link once I've
created the page.
Do we even need an RFC for this? I would personally just open a
Do we even need an RFC for this? I would personally just open a bug and
commit the change.
But if people want an RFC, that's fine... It just seems like a huge
undertaking for such a minor change...
I see no need for an RFC just to add a helpful notice here. Just do it.
Thanks
FYI: the bug is: 63363
https://bugs.php.net/bug.php?id=63363
On Thu, Oct 25, 2012 at 12:06 PM, Anthony Ferrara ircmax...@gmail.comwrote:
Do we even need an RFC for this? I would personally just open a bug and
commit the change.
But if people want an RFC, that's fine... It just seems
Rasmus et al,
I see no need for an RFC just to add a helpful notice here. Just do it.
-Rasmus
Should this target master only (5.5)? Or 5.3/5.4 as well?
My tendancy would be to target 5.5 only, but I can see the argument made
that it should target 5.3/5.4 as well... Thoughts?
Anthony
On Thu, Oct 25, 2012 at 2:48 PM, JJ ja...@php.net wrote:
Stas suggested this should throw a notice instead of a warning, I've
amended. Thx all.
https://github.com/php/php-src/pull/221
The PR has been merged in and closed. It has been merged into 5.4 and
master.
Thanks for the contribution!
Florin,
On Thu, Nov 8, 2012 at 6:42 AM, Florin Razvan Patan
florinpa...@gmail.comwrote:
Hello,
After a talk on the Symfony framework here:
https://github.com/symfony/symfony/issues/5911
Long story short, the point that @Seldaek suggestion to have a common
interface for loggers
actually
Sebastian,
There are already discussing this (to be honest: For months now).
Some are mentioned at the pull requests at
https://github.com/php-fig/fig-standards/pulls
So then there's really no reason to be discussing it for core, is there?
My standpoint would be not to add E_DEPRECATED notices in 5.5... It's
simply used too much to start loudly complaining about it. Instead, what I
would suggest is the following:
1. Officially deprecate it now. Right now, on the docs it says
discouraged, but I would suggest changing that to
There's one important thing that I think you all are missing here. You keep
bringing up that we should just use the normal deprecation process. The
problem is that the deprecation process was never designed for a feature
like this.
Look at what was deprecated and removed so far. We deprecated
Will,
Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which depending on the implementation of the
error handler can be quite costly performance-wise.
So what solution is
Sherif,
I'm just trying to understand your reasoning behind this view.
How is telling people it's deprecated, but only in the manual going
to be any different than putting warnings to discourage future use,
but only in the manual?
I'm not saying to put it only in the manual. I'm saying we
Adam,
My intention at this stage is to call a vote next Monday: it feels
like the discussion has mostly died down now (which isn't to say I
think we're at a consensus necessarily — it just feels as though the
flurry of opinions have been made and argued either way), and I'm
hoping that
Pierre,
Hard/soft deprecated?
I suppose by soft you mean not actually deprecated but only
documented as such?
Correct. Hard = raising E_DEPRECATED from code. Soft = Documentation and PR
only...
Kris,
By NEXT are you referring to 6.0 or 5.6?
Whatever the release after 5.5 is. Be it 5.6, or 6.0, NEXT indicates the
next temporal release...
Also, can you add an option for raising E_DEPRECATED in 5.5 then removing
support altogether in 6?
That's already in there. That's what I mean
Adam,
Thanks for opening voting.
However, I'd like to ask you to do something else here. Can you please
update the RFC to reflect the discussions that happened on list? Not
everything that was talked about, but the major discussion points at least.
That way it's there for future reference, and
Patrick,
Sorry, but removing the E_DEPRECATED notice when moved to PECL is not
part of the proposed RFC and should certainly not happen.
The proposal doesn't actually propose anything about a move to PECL. It's
listed in the possible future actions section exactly once. But the RFC
doesn't
Kris,
I disagree. Whether we're deprecating an extension or a subset of
functions, the practical impact is pretty much the same. As for moving it
to PECL, why are we even discussing that here? It's completely outside the
scope of this RFC. I imagine moving it to PECL would make the most
Angel
On Thu, Nov 29, 2012 at 12:02 PM, Ángel González keis...@gmail.com wrote:
David Muir wrote:
On 29/11/12 05:09, Ángel González wrote:
I see it as simple to show E_DEPRECATED but not when installed from
PECL.
1) Add a
int mysql_extension_triggers_deprecated_warning = 1;
And
Kris
I think you're forgetting though that the same applies to PHP itself. Many
repos still default to PHP 5.1.x. Adoption always tends to be a lagging
factor. I don't see any evidence to suggest that Drupal and other distros
have even slower adoption rates than PHP. In fact, the opposite
Guys,
PHP arrays are a great one-size-fits-all data structure. But like all
one-size-fits-all anything, jack-of-all-trades usually means master of
none.
There are definitely benefits to using specific data structures if
implemented correctly under the hood.
A good example of this is a Queue.
Victor,
If you give a closer look to my example, you will notice a difference:
$map[$setA] and $map[$setB] point to the same storage which I think is not
possible with SPLObjectStorage.
Well, how could you do that? Without implementing object comparison methods
at least (which is outside the
Tjerk,
I've been hearing this argument from time to time and I don't understand
it; aren't exceptions created with the sole purpose of (error) flow
control?
If so, then how can exceptions for flow control and very bad idea be
mentioned in the same sentence unless there are particular bad use
Sherif,
You're right. It does break BC, but this was a bug fix.
https://bugs.php.net/bug.php?id=61038
The behavior is incorrect in that regard.
However in this case that *bug* does have fairly significant BC
implications.
In fact, how I read the specification is that the original binary
Clint,
...snip...
I like the idea of an init function, but that would have to wait for a
further release I think, or delay this whole project a year.
Well, just speaking in general, we should not try to rush through these
kinds of design decisions. They should only be done incrementally if
Stas,
I think this is way too much magic. This means default is no longer a
default, but instead some obscure flag that somehow is carried over to
the setter. I do not think redefining initialization as permitting nulls
is a good idea, initialization and value set are two different things.
Stas,
But this in for methods, and you are putting it into entirely different
place - property initializer. That's what I call magic - somehow
property initializer magically becomes method parameter's default value.
The same could be used to justify the param order difference between
strings
Stas,
You really put it in the same answer as telling me it's the same as
parameter defaults? Here you introduce completely new concept, not
existing in PHP at all - non-constant initializers. And this is a whole
new can of worms - when it should be run, what should happen when it's
run, what
Stas,
This is pretty bad by itself. But the fact that everybody would be using
this feature in this way - since they would think I don't need null
default, null is always the default and I'd initialize it in the ctor
anyway, not realizing that declaring public DateTime $foo blocks
unset - is
Stas,
You can not both say it works just like method parameters and in the
same breath say it needs the concept of dynamic initializers which never
existed in PHP and which BTW was not introduced in the RFC either (and
which won't solve the problem you're trying to solve anyway).
I never
Yahav and all,
On Sun, Jan 6, 2013 at 4:58 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
Hi internals!
In one of the discussions (about the deprecated keyword, to be specific),
it was been said that adding ability to read doc-comment annotation could
be handy. Personally, I really think
Nathan,
On Mon, Jan 7, 2013 at 12:10 PM, nat...@starin.biz wrote:
I wanted some thought from you guys about the idea of giving PHP scripts
the
ability to read some internal information about variables such as ZVals.
The idea of how this reflection class would work would be something like:
Levi
Maybe I'm a complete fool, but since annotations aren't executed (they
are declarative only), this should cause no problems.
You're not a fool. And the point is not that they are executed, but because
they are nearly syntactically identical to executable code. So parser and
readability
Rasmus
This is my worry as well. Especially when it comes to opcode cache
support. Most of the patches I see these days completely ignore the
opcode cache side of things which needs to change. For any large
language-level change, any implementation that doesn't also include an
APC diff, or
Stas,
On Wed, Jan 9, 2013 at 11:58 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
I seriously hope it never comes to this in PHP
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Frankly,
Amaury,
Would you shut up with this rhetoric already? All it does is show that
you're completely and utterly out of touch with the reality of modern
development.
Frankly, I'm getting sick and tired of seeing these recurring themes of
PHP is not java and I never want this. If you never want
Stas,
It is a recurring theme because it's true. You are right that every
language needs a vision, and PHP's vision is being simple and practical
and focused on the web. PHP is what people use to get their first site
off the ground. PHP is what a web designer learns when he/she wants to
go
1 - 100 of 602 matches
Mail list logo
