Yasuo Ohgaki wrote:
I've made the patch for trunk. I checked by using session module
tests using valgrind.
https://gist.github.com/1379668
As a general comment there seems to be lots of extra white space
in the 'empty' lines of the patch.
Index: ext/session/php_session.h
=
2011/11/30 Nikita Popov
> If we really want this kind of (expr)-> syntax, then it should really
> accept *any* expr. But I am not quite sure whether this will work out
> easily because in this case we can't be sue that expr is an object
> (but maybe it'll be simple, I just don't know).
>
Same as
On 2011-11-30, Sebastian Bergmann wrote:
> Am 30.11.2011 19:09, schrieb Ralph Schindler:
>> $value = ($obj = new Foo)->produceAValue();
>
> -1
Just curious: why?
(Not that I'm 100% sure I agree with it myself, but curious why you
would vote against it...)
--
Matthew Weier O'Phinney
Project Le
On 2011-11-30, Will Fitch wrote:
> If that's the case, then why not just add whatever $options is as a
> parameter to your constructor. I'm not totally against this concept,
> but this use is moot.
No, it's not.
Consider the case of using a variable for the class name -- i.e.,
dynamic classload
You surely could add a factory to every class in your project, perhaps with
a trait, but you wouldn't have it for core and third party classes.
On 30 November 2011 19:59, Will Fitch wrote:
> Again, back to my question of why not use:
>
> MyComponent::factory($bar, $option);
>
> Depending on wha
If that's the case, then why not just add whatever $options is as a parameter
to your constructor. I'm not totally against this concept, but this use is
moot.
On Nov 30, 2011, at 2:51 PM, Ralph Schindler wrote:
> Ironically, quite the opposite is something I find useful:
>
> ($foo = new MyCom
On 30 November 2011 19:59, Will Fitch wrote:
> Again, back to my question of why not use:
>
> MyComponent::factory($bar, $option);
>
> Depending on what ::factory does, it could then pass $option(s) to the
> constructor or method getting your instance needed.
>
It brings to mind a review of Dart
Again, back to my question of why not use:
MyComponent::factory($bar, $option);
Depending on what ::factory does, it could then pass $option(s) to the
constructor or method getting your instance needed.
On Nov 30, 2011, at 2:56 PM, Dmitri Snytkine wrote:
> Just for such case I use factory m
Just for such case I use factory methods in a class, so I can do this:
MyComponent::factory($bar)->configure($option)
A clean one-liner.
The static factory method just returns the object of class, your standard
factory pattern.
Plus you may gain extra flexibility from using factory instead of di
Ironically, quite the opposite is something I find useful:
($foo = new MyComponent($bar))->configure($options);
In a single line, instantiate and configure (via an API call) an object.
The return of configure() is not important to me, but the brevity of
that workflow, and the result of "new"
Hi,
personally I would find the proposed syntax very useful, similarly to the
following one that is already implemented:
if ($value = foo()) return $value
instead of
$value = foo();
if ($value) return $value;
Regards,
Devis
On 30 November 2011 19:13, Nikita Popov wrote:
> To me the main
To me the main problem here is that $bar = ($foo = new Foo)->bar()
simply doesn't make much sense. It is equivalent to:
$foo = new Foo;
$bar = $foo->bar();
Which is much cleaner and easier to understand.
The plain (new Foo)->bar() syntax *is* useful for cases like (new
ReflectionClass($class))->im
Hi Sebastian
As I agree with your position, there is no vote anymore on the list but
discussions.
About this addition, yes it should accept any expression. However I fail to
see the gain then but to get a perlish line.
Cheers,
On Nov 30, 2011 7:58 PM, "Sebastian Bergmann" wrote:
> Am 30.11.201
Nikita,
You're completely right about the expanded expressions, but I'm not sure
its an edge-case per-se.
The problem with the current syntax is that the resultant of the 'new'
operation is lost UNLESS your chained method returns $this - which IMO
makes it about as 1/2 as useful as it really
Am 30.11.2011 19:09, schrieb Ralph Schindler:
> $value = ($obj = new Foo)->produceAValue();
-1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mail
If I could get some comments on the original issues I mentioned (in
http://markmail.org/message/aohq5lcoeaiqos7y?q=php+internals+list:net.php.lists.internals)
it would be really nice, too :)
Nikita
On Wed, Nov 30, 2011 at 6:28 AM, Александр Москалёв wrote:
> Morfi, see my mail in this thread. St
Hi Ralph!
This (in it's current form) doesn't look like a good idea to me. You
are only handling yet another edge case. ($foo = $bar = new A)->bar()
would again not work.
If we really want this kind of (expr)-> syntax, then it should really
accept *any* expr. But I am not quite sure whether this
Hey all (Filipe),
This was brought up in the thread "New dereferencing syntaxes in 5.4".
I too think this would be beneficial:
$value = ($obj = new Foo)->produceAValue();
but the current parser (branch 5.4) doesn't have a rule for this. I've
attached a quick/working patch, but I don't full
Hi Stats,
One additional comment.
2011/11/30 Yasuo Ohgaki :
> Hi Stats,
>
> 2011/11/30 Stas Malyshev :
>>> I though I've better to start new thread, since I changed the status
>>> to "Under Discussion".
>>>
>>> This is RFC for making PHP session strict.
>>>
>>> https://wiki.php.net/rfc/strict_ses
Hi Stats,
2011/11/30 Stas Malyshev :
>> I though I've better to start new thread, since I changed the status
>> to "Under Discussion".
>>
>> This is RFC for making PHP session strict.
>>
>> https://wiki.php.net/rfc/strict_sessions
>>
>> I'll implement DoS protection later, since current patch pret
Hi peter:
On Wed, Nov 30, 2011 at 5:23 PM, Peter Cowburn wrote:
> Hi Laruence et al.
>
> On 30 November 2011 06:06, Laruence wrote:
>> Hi:
>>
>> base on feature request: https://bugs.php.net/bug.php?id=60408 , I
>> wrote a patch to make php support const array/string dereference
>>
>> rfc is
Hi Laruence et al.
On 30 November 2011 06:06, Laruence wrote:
> Hi:
>
> base on feature request: https://bugs.php.net/bug.php?id=60408 , I
> wrote a patch to make php support const array/string dereference
>
> rfc is here, https://wiki.php.net/rfc/constdereference
>
> any opinions?
Could y
Hi!
Hi all,
I though I've better to start new thread, since I changed the status
to "Under Discussion".
This is RFC for making PHP session strict.
https://wiki.php.net/rfc/strict_sessions
I'll implement DoS protection later, since current patch pretty well
tested and suitable for PHP 5.4/5.3
Hi all,
I though I've better to start new thread, since I changed the status
to "Under Discussion".
This is RFC for making PHP session strict.
https://wiki.php.net/rfc/strict_sessions
I'll implement DoS protection later, since current patch pretty well
tested and suitable for PHP 5.4/5.3, too.
24 matches
Mail list logo
