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 threaded
On Tue, Sep 10, 2013 at 11:19 AM, Rasmus Lerdorf 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,
> regardless of how th
should be the norm; where
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
On Fri, Sep 6, 2013 at 6:01 PM, Pascal Chevrel 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 complete.
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 k
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 me
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
excepti
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 wrote:
> On 4/14/2013 7:56 PM, Laruence w
This looks great, I'm taking a look and testing it!
Yeah, like this as well, and +1 for consistency.
l, instead of living 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
ng is that: IF you want to keep the old way of doing
things around instead of removing them, 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
> use a slightly modified version of the open tag, for example <*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 be ab
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
On Mon, Jul 16, 2012 at 4:31 PM, Amaury Bouchard 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 syntax for managi
> 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:
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] syn
SPRNG 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 t
w how that feels like).
If not, then at least consider 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
ers.
I personally think there's a place for having both.
> 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
>>
>&
, NULL, 10
// vs. using a reserved word
fn1(default, default, 10), // FALSE, NULL, 10
Cheers,
On Wed, Apr 18, 2012 at 11:21, Peter Cowburn wrote:
> On 18 April 2012 10:25, Daniel Macedo wrote:
>>
>> But I couldn't support the comma train, for the insane «lots of
>> param
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 wrote:
>
> Something like
>
> setcookie( name:'mycookie', value:'abc', secure:true, ht
Only $599? This looks like an awesome deal!
Retards...
On Thu, Apr 12, 2012 at 16:27, CelebrityAccess wrote:
> There is no better time to subscribe to CelebrityAccess – the industry’s
> most comprehensive source of live event news and information.
>
> More data… More news… In depth analysis… a
> 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
) * $b - pow(10, $c) / 2");
Came across something like that in the manual: http://php.net/ref.bc#107014
How's 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
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
arithmetic
"/var/logs/php_error_log"
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
rray) 'test' // 'test'
(string array) 123 // '123'
(string array) TRUE // '1'
(string array) array(1, 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
> 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 Devel
*several entries* per type cast (since spaces are
allowed inside casts anyway, 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
.
Made me 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
including throwing an error 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
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 har
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 th
discussion
whenever this comes around again (as it inevitably does)...
~ Daniel Macedo
On Wed, Feb 22, 2012 at 14:13, Dmitri Snytkine
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
37 matches
Mail list logo
