If everything is chained, it's a pain to figure out such basic workings.
Hi,
I still find it hard to understand why some should artificially claim basic
constructs supported by other languages for years are somehow more complex
than PHP's existing semantics.
Supporting dereferencing in all
Hi Stas:
On Tue, Jan 19, 2010 at 12:09:53PM -0800, Stanislav Malyshev wrote:
>
> $oop = $eep->oop();
> $ork = $oop->ork();
> $ah = $ork->ah();
> $ah2 = $ah->ah();
>
> where it instantly becomes crystal clear!
:) Yep, that's lousy code.
Variables should be named for the classes they represent.
On Jan 19, 2010, at 5:54 PM, Alain Williams wrote:
>>> $eep->oop()->ork()->ah()->ah();
>>>
>>> the newcomer will have to spend significant time rummaging around the
>>> source code to figure out what classes are involved.
>> As opposed to:
>> $oop = $eep->oop();
>> $ork = $oop->ork();
>> $ah = $or
On Tue, Jan 19, 2010 at 12:09:53PM -0800, Stanislav Malyshev wrote:
> Hi!
>
> >$eep->oop()->ork()->ah()->ah();
> >
> >the newcomer will have to spend significant time rummaging around the
> >source code to figure out what classes are involved.
>
> As opposed to:
> $oop = $eep->oop();
> $ork = $oo
Hi!
$eep->oop()->ork()->ah()->ah();
the newcomer will have to spend significant time rummaging around the
source code to figure out what classes are involved.
As opposed to:
$oop = $eep->oop();
$ork = $oop->ork();
$ah = $ork->ah();
$ah2 = $ah->ah();
where it instantly becomes crystal clear!
Hi Stas:
> If you don't understand the language, nothing is self-documenting.
Yes. For clarity, what I meant by the "knowing the language" reference,
I was imagining a PHP programmer trying to read/debug the code of a
pre-existing project for the first time. When the code does stuff like:
fo
Hi!
Sure. But one needs to understand the language. Otherwise the reader
needs to go hunting around a dictionary (or in our case, the source code)
to figure out what the heck the person (code) is trying to say (do).
Chaining produces code that is not self-documenting.
If you don't understan
Hi Stas:
On Tue, Jan 19, 2010 at 10:30:28AM -0800, Stanislav Malyshev wrote:
>
> People like to speak in full expressive sentences
Sure. But one needs to understand the language. Otherwise the reader
needs to go hunting around a dictionary (or in our case, the source code)
to figure out what
Hi!
When I use one, I consider it exotic/obtuse/unusual enough to require
self-documenting code, with a temp variable whose name include
'closure'.
By "use" I meant not "use it so rarely that it's an exotic hack for me
that I have to explain what I did here", I mean "write code that relies
o
Hi!
enhancements in the sense that they enable things that were not
possible before, sure. syntax sugar that hurts readability, not
really.
It starts to seem to me that the notion of readability is rather
different here than in the rest of the world. Lately, almost any syntax
sugar features
Hi!
I don't mind the foo()() syntax, especially now that we have closures.
But people are right, we have a longstanding feature request for
$foo()[0] as well, so if we start down this path of adding chaining, we
should do that one as well and see if any others make sense.
As I said, that was n
On Tue, January 19, 2010 10:05 am, Stanislav Malyshev wrote:
> Hi!
>
>> I'd rather see two other things that are missing, support for
>> dynamic object and array de-referencing like
>> (new class)->method() and get_array()["index"].
>
> The second was next on my list, while the first seems to me ki
On Tue, January 19, 2010 5:19 am, Alain Williams wrote:
> I have seen the argument that things like this will confuse novice
> programmers,
> maybe: but would they ever try to type something like that ?
Yes, because they see the experts typing something like that.
What's more, they have to READ s
On Tue, January 19, 2010 1:29 am, Eddie Drapkin wrote:
> On Tue, Jan 19, 2010 at 2:14 AM, Alexey Zakhlestin
> wrote:
>>
>> Would be nice if something like this worked too:
>>
>> Â Â (new Class())->method();
>>
>>
>
> I was just looking at some Java code and thinking, "man I wish PHP did
> this."
Op 1/19/10 1:27 AM, Stanislav Malyshev schreef:
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
>
> What it means is that if foo() returns callable value (which probably
> should be function name or closure) then it would be called. Parameters
> and more tha
Hello,
I have a few questions about error reporting in extensions for 5.3.1.
I need to convert any IS_OBJECT zval to char* without issuing an error;
failed conversions must throw.
I've tried this inside a PHP_METHOD:
zend_error_handling error_handling;
zend_replace_error_handling(EH_THROW, NULL
On 19.01.2010, at 18:39, Rasmus Lerdorf wrote:
> I don't mind the foo()() syntax, especially now that we have closures.
> But people are right, we have a longstanding feature request for
> $foo()[0] as well, so if we start down this path of adding chaining, we
> should do that one as well and see
Stanislav Malyshev wrote:
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
>
> What it means is that if foo() returns callable value (which probably
> should be function name or closure) then it would be called. Parameters
> and more than two sets of () work
Hello,
On Tue, Jan 19, 2010 at 10:07 AM, Lukas Kahwe Smith wrote:
>
> On 19.01.2010, at 18:03, Chris Stockton wrote:
> enhancements in the sense that they enable things that were not possible
> before, sure. syntax sugar that hurts readability, not really.
> if you are worried about key strokes
> -Original Message-
> From: Stanislav Malyshev [mailto:s...@zend.com]
> Sent: 19 January 2010 00:28
> To: 'PHP Internals'
> Subject: [PHP-DEV] function call chaining
>
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
>
> What it means is that if
Eddie Drapkin wrote:
> On Tue, Jan 19, 2010 at 12:02 PM, Rasmus Lerdorf wrote:
>> Eddie Drapkin wrote:
>>> On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev wrote:
The second was next on my list, while the first seems to me kind of exotic
-
why create object only to call one me
On Tue, Jan 19, 2010 at 12:02 PM, Rasmus Lerdorf wrote:
> Eddie Drapkin wrote:
>> On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev wrote:
>>> The second was next on my list, while the first seems to me kind of exotic -
>>> why create object only to call one method and immediately drop it? Why
On 19.01.2010, at 18:03, Chris Stockton wrote:
> Hello,
>
> On Mon, Jan 18, 2010 at 5:27 PM, Stanislav Malyshev wrote:
>> I wrote a small patch that enables this kind of syntax in PHP:
>>
>> foo()();
>> ...
>
> I think language enhancements with no BC breaks that offer a wider
> toolset to pr
Hello,
On Mon, Jan 18, 2010 at 5:27 PM, Stanislav Malyshev wrote:
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
> ...
I think language enhancements with no BC breaks that offer a wider
toolset to programmers is a good thing. I would also like to see the
other idea
Eddie Drapkin wrote:
> On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev wrote:
>> The second was next on my list, while the first seems to me kind of exotic -
>> why create object only to call one method and immediately drop it? Why this
>> method is not static then?
>
>
> Why would this imp
On Tue, Jan 19, 2010 at 11:05 AM, Stanislav Malyshev wrote:
> The second was next on my list, while the first seems to me kind of exotic -
> why create object only to call one method and immediately drop it? Why this
> method is not static then?
Why would this imply "dropping" the object?
This:
Hi!
I'd rather see two other things that are missing, support for
dynamic object and array de-referencing like
(new class)->method() and get_array()["index"].
The second was next on my list, while the first seems to me kind of
exotic - why create object only to call one method and immediately
On Tue, Jan 19, 2010 at 5:00 PM, Stanislav Malyshev wrote:
> Hi!
>
>> I'm not a fan of this kind of syntaxic sugars, especially for
>> procedural implementation only. What are the benefits?
>
> Some as all other syntax sugars - better-looking code.
Ah ok, then let say -1 from here for the functio
Hi!
I'm not a fan of this kind of syntaxic sugars, especially for
procedural implementation only. What are the benefits?
Some as all other syntax sugars - better-looking code.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
I'd rather see two other things that are missing, support for
dynamic object and array de-referencing like
(new class)->method() and get_array()["index"].
I honestly don't see func()()()() make anything better in the
world of a PHP programmer.
The array de-referencing and dynamic objects are mu
Hi,
On Tue, 2010-01-19 at 12:31 +0100, Michael Wallner wrote:
> On 01/19/2010 01:27 AM, Stanislav Malyshev wrote:
> > Hi!
> >
> > I wrote a small patch that enables this kind of syntax in PHP:
> >
> > foo()();
I think that becomes hard to read quite easily.
> I'd rather see two other things th
2010/1/19 Pierre Joye :
> On Tue, Jan 19, 2010 at 12:31 PM, Michael Wallner wrote:
>> On 01/19/2010 01:27 AM, Stanislav Malyshev wrote:
>>> Hi!
>>>
>>> I wrote a small patch that enables this kind of syntax in PHP:
>>>
>>> foo()();
>>
>> I'd rather see two other things that are missing, support fo
On Tue, Jan 19, 2010 at 12:31 PM, Michael Wallner wrote:
> On 01/19/2010 01:27 AM, Stanislav Malyshev wrote:
>> Hi!
>>
>> I wrote a small patch that enables this kind of syntax in PHP:
>>
>> foo()();
>
> I'd rather see two other things that are missing, support for
> dynamic object and array de-re
On 01/19/2010 01:27 AM, Stanislav Malyshev wrote:
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
I'd rather see two other things that are missing, support for
dynamic object and array de-referencing like
(new class)->method() and get_array()["index"].
I ho
On Tue, Jan 19, 2010 at 01:55:32PM +0300, Alexey Zakhlestin wrote:
>
> On 19.01.2010, at 13:47, Christian Schneider wrote:
>
> > Alexey Zakhlestin wrote:
> >> Would be nice if something like this worked too:
> >>(new Class())->method();
> >
> > If you *really* want to do this you can use a f
On 19.01.2010, at 13:47, Christian Schneider wrote:
> Alexey Zakhlestin wrote:
>> Would be nice if something like this worked too:
>>(new Class())->method();
>
> If you *really* want to do this you can use a factory method:
> Class::create()->method();
I know. That's what I do if I need it.
hi Stan,
On Tue, Jan 19, 2010 at 1:27 AM, Stanislav Malyshev wrote:
> Hi!
>
> I wrote a small patch that enables this kind of syntax in PHP:
>
> foo()();
>
> What it means is that if foo() returns callable value (which probably should
> be function name or closure) then it would be called. Parame
Alexey Zakhlestin wrote:
> Would be nice if something like this worked too:
> (new Class())->method();
If you *really* want to do this you can use a factory method:
Class::create()->method();
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
On 01/19/2010 01:30 PM, Jani Taskinen wrote:
> Funny, I was just thinking the opposite "man I wish PHP never allows
> this" :)
>
> Can of worms I say, can of worms..
Exactly my thought.
Please, let's not open it.
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP
On 01/19/2010 09:29 AM, Eddie Drapkin wrote:
On Tue, Jan 19, 2010 at 2:14 AM, Alexey Zakhlestin wrote:
Would be nice if something like this worked too:
(new Class())->method();
I was just looking at some Java code and thinking, "man I wish PHP did this"
Funny, I was just thinking the
40 matches
Mail list logo
