Got this notification as well, I assumed it was a one-time error.
Maybe someone from internals-owner@ should take a look at what's going on... (=
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Why not both?
The list should and will remain, but I see no issue in using the same
inbox to start/reply-to a thread; it's been done, it can be done!
And I don't think it's just about keeping people who like one or the
other more, but rather allowing a quick read over the conversation in
a
On Tue, Sep 10, 2013 at 11:19 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
I think you are over-thinking this case actually. I would prefer to just
keep it simple. If someone does a named parameter call to a method that
doesn't have a parameter with a specified parameter it is an error,
we'd force the dev to implement the *same* args as the parent (like it
is now: i.e. type hinting, same signature, etc); even if it's just to
do an unset($oldbar) inside something like B::foo($newBar, $oldBar =
NULL)
Was that clear?
Thanks,
Daniel Macedo
--
PHP Internals - PHP Runtime Development
Dan,
That's a good question as well, with the current $var syntax I'm assuming NO.
You're using the $var3 name as a key, not as the $paramToOverride value.
Maybe the collon could be used here?
$paramToOverride = 'var3';
testFunction(:$paramToOverride = 'bar'); // Colon before $ would make
the
On Fri, Sep 6, 2013 at 6:01 PM, Pascal Chevrel pascal.chev...@free.fr wrote:
Le 06/09/2013 18:39, Nikita Popov a écrit :
Hi internals!
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
The RFC and implementation are not yet
I can accept not supporting PSR directly but implementing the class
autoloader and stating internals believes autoload in should exist, just
doesn't specify/support any particular implementation, this makes sense,
although I like PSR and don't really see others that make (as much) sense.
This
Sorry but I disagree, I think you're approaching try-catch wrong.
You shouldn't have a try-catch that *can* continue on the next line after
the throw.
What you should do is have decoupled code that handles _their own
exceptions_ nicely and either cleans up after itself else it rethrows the
I've seen the usage of signing/hashing stored along side the serialized
data to prevent this sort of injection.
Still not 100% safe, but in case you really can't escape the use of
serialize, it's a start...
On Mon, Apr 15, 2013 at 2:52 PM, Thomas Hruska thru...@cubiclesoft.comwrote:
On
This looks great, I'm taking a look and testing it!
Yeah, like this as well, and +1 for consistency.
in an ever
more complex compatibility hurt fest that exists on other platforms...
Cheers,
Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
use a slightly modified version of the open tag, for example ?php6 or
*php, etc. This satisfies several desires: we don't want an extra
line of boilerplate code like 'use PHP 6' to be required in every
source file, we want a PHP 5 file to run without modification, and we
want a PHP 6 file to
, it should be change
settings/tag/whatever so it work as the old way and not change it so
it works the new way, that was my only point.
Cheers
Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
You already have the read-only/write-only option proposed on that RFC
- by not defining set and vice-versa for write only - or by inserting
new keywords (not sure if this is needed/optimal).
And nowhere in PHP do we have the syntax you propose as A:B, and I
even recall a short array [a:1, b:2]
If you just want an attribute that is:
- readable from everywhere
- writable from the current class only
I believe the RFC sugests:
public $a {
private set;
}
Would be enough, if I understand correctly...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Mon, Jul 16, 2012 at 4:31 PM, Amaury Bouchard ama...@amaury.net wrote:
My point is not to add two ways to do the same thing.
What I'm humbly suggesting to do is to keep the core idea of the existing
RFC (make things easier when you have to write getters/setters), and think
about another
That is already accounted for, both the visibility (what's inside
limits what's before the variable) as well as changing the
write-only/read-only options. If you read the RFC, when extending a
class and adding set method to a member that was read-only, you
overload the read-only setting...
Hence
implementations around), I've seen salts used from numbers to
md5's to just being skipped altogether.
~ Daniel Macedo
NOTE: Although related/solving some of the same problems; skipping optional
parameters (several commas or using 'default' keyword) is different from
using named parameters.
And both have different supporters/haters over each change.
I wouldn't like to restart the whole debate over the KISS, Not
this should be marked as deprecated
(even without a due date for complete removal), just for the sake of
no longer being maintained!
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'll keep going offtopic a bit more.
I would rather see named parameters implemented *prior* to this.
Although maybe not instead, I think both might have their place.
On Wed, Apr 18, 2012 at 08:43, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Something like
setcookie( name:'mycookie', value:'abc',
// vs. using a reserved word
fn1(default, default, 10), // FALSE, NULL, 10
Cheers,
On Wed, Apr 18, 2012 at 11:21, Peter Cowburn petercowb...@gmail.com wrote:
On 18 April 2012 10:25, Daniel Macedo admac...@gmail.com wrote:
But I couldn't support the comma train, for the insane «lots
.
Daniel Macedo wrote:
function fn1($a = false, $b = nul, $c = 1)
{
var_dump($a, $b. $c);
}
// your idea
fn1(NULL, NULL, 10), // NULL, NULL, 10
// vs. using a reserved word
fn1(default, default, 10), // FALSE, NULL, 10
Of cause one little problem here is if the default gets changed
Though does it count if it's still March 31st over here? ;)
--Kris
Nope, you've been caught! (=
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
error_reporting = E_ALL ~E_DEPRECATED
Cheers,
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Michael, I'm with Anthony, in that you shouldn't change behaviour of
this nature with an ini setting.
I would bring more pain than what it takes away.
This is one of those gotchas that everyone comes across, like you noted.
The main issue is that floating point arithmetic != real number
that for a quick 'n dirty idea to solve this issue?
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, but could also be a semicolon or
something):
$int_or_null = (int unset) $x;
This could be usefull for other instances as (string null) or (bool
null) as well... Your thoughts?
Best regards,
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
This could be usefull for other instances as (string null) or (bool
null) as well... Your thoughts?
Typo! The examples should read (string unset) and (bool unset)
BTW: Order would equal what is type casted OR simply accepted!
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development
, 2, 3) // array(3) { [0]= int(1) [1]=
int(2) [2]= int(3) }
I find this way more useful/complete/readable than what you proposed.
Best regards,
~ Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
if there's loss of data in
conversion. Although I'm not so sure about having strong types...
Regards,
Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hate him a little bit, but I have to say I'm satisfied with
that reply. :)
Best regards,
Daniel Macedo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anthony,
Remember you're dealing with the internals list. :)
I kind of like the idea of having long proper discussions on a
particular topic. But let's face it, that's an utopic view (at best)!
Even if optional, and even if backwards compatible, there are a number
of things that will be quite
Quick note:
If you're not storing Belarusian, Macedonian, Serbian, or Ukrainian or
have no need for *proper sorting* of the extra letters in these
languages NOR the support of expansions and ligatures; I would revert
to using utf8_general_ci, which is _slightly_ faster but converts all
chars to
this comes around again (as it inevitably does)...
~ Daniel Macedo
On Wed, Feb 22, 2012 at 14:13, Dmitri Snytkine
dsnytk...@ultralogistics.com wrote:
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
36 matches
Mail list logo
