Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 02:32, schrieb Stas Malyshev: I'm not sure I understand why you need week refs there - can't you just always use $prodDb-getProduct(1) and when you don't need it anymore just do $prodDb-drop(1)? Or let it drop it whenever it wants to? My Project requires lots of DB-Record = PHP-Object mapping, as the objects get used quite dynamically I can't know when and how often an object will be used. To make sure there's only one instance of an Object in Memory per Session, I cache them in an associative-array, the key being the record-id (actually a PHP-Object consists of many records). Then I am using the Singleton-Pattern like Library::getObject($id) which returns a new (fetched freshly from the DB) or an already used object (from the cache). This works very well and keeps me from expensively reconstructing objects from the DB. What it does not work well with is Garbage collection, since the an object will always be referenced at least once (by the cache). The longer a script is running, the higher the chance that it will run out of memory (fast). I do want to keep those objects for as long as possible, but not if the price is an out of memory fatal error. My solution to this was neither nice nor correct, but I could not think of anything else: Whenever I'd create a fresh object I'd check memory against its limit and if it runs close, I will discard the oldest objects from the cache, always running the risk that my singleton is suddenly not so single anymore, because a discarded object was still referenced somewhere else. So either I get to know if the object is actually in use somewhere else than just the cache (using the zval-refcount method) or PHP provides me with something like WeakReference or even better: SoftReference, which would give me more control as to when it would be collected. I am open to any suggestions how I could solve my problem without WeakReference or zval-refcount (short of keeping a ref-count in userland). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] An implementation of a short syntax for closures
Hello everyone.
I am new to the php-internals list. I have joined because I have
implemented a feature that I would like to be included in the php
language: a shorter syntax for lambdas. I am going to briefly present
it here. Apologies for the long (and yet incomplete) e-mail. I am
ready to write a more complete RFC in the wiki, however, I would
appreciate having some directions for that. Do I have to ask for
permission first? Is it open to anyone to submit an RFC?
1. NECESSITY:
This feature was briefly discussed in this list about a month ago:
http://marc.info/?t=13092691823r=1w=2.
It is also one of the asked (and upvoted) features in the open stack
overflow's discussion:
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php.
Finally, I have written a small and probably incomplete article in my
blog about the necessity of a shorter syntax for lambdas:
http://linepogl.wordpress.com/2011/07/09/on-the-syntax-of-closures-in-php/
2. THE CURRENT SYNTAX
I give 3 examples with the current syntax:
// Mapping:
$a-select( function($x){ return $x-getName(); } );
// Filtering:
$a-where( function($x)use($y){ return $x==$y; } );
// Currying:
$add = function($x){ return function($y)use($x){ return $x+$y; }; };
In my opinion, the above code is not easily readable. Yet, those
examples are not very complicated. The first two are samples of
elegant LINQ-style code while the last one can be found in the first
pages of any functional programming tutorial.
3. PROPOSED SYNTAX
The syntax I propose and I have already implemented is this:
// Mapping:
$a-select( | $x |= $x-getName() );
// Filtering:
$a-where( | $x : $y |= $x==$y );
// Currying:
$add = | $x |= | $y : $x |= $x+$y;
4. ADVANTAGES
a. The code is more readable (see more in my blog if you are not
convinced about that).
b. The syntax is backwards compatible. The short lambda and the longer
equivalent are interchangeable.
c. Variable scoping works exactly like in the longer version. There is
nothing new but syntactic sugar.
d. Lambda expressions are searchable. The |= operator is unique.
e. The |= operator is similar to =. That's good because they both
relate to mapping. In addition, the : operator is similar to :: and
that's also good because they both relate to scoping.
f. The implemented syntax supports type hinting, passing by reference
and return by reference. There is also an option to fall back to a
statement block if the single return statement is not enough.
Therefore is a complete alternative to the existing syntax.
5. DISADVANTAGES
a. The short syntax is clear and readable, but can become confusing
when used in the wrong places. Yet, isn’t this the case with every
feature?
b. A lambda without arguments conflicts with the logical or operator.
A way to avoid this is to insert whitespace between the two pipes, but
this breaks the invariant that whitespace is not important in PHP.
Although this use case is not ideal for short lambdas, it can be fixed
at the compiler level by introducing the rather long operator ||=.
c. The newly introduced feature of static closures is not yet
supported. The short lambdas behave like dynamic closures for the time
being.
You can download the patch on the 5.4 branch from here:
https://bitbucket.org/linepogl/php_short_closures/downloads/short_closures_syntax_0.1_php54.diff
I have posted a more complete presentation here:
http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/
I am ready to give more examples and to further defend my proposal.
However as I am new to your community, I would like to have some
directions on the way I should continue.
Kind regards,
Lazare INEPOLOGLOU
Ingénieur Logiciel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hi! On 8/3/11 11:03 PM, Lars Schultz wrote: (from the cache). This works very well and keeps me from expensively reconstructing objects from the DB. What it does not work well with is Garbage collection, since the an object will always be referenced at least once (by the cache). The longer a script is running, the higher I'm sorry but you putting forth contradictory requirements here - you want to keep the objects (to avoid expensively reconstructing them) and you don't want to keep them (memory problems). You'll have to give up one of these requirements. As I see, you gave up the caching requirement and you clean up objects when memory is tight. As long as you don't need more objects than you have memory you should be fine. objects from the cache, always running the risk that my singleton is suddenly not so single anymore, because a discarded object was still referenced somewhere else. You should control your code so that somewhere else does not keep extra references. As well as you'd have to control you code if you use weak refs, otherwise extra references would still keep objects alive - or you'd have to rewrite your code and control it so that is always uses weak refs and always checks that the ref is alive. I am open to any suggestions how I could solve my problem without WeakReference or zval-refcount (short of keeping a ref-count in userland). Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On 08/04/2011 12:08 AM, Lazare Inepologlou wrote: $add = | $x |= | $y : $x |= $x+$y; This does not seem to match the syntax of any language I know of so people are going to have a hard time figuring out what this does. It's not even clear that |= is a new operator there due to the dangling |, which as you say conflicts with the regular | operator. Plus it is only useful in one limited type of trivial closure usage. In PHP we try really hard not to invent new unfamiliar syntax. We try to stick with things that have some basis in either the existing syntax or in other popular languages that the average PHP developer might be exposed to. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Hi,
I've always thought that just supressing the function keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
Regards,
David
On Thu, Aug 4, 2011 at 2:23 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 08/04/2011 12:08 AM, Lazare Inepologlou wrote:
$add = | $x |= | $y : $x |= $x+$y;
This does not seem to match the syntax of any language I know of so
people are going to have a hard time figuring out what this does. It's
not even clear that |= is a new operator there due to the dangling |,
which as you say conflicts with the regular | operator. Plus it is only
useful in one limited type of trivial closure usage.
In PHP we try really hard not to invent new unfamiliar syntax. We try to
stick with things that have some basis in either the existing syntax or
in other popular languages that the average PHP developer might be
exposed to.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Hi!
On 8/4/11 12:31 AM, dukeofgaming wrote:
I've always thought that just supressing the function keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
My opinion is that when almost any mix of alphanumeric and
non-alphanumeric characters becomes a valid syntax in the language, it's
taking it a bit too far :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Stas Malyshev wrote: I am open to any suggestions how I could solve my problem without WeakReference or zval-refcount (short of keeping a ref-count in userland). Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. Like you Stas I am having trouble understanding what the problem is ... On one 'project' I'm playing with I build a tree of genealogical references in memory, all identified by their unique_id. If the person has already been loaded, then it simply uses the existing reference for that element of the tree. If there is a change to data for some reason the 'cached' record is deleted so that it has to be re-read from the database next time it's accessed ... if it is accessed at all. Persons are all class objects ... so deleting is just marking the object as invalid at which point ( I hope ) the underlying data is dropped. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] test
Hello ! It's a test. Sorry for noise. Best regards, Fred -- Frédéric Hardy : Architecte d'application/Admin. système/Ergonome CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf Blog : http://blog.mageekbox.net Twitter : http://twitter.com/mageekguy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Hello !
I've always thought that just supressing the function keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
Huge +1 for that.
Code using closures will be more readable.
$add = | $x |= | $y : $x |= $x+$y;
Not sure that it's really readable.
Moreover, it's more Perl/Ruby way than PHP way.
Best regards,
Fred
--
Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
Blog : http://blog.mageekbox.net
Twitter : http://twitter.com/mageekguy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Good morning Rasmus, Thank you for your interest. This is just a proposal that I have tested and works. Of course, the final syntax can be different. Syntax is always a matter of taste :-) it is only useful in one limited type of trivial closure usage This trivial usage is actually the most common one. A single-return closure can be used for sorting, mapping, filtering, lifting, folding, comparing, validating, formatting, lazy-loading etc. which cover the majority of the tasks a PHP programmer does everyday. The popular LINQ library is just an example of the power of this kind of closures. The only case that these closures are not useful is asynchronous (event-driven) programming. However, PHP is single threaded and usually delegates the user interface to javascript, and therefore, two major needs for asynchronous programming are eliminated. In PHP we try really hard not to invent new unfamiliar syntax. I have done some research before posting and it seems that the proposed syntax is not at all uncommon. For example, here is the same comparer written in a variety of languages: Proposed for PHP: | $x , $y |= $x - $y C#: ( x , y )= x - y Haskell: \ x y - x - y Python: lambda x y: x - y OCaml, F#: fun x y - x - y StandardML: fn x y = x - y There are many similarities here. In all of the above examples, there is no return and no curly brackets. In addition, all expressions begin with a token and separate the arguments from the returning expression with another token. Kind regards, Lazare INEPOLOGLOU Ingénieur Logiciel 2011/8/4 Rasmus Lerdorf ras...@lerdorf.com On 08/04/2011 12:08 AM, Lazare Inepologlou wrote: $add = | $x |= | $y : $x |= $x+$y; This does not seem to match the syntax of any language I know of so people are going to have a hard time figuring out what this does. It's not even clear that |= is a new operator there due to the dangling |, which as you say conflicts with the regular | operator. Plus it is only useful in one limited type of trivial closure usage. In PHP we try really hard not to invent new unfamiliar syntax. We try to stick with things that have some basis in either the existing syntax or in other popular languages that the average PHP developer might be exposed to. -Rasmus
Re: [PHP-DEV] An implementation of a short syntax for closures
Hello,
$add = | $x |= | $y : $x |= $x+$y;
Not sure that it's really readable.
This is not the most trivial example. In my blog, there is a small
sub-section where I explain why this is more readable than an implementation
with the current syntax. See under Readability and A more complicated
example.
http://linepogl.wordpress.com/2011/08/04/short-closures-for-php-an-implementation/
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
Le 4 août 2011 10:50, Frédéric Hardy frederic.ha...@mageekbox.net a écrit
:
Hello !
I've always thought that just supressing the function keyword could work
as a shorthand, i.e. having ([param1 [, param2 [, ...]]]){...}. Somewhat
similar to Ruby's lambda shorthand:
http://slideshow.rubyforge.org/ruby19.html#40
Huge +1 for that.
Code using closures will be more readable.
$add = | $x |= | $y : $x |= $x+$y;
Not sure that it's really readable.
Moreover, it's more Perl/Ruby way than PHP way.
Best regards,
Fred
--
Frédéric Hardy : Architecte d'application/Admin. système/Ergonome
CV : http://blog.mageekbox.net/public/cv.frederic.hardy.pdf
Blog : http://blog.mageekbox.net
Twitter : http://twitter.com/mageekguy
Re: [PHP-DEV] An implementation of a short syntax for closures
Hi all :-), On 04/08/11 09:23, Rasmus Lerdorf wrote: On 08/04/2011 12:08 AM, Lazare Inepologlou wrote: $add = | $x |= | $y : $x |= $x+$y; This does not seem to match the syntax of any language I know of so people are going to have a hard time figuring out what this does. It's not even clear that |= is a new operator there due to the dangling |, which as you say conflicts with the regular | operator. Plus it is only useful in one limited type of trivial closure usage. This syntax reminds me the “block lambda syntax”, presented on the ECMAScript's wiki [1] about the future of ECMAScript6. It seems they tend to choose the “arrow function syntax” [2], which is more natural and more readable. You can found pros and cons on the wiki, along with a lot of use cases/examples (including rebinding this!). For a quicker introduction to these two short syntaxes, I would suggest you to read the conference “FalsyValues” [3], from slide 31 to 36, recently given by Dmitry Soshnikov about the future of ECMAScript 6 (all the conference is a beauty, a must-read). In PHP we try really hard not to invent new unfamiliar syntax. We try to stick with things that have some basis in either the existing syntax or in other popular languages that the average PHP developer might be exposed to. +1. It must be the result of a long reflection and we should get a large vote from the community before choosen one syntax. Best regards. [1] http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival [2] http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax [3] http://www.slideshare.net/dmitrysoshnikov/falsyvalues-dmitry-soshnikov-ecmascript-6 -- Ivan Enderlin Developer of Hoa Framework http://hoa.42/ or http://hoa-project.net/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
On Thu, Aug 4, 2011 at 10:37 AM, Lester Caine les...@lsces.co.uk wrote: Stas Malyshev wrote: I am open to any suggestions how I could solve my problem without WeakReference or zval-refcount (short of keeping a ref-count in userland). Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. Like you Stas I am having trouble understanding what the problem is ... On one 'project' I'm playing with I build a tree of genealogical references in memory, all identified by their unique_id. If the person has already been loaded, then it simply uses the existing reference for that element of the tree. If there is a change to data for some reason the 'cached' record is deleted so that it has to be re-read from the database next time it's accessed ... if it is accessed at all. Persons are all class objects ... so deleting is just marking the object as invalid at which point ( I hope ) the underlying data is dropped. if you have gc enabled, and noone else references that object, then it will be freed next time when the gc runs. what weak references are trying to solve, that if you create such a Registry, as you do, your object will always have at least one reference (your Registry holds them), so gc won't collect those. with weak references, you can lazy load your Person records as you do, but every People record which only referenced through Weakrefs will be garbage collected on the next gc run. collecting the garbage will happen if the gc root buffer is full, or if you manually call gc_collect_cycles. http://www.php.net/manual/en/features.gc.collecting-cycles.php -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory management ...
I'm still trying to get my head around this 'Weak Reference' thing, but since I'm still working to be compatible with PHP5.2 then I've not taken much notice of this 'garbage collection' stuff. So this may be where I am missing something? I manage what material I need using a list of numbers, and create objects as and when they are required, pulling the detail from the database. There is a limit on the amount of memory available, so in the past I got 'out of memory', now I just say 'some detail not available'. If I'm out of space, then I reuse an existing object that is 'invalid', but to simplify things then much of the time I don't ACTUALLY need the full record, and simply build the page via the one object which is sequentially loaded ... slower, but memory efficient. Never do 'SELECT * FROM', always specify just the fields you need at that time. So it looks like the question I should be asking is How do you 'drop' an object? I think my take on this 'Weak Reference' stuff is that it does not actually 'create' the object? But I am creating the object because I need to use it, not because I may need it later? I'll get the database server to do any heavy processing ... and that may well be a different machine ... I just want the results. So I try to avoid pulling unnecessary data into the PHP side - I can only put so much on a client page. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory management ...
On Thu, Aug 4, 2011 at 12:17 PM, Lester Caine les...@lsces.co.uk wrote: I'm still trying to get my head around this 'Weak Reference' thing, but since I'm still working to be compatible with PHP5.2 then I've not taken much notice of this 'garbage collection' stuff. So this may be where I am missing something? I manage what material I need using a list of numbers, and create objects as and when they are required, pulling the detail from the database. There is a limit on the amount of memory available, so in the past I got 'out of memory', now I just say 'some detail not available'. If I'm out of space, then I reuse an existing object that is 'invalid', but to simplify things then much of the time I don't ACTUALLY need the full record, and simply build the page via the one object which is sequentially loaded ... slower, but memory efficient. Never do 'SELECT * FROM', always specify just the fields you need at that time. So it looks like the question I should be asking is How do you 'drop' an object? I think my take on this 'Weak Reference' stuff is that it does not actually 'create' the object? But I am creating the object because I need to use it, not because I may need it later? I'll get the database server to do any heavy processing ... and that may well be a different machine ... I just want the results. So I try to avoid pulling unnecessary data into the PHP side - I can only put so much on a client page. if you unset a variable, the zval's refcount for that variable will be decreased by one. if the refcount reach zero, the zval will be freed. http://www.php.net/manual/en/features.gc.refcounting-basics.php this was also before 5.3 the new feature in 5.3 however you can fix the memory leaks that happened because of the circular references: http://www.php.net/manual/en/features.gc.collecting-cycles.php a simple example for circular reference is basically when you have two zval, they both reference each other, so their refcount is one, so they cannot be freed, but they should been. this was addressed in 5.3, now the gc collector will traverse the zvals and find such islands and free them. so to address your question: if you unset your variables you can reclaim memory, but there could be edge cases, when you will memory leak before version 5.3. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.7 is there a RC5 coming soon?
On Wed, 2011-08-03 at 17:29 -0700, James Yu wrote: Thanks! Why do you need a 5th RC? Anything of importance changed? You want to get a patch in? Ilia, who thankfully took over this release, wrote in a mail about RC4: Given the small number of changes since the last RC, it is likely a final version will be released in 2 weeks. If it is not, a fourth release candidate will be available in 2 weeks. Please make us aware of critical issues. http://news.php.net/php.qa/65889 If you ignore the small mistake and replace by fourth with fifth that's the status. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Lazare Inepologlou wrote: Thank you for your interest. This is just a proposal that I have tested and works. Of course, the final syntax can be different. Syntax is always a matter of taste :-) As much as I love the idea, I have to agree that using | doesn't really make sense here and actually makes the readability worse, IMO. However, I can't really think of a better operator. ( $x ) = $x + 1 for example would be ambiguous if used in an array definition, but is otherwise the best in terms of readability. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory management ...
Ferenc Kovacs wrote: so to address your question: if you unset your variables you can reclaim memory, but there could be edge cases, when you will memory leak before version 5.3. So it looks like I'm not hitting any edge cases in the earlier code as some sites have been running for years without a reboot ... Must think about doing that sometime, running a windows server for 21 months without a reboot might be pushing luck :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
Lazare Inepologlou wrote:
Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)
As much as I love the idea, I have to agree that using | doesn't really
make sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) = $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.
If you go there you can also allow more complex statements and re-use
symbols used to group statements, using a syntax like
( $x ) { $x + 1; }
Oh wait - now we've reached a point which was mentioned in this thread
already allow to drop the function keyword.
Back when I proposed to drop function a key argument was that people
wanted an easy way to grep for function declarations. I accepted the
validity of that concern and think this might be a case here, too. The
difference of these few characters is not that much but the keyword
gives a clear guidance what's going on, else you might end up with a
long list of random characters next to each other ...
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
2011/8/4 Lazare Inepologlou linep...@gmail.com:
Hello everyone.
I am new to the php-internals list. I have joined because I have
implemented a feature that I would like to be included in the php
language: a shorter syntax for lambdas. I am going to briefly present
it here. Apologies for the long (and yet incomplete) e-mail. I am
ready to write a more complete RFC in the wiki, however, I would
appreciate having some directions for that. Do I have to ask for
permission first? Is it open to anyone to submit an RFC?
The stuff...
Absolutely against such a syntax. Just try to imagine that you have to
actually not only write code, but you have to edit it and it can be
written by someone else.
The syntax we have right now is a bit wordy (is there such a word? :)
), but it makes code easily readable and formatted. Consider
JavaScript - it has function keyword for lambdas and no one is
complaining. Besides it lets you to indent your code beautifully:
$a-select(function($x) {
return $x-getName();
});
Or like this:
call_some_function(
$param1,
$param2
function ($x, $y) {
return $x * $y;
}
);
And so on.
If you write it in one line - it will become ugly one way or other no
matter the syntax.
Just make a Live Template (or whatever it's called in your IDE) for
somethink like labd = function (#vars#) { #body } for auto-complete
and be happy.
Is PHP still going the KISS way? PHP does not have different syntax's
for same things except few exceptions witch make sense and didn't
allowed such additions in the past. Please, can I ask the core team to
stay on the same line in the future :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
Oh, and I forgot one more thing: As I read the internals, I noticed many times that PHP lexer is somewhat limited in it's capabilities and sometimes the features are dropped because of this issue. It can be the case that the can be ambiguous and it will be just impossible to add at this stage. As Ryan McCue pointed out in his example - there can be a problem with arrays. And so on. Use cases are not just limited to declaring a lambda as a function callback or assigning it to a variable. Creatinx syntax that just looks odd for the language like those | probably will not be accepted by the community because it looks out of place. my 2 cents -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 09:17, schrieb Stas Malyshev: I'm sorry but you putting forth contradictory requirements here - you want to keep the objects (to avoid expensively reconstructing them) and you don't want to keep them (memory problems). You'll have to give up one of these requirements. As I see, you gave up the caching requirement and you clean up objects when memory is tight. As long as you don't need more objects than you have memory you should be fine. As long as memory is infinite I'd be fine. It's not contradictory at all. I have to balance performance gain (keeping objects in memory) and memory usage (keeping too many objects out of memory). You should control your code so that somewhere else does not keep extra references. As well as you'd have to control you code if you use weak refs, otherwise extra references would still keep objects alive - or you'd have to rewrite your code and control it so that is always uses weak refs and always checks that the ref is alive. Not true. With WeakReferences, objects would be cleaned from memory as soon as my cache-list is the only place left still referencing it and the GC is run. Even better would be SoftReferences, which would only be cleaned when there is no memory left. Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. This is like saying: do not use objects at all and use the DB for storage. verbosity and slowness is something I'd like to prevent. I did not mean to defend WeakReferences, I just meant to give a valid use case. Your saying that I shouldn't do it doesn't help much. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
... ( $x ) = $x + 1 for example would be ambiguous if used in an array
definition, but is otherwise the best in terms of readability.
... people wanted an easy way to grep for function declarations
A new and unique operator (like the |= I have proposed) is a solution
that works because:
1. A lambda expression can be part of other expressions, like arrays.
Therefore, we cannot reuse =, or -.
2. Multiple lambda expressions can be chained. The operator must have
very low precedence and it be right associative.
3. Lambdas should be grep-able.
For those who would like to try other syntaxes that could work in PHP,
I suggest a simple and creative way to approach this. All we need is 3
operators:
OP_A args OP_B lexical_vars OP_C expr
Operator OP_C ought to have the above properties (unique, low
precedence, right associative). On the other hand there are no
restrictions about OP_A and OP_B and we can reuse existing ones as
long as they don't conflict and they look nice.
:-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2011/8/4 Johannes Schlüter johan...@schlueters.de:
On Thu, 2011-08-04 at 21:18 +1000, Ryan McCue wrote:
Lazare Inepologlou wrote:
Thank you for your interest. This is just a proposal that I have tested and
works. Of course, the final syntax can be different. Syntax is always a
matter of taste :-)
As much as I love the idea, I have to agree that using | doesn't really
make sense here and actually makes the readability worse, IMO. However,
I can't really think of a better operator. ( $x ) = $x + 1 for example
would be ambiguous if used in an array definition, but is otherwise the
best in terms of readability.
If you go there you can also allow more complex statements and re-use
symbols used to group statements, using a syntax like
( $x ) { $x + 1; }
Oh wait - now we've reached a point which was mentioned in this thread
already allow to drop the function keyword.
Back when I proposed to drop function a key argument was that people
wanted an easy way to grep for function declarations. I accepted the
validity of that concern and think this might be a case here, too. The
difference of these few characters is not that much but the keyword
gives a clear guidance what's going on, else you might end up with a
long list of random characters next to each other ...
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On 08/04/2011 04:39 PM, Lazare Inepologlou wrote: ... ( $x ) = $x + 1 for example would be ambiguous if used in an array definition, but is otherwise the best in terms of readability. ... people wanted an easy way to grep for function declarations A new and unique operator (like the |= I have proposed) is a solution that works because: Please stop that, it's not funny anymore. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
+1 - think everybody'd want their functions to be searchable and searching for complex patterns like (function)|(\|\=\) would really be a headache. Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic? 2011/8/4 Antony Dovgal t...@daylessday.org On 08/04/2011 04:39 PM, Lazare Inepologlou wrote: ... ( $x ) = $x + 1 for example would be ambiguous if used in an array definition, but is otherwise the best in terms of readability. ... people wanted an easy way to grep for function declarations A new and unique operator (like the |= I have proposed) is a solution that works because: Please stop that, it's not funny anymore. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On Thu, 4 Aug 2011, Victor Bolshov wrote: Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic? No. I don't see at all why we need this, just like I don't see why we needed an alternative (short) syntax for arrays. This kind of syntax additions that add *no* functionality, should not be in PHP. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On 08/04/2011 05:04 PM, Derick Rethans wrote: On Thu, 4 Aug 2011, Victor Bolshov wrote: Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic? No. I don't see at all why we need this, just like I don't see why we needed an alternative (short) syntax for arrays. This kind of syntax additions that add *no* functionality, should not be in PHP. Yes, I believe we should stop this stream of alternative syntax proposals and concentrate on fixing existing functionality instead of adding less readable ways to do the same thing. I would really like to keep PHP code easily readable, not to turn it into perl-ish write-only gibberish. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory management ...
On Thu, 2011-08-04 at 12:36 +0100, Lester Caine wrote: Ferenc Kovacs wrote: so to address your question: if you unset your variables you can reclaim memory, but there could be edge cases, when you will memory leak before version 5.3. So it looks like I'm not hitting any edge cases in the earlier code as some sites have been running for years without a reboot ... Must think about doing that sometime, running a windows server for 21 months without a reboot might be pushing luck :) PHP frees memory forcefully on request end as good as it can (which is quite good) but sometimes a request takes a lot of memory and some people try to reduce that. johannes -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.7 is there a RC5 coming soon?
Unless something changes, I think we are going to go from RC4 to final release. On Wed, Aug 3, 2011 at 8:29 PM, James Yu jym2...@gmail.com wrote: Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fix imap_mail actually use the rpath option
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+char *sendmail_path = INI_STR(sendmail_path);
+char *appended_sendmail_path = NULL;
+
+/** Return Path or not **/
+if (rpath rpath[0]) {
+appended_sendmail_path = emalloc(
+strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+strcpy(appended_sendmail_path, sendmail_path);
+strcat(appended_sendmail_path, -f);
+strcat(appended_sendmail_path, rpath);
+sendmail_path = appended_sendmail_path;
+}
+
+/** open the sendmail pointer **/
+sendmail = popen(sendmail_path, w); /* New Code */
+
+ if (appended_sendmail_path)
+efree(appended_sendmail_path);
+
if (sendmail) {
if (rpath rpath[0]) fprintf(sendmail, From: %s\n,
rpath);
fprintf(sendmail, To: %s\n, to);
hopefully that will work to fix the rpath option, and finally close this
bug http://bugs.php.net/bug.php?id=30688
Re: [PHP-DEV] [PATCH] fix imap_mail actually use the rpath option
hi,
Can you attach this patch to the bug please?
Thanks for your work!
On Thu, Aug 4, 2011 at 5:30 PM, Keloran ava...@gmail.com wrote:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+ char *sendmail_path = INI_STR(sendmail_path);
+ char *appended_sendmail_path = NULL;
+
+ /** Return Path or not **/
+ if (rpath rpath[0]) {
+ appended_sendmail_path = emalloc(
+ strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+ strcpy(appended_sendmail_path, sendmail_path);
+ strcat(appended_sendmail_path, -f);
+ strcat(appended_sendmail_path, rpath);
+ sendmail_path = appended_sendmail_path;
+ }
+
+ /** open the sendmail pointer **/
+ sendmail = popen(sendmail_path, w); /* New Code */
+
+ if (appended_sendmail_path)
+ efree(appended_sendmail_path);
+
if (sendmail) {
if (rpath rpath[0]) fprintf(sendmail, From: %s\n,
rpath);
fprintf(sendmail, To: %s\n, to);
hopefully that will work to fix the rpath option, and finally close this
bug http://bugs.php.net/bug.php?id=30688
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
From your blog post: All in all, I have tried to eliminate the syntax noise by reducing the key strokes in the the non-significant parts of the expression is typing time really the bottleneck for productivity Is typing really the bottleneck for developers these days? I must suck then. I spend most of my day thinking or waiting on version control, testing and deploy applications, not typing. Brian. http://brian.moonspot.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix imap_mail actually use the rpath option
patch attached
On Thu, Aug 4, 2011 at 4:39 PM, Pierre Joye pierre@gmail.com wrote:
hi,
Can you attach this patch to the bug please?
Thanks for your work!
On Thu, Aug 4, 2011 at 5:30 PM, Keloran ava...@gmail.com wrote:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+char *sendmail_path = INI_STR(sendmail_path);
+char *appended_sendmail_path = NULL;
+
+/** Return Path or not **/
+if (rpath rpath[0]) {
+appended_sendmail_path = emalloc(
+strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+strcpy(appended_sendmail_path, sendmail_path);
+strcat(appended_sendmail_path, -f);
+strcat(appended_sendmail_path, rpath);
+sendmail_path = appended_sendmail_path;
+}
+
+/** open the sendmail pointer **/
+sendmail = popen(sendmail_path, w); /* New Code */
+
+ if (appended_sendmail_path)
+efree(appended_sendmail_path);
+
if (sendmail) {
if (rpath rpath[0]) fprintf(sendmail, From: %s\n,
rpath);
fprintf(sendmail, To: %s\n, to);
hopefully that will work to fix the rpath option, and finally close this
bug http://bugs.php.net/bug.php?id=30688
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: json_encode option for not escaping unnecessary character
I write to omar (ext author) and scottmac (bug owner) and not received a reply from they. Can someone else check this patch, please? With regards, Alexander Moskaliov ir...@irker.net 2011/7/25 Александр Москалёв ir...@irker.net: Hello. Can someone check my patch in this request https://bugs.php.net/bug.php?id=53946 ? It would be nice to see it in PHP 5.4 . If a question arises why this is necessary, then see my comments on this bug. Thanks in advance. With respect, Alexander Moskaliov ir...@irker.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix imap_mail actually use the rpath option
I have now attached the patch to the issue:
https://bugs.php.net/bug.php?id=30688
On Thu, Aug 4, 2011 at 6:07 PM, Keloran ava...@gmail.com wrote:
patch attached
On Thu, Aug 4, 2011 at 4:39 PM, Pierre Joye pierre@gmail.com wrote:
hi,
Can you attach this patch to the bug please?
Thanks for your work!
On Thu, Aug 4, 2011 at 5:30 PM, Keloran ava...@gmail.com wrote:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+ char *sendmail_path = INI_STR(sendmail_path);
+ char *appended_sendmail_path = NULL;
+
+ /** Return Path or not **/
+ if (rpath rpath[0]) {
+ appended_sendmail_path = emalloc(
+ strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+ strcpy(appended_sendmail_path, sendmail_path);
+ strcat(appended_sendmail_path, -f);
+ strcat(appended_sendmail_path, rpath);
+ sendmail_path = appended_sendmail_path;
+ }
+
+ /** open the sendmail pointer **/
+ sendmail = popen(sendmail_path, w); /* New Code */
+
+ if (appended_sendmail_path)
+ efree(appended_sendmail_path);
+
if (sendmail) {
if (rpath rpath[0]) fprintf(sendmail, From: %s\n,
rpath);
fprintf(sendmail, To: %s\n, to);
hopefully that will work to fix the rpath option, and finally close this
bug http://bugs.php.net/bug.php?id=30688
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix imap_mail actually use the rpath option
cool, thanks
that patch is for 5.4 (since the line nums changed from 5.3-5.4,
On Thu, Aug 4, 2011 at 5:19 PM, Pierre Joye pierre@gmail.com wrote:
I have now attached the patch to the issue:
https://bugs.php.net/bug.php?id=30688
On Thu, Aug 4, 2011 at 6:07 PM, Keloran ava...@gmail.com wrote:
patch attached
On Thu, Aug 4, 2011 at 4:39 PM, Pierre Joye pierre@gmail.com
wrote:
hi,
Can you attach this patch to the bug please?
Thanks for your work!
On Thu, Aug 4, 2011 at 5:30 PM, Keloran ava...@gmail.com wrote:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+char *sendmail_path = INI_STR(sendmail_path);
+char *appended_sendmail_path = NULL;
+
+/** Return Path or not **/
+if (rpath rpath[0]) {
+appended_sendmail_path = emalloc(
+strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+strcpy(appended_sendmail_path, sendmail_path);
+strcat(appended_sendmail_path, -f);
+strcat(appended_sendmail_path, rpath);
+sendmail_path = appended_sendmail_path;
+}
+
+/** open the sendmail pointer **/
+sendmail = popen(sendmail_path, w); /* New Code */
+
+ if (appended_sendmail_path)
+efree(appended_sendmail_path);
+
if (sendmail) {
if (rpath rpath[0]) fprintf(sendmail, From: %s\n,
rpath);
fprintf(sendmail, To: %s\n, to);
hopefully that will work to fix the rpath option, and finally close
this
bug http://bugs.php.net/bug.php?id=30688
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DEV] 5.3.7 is there a RC5 coming soon?
I found there's critical bug fixed after RC4 https://bugs.php.net/bug.php?id=55356 SSL didn't work properly in RC4. Thanks, James On Thu, Aug 4, 2011 at 7:10 AM, Ilia Alshanetsky i...@prohost.org wrote: Unless something changes, I think we are going to go from RC4 to final release. On Wed, Aug 3, 2011 at 8:29 PM, James Yu jym2...@gmail.com wrote: Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hi! On 8/4/11 5:34 AM, Lars Schultz wrote: Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. This is like saying: do not use objects at all and use the DB for storage. verbosity and slowness is something I'd like to prevent. No, it's not even remotely like that. Using one intermediary function and doing the DB call is orders of magnitude apart. You asked how you can solve the problem, I showed you how. You can claim you don't like the solution, that's fine, everybody has his own taste. But you can't claim there's no other solution. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix imap_mail actually use the rpath option
Hi,
few comments just from reading the patch, not the full context, not
testing it:
On Thu, 2011-08-04 at 16:30 +0100, Keloran wrote:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+char *sendmail_path = INI_STR(sendmail_path);
+char *appended_sendmail_path = NULL;
This won't work on all compiles, declarations have to go first in the
block.
+/** Return Path or not **/
+if (rpath rpath[0]) {
+appended_sendmail_path = emalloc(
+strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+strcpy(appended_sendmail_path, sendmail_path);
+strcat(appended_sendmail_path, -f);
+strcat(appended_sendmail_path, rpath);
+sendmail_path = appended_sendmail_path;
+}
+
+/** open the sendmail pointer **/
+sendmail = popen(sendmail_path, w); /* New Code */
How do you open a pointer ;-)
I think everybody reading the code should know popen() so the first
comment isn't really useful; I assume the second comment there was for
your purpose.
+ if (appended_sendmail_path)
+efree(appended_sendmail_path);
+
Always use { } even for a single line (see CODING_STANDARDS)
While editing this functions: Should this function not also respect the
new mail.force_extra_parameters and mail.log settings, too? (Might need
an extra bug report to be reported correctly ...)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: json_encode option for not escaping unnecessary character
Never got the email, will look today at it. Doesn't quite match our coding standards from the first glance. S On 4 Aug 2011, at 09:17, Александ Москалёвir...@irker.net wrote: I write to omar (ext author) and scottmac (bug owner) and not received a reply from they. Can someone else check this patch, please? With regards, Alexander Moskaliov ir...@irker.net 2011/7/25 Александр Москалёв ir...@irker.net: Hello. Can someone check my patch in this request https://bugs.php.net/bug.php?id=53946 ? It would be nice to see it in PHP 5.4 . If a question arises why this is necessary, then see my comments on this bug. Thanks in advance. With respect, Alexander Moskaliov ir...@irker.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Am 04.08.2011 18:35, schrieb Stas Malyshev: No, it's not even remotely like that. Using one intermediary function and doing the DB call is orders of magnitude apart. You asked how you can solve the problem, I showed you how. You can claim you don't like the solution, that's fine, everybody has his own taste. But you can't claim there's no other solution. Right. I don't like doing design-stuff how they do it in java either, but a little bit of it hasn't hurt anybody, and it's conciseness helps readability alot. I am sure you understand the problem quite well but it's not one of yours, obviously. That's fine too. But you can't claim the use-case is not valid. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3.7 is there a RC5 coming soon?
This seems to be a build, not an code issue. So this should be fixed by a build independently from RC or final. Pierre can confirm. johannes On Thu, 2011-08-04 at 09:36 -0700, James Yu wrote: I found there's critical bug fixed after RC4 https://bugs.php.net/bug.php?id=55356 SSL didn't work properly in RC4. Thanks, James On Thu, Aug 4, 2011 at 7:10 AM, Ilia Alshanetsky i...@prohost.org wrote: Unless something changes, I think we are going to go from RC4 to final release. On Wed, Aug 3, 2011 at 8:29 PM, James Yu jym2...@gmail.com wrote: Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RSS channel or maillist for bugs
Hi All. I can't find RSS channel or maillist for https://bugs.php.net. If it exists?
[PHP-DEV] Re: [PATCH] fix imap_mail actually use the rpath option
Yeah it does need cleaning up, didn't know about the new mail options,
main reason I did it was because the function has had the option since
2004, but it's never actually used it
On Thursday, August 4, 2011, Johannes Schlüter johan...@schlueters.de wrote:
Hi,
few comments just from reading the patch, not the full context, not
testing it:
On Thu, 2011-08-04 at 16:30 +0100, Keloran wrote:
Index: ext/imap/php_imap.c
===
--- ext/imap/php_imap.c (revision 314217)
+++ ext/imap/php_imap.c (working copy)
@@ -4016,7 +4016,27 @@
if (!INI_STR(sendmail_path)) {
return 0;
}
- sendmail = popen(INI_STR(sendmail_path), w);
+
+ /** Used to make return-path work **/
+ char *sendmail_path = INI_STR(sendmail_path);
+ char *appended_sendmail_path = NULL;
This won't work on all compiles, declarations have to go first in the
block.
+ /** Return Path or not **/
+ if (rpath rpath[0]) {
+ appended_sendmail_path = emalloc(
+ strlen(sendmail_path) + 3 + strlen(rpath) + 1);
+ strcpy(appended_sendmail_path, sendmail_path);
+ strcat(appended_sendmail_path, -f);
+ strcat(appended_sendmail_path, rpath);
+ sendmail_path = appended_sendmail_path;
+ }
+
+ /** open the sendmail pointer **/
+ sendmail = popen(sendmail_path, w); /* New Code */
How do you open a pointer ;-)
I think everybody reading the code should know popen() so the first
comment isn't really useful; I assume the second comment there was for
your purpose.
+ if (appended_sendmail_path)
+ efree(appended_sendmail_path);
+
Always use { } even for a single line (see CODING_STANDARDS)
While editing this functions: Should this function not also respect the
new mail.force_extra_parameters and mail.log settings, too? (Might need
an extra bug report to be reported correctly ...)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RSS channel or maillist for bugs
On Thu, Aug 4, 2011 at 6:51 PM, Sokolov Evgeniy ewg...@gmail.com wrote: Hi All. I can't find RSS channel or maillist for https://bugs.php.net. If it exists? the general mailing list for bugs is php-b...@lists.php.net the rss feed for it is http://news.php.net/group.php?group=php.bugsformat=rss some bugs goes other lists like: http://news.php.net/php.doc.bugs http://news.php.net/php.pear.bugs http://news.php.net/php.webmaster http://news.php.net/php.pecl.dev you can see the list of the mailing lists here: http://news.php.net/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: json_encode option for not escaping unnecessary character
Hi, Scott. I wrote you on scott...@php.net. This patch - my first work on C language. I write it becouse people advised me write patch for fast feature adding. I also tried add minimal changes. If you spend a little time to check and fix my patch, I would be very thankful to you. With regards, Alexander Moskaliov ir...@irker.net 2011/8/4 Scott MacVicar sc...@macvicar.net: Never got the email, will look today at it. Doesn't quite match our coding standards from the first glance. S On 4 Aug 2011, at 09:17, Александ Москалёвir...@irker.net wrote: I write to omar (ext author) and scottmac (bug owner) and not received a reply from they. Can someone else check this patch, please? With regards, Alexander Moskaliov ir...@irker.net 2011/7/25 Александр Москалёв ir...@irker.net: Hello. Can someone check my patch in this request https://bugs.php.net/bug.php?id=53946 ? It would be nice to see it in PHP 5.4 . If a question arises why this is necessary, then see my comments on this bug. Thanks in advance. With respect, Alexander Moskaliov ir...@irker.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On Thu, Aug 4, 2011 at 09:12, Antony Dovgal t...@daylessday.org wrote:
Btw, am I the only one to whom the proposed syntax seems kinda
hieroglyphic?
No. I don't see at all why we need this, just like I don't see why we
needed an alternative (short) syntax for arrays. This kind of syntax
additions that add *no* functionality, should not be in PHP.
Yes, I believe we should stop this stream of alternative syntax proposals
and concentrate on fixing existing functionality instead of adding less
readable ways to do
the same thing. I would really like to keep PHP code easily readable, not to
turn it into
perl-ish write-only gibberish.
100% agreed, both about the cryptic nature of the proposed syntax and
the need to focus on fixing existing issues. Strong -1 on a new
syntax.
The current PHP syntax for closures is the second-best one I've ever
used, IMHO. Clear, readable, explicit. My all-time favorite syntax is
that favored by Objective-C:
^ [returntype] ([params]) { code; }
The compiler figures out at build time which lexical stuff to capture,
and in most cases can infer the optional return type. I'd kinda love a
^ (params) use (captures) { code; } syntax in PHP, but nothing any
less wordy than that, and I'd hardly consider it any kind of priority.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An implementation of a short syntax for closures
On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind gwy...@darkrainfall.orgwrote: On Thu, Aug 4, 2011 at 09:12, Antony Dovgal t...@daylessday.org wrote: Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic? No. I don't see at all why we need this, just like I don't see why we needed an alternative (short) syntax for arrays. This kind of syntax additions that add *no* functionality, should not be in PHP. Yes, I believe we should stop this stream of alternative syntax proposals and concentrate on fixing existing functionality instead of adding less readable ways to do the same thing. I would really like to keep PHP code easily readable, not to turn it into perl-ish write-only gibberish. 100% agreed, both about the cryptic nature of the proposed syntax and the need to focus on fixing existing issues. Strong -1 on a new syntax. Aye, just realized watching the |= reminded me of perl... say, I think that is what an aneurysm feels like.
Re: [PHP-DEV] An implementation of a short syntax for closures
On Thu, Aug 4, 2011 at 7:54 PM, dukeofgaming dukeofgam...@gmail.com wrote: On Thu, Aug 4, 2011 at 1:47 PM, Gwynne Raskind gwy...@darkrainfall.orgwrote: On Thu, Aug 4, 2011 at 09:12, Antony Dovgal t...@daylessday.org wrote: Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic? No. I don't see at all why we need this, just like I don't see why we needed an alternative (short) syntax for arrays. This kind of syntax additions that add *no* functionality, should not be in PHP. Yes, I believe we should stop this stream of alternative syntax proposals and concentrate on fixing existing functionality instead of adding less readable ways to do the same thing. I would really like to keep PHP code easily readable, not to turn it into perl-ish write-only gibberish. 100% agreed, both about the cryptic nature of the proposed syntax and the need to focus on fixing existing issues. Strong -1 on a new syntax. Aye, just realized watching the |= reminded me of perl... say, I think that is what an aneurysm feels like. One of the downsides to a language like perl was its Readability, fancy magic symbols and lack of readability in its source code. PHP has the opposite, very clear and readable C-like code. If PHP moves towards a more magic syntax language then it would be counter-productive. Closures are quirky enough to wrap your eyes/mind around. Making these more cryptic is very counter-productive. Like mentioned, the amount of typing is not a problem, its more so waiting on things to transfer, commit..etc Very big -1 for me on this one. Please don't let a plethora of PHP devs release code with this syntax. Regards, Paul Dragoonis. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: An implementation of a short syntax for closures
Hello PHP Internals,
This is my first message to the list. I've been reading via the archive
since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
loving the new stuff)
Up until now I haven't had anything to say that wasn't already being
talked about, but the topic of short hand syntax is of particular
interest to me.
Before I start, I think I need to make clear that I am in general not a
fan of making cryptic code (ala perl). I tend to use long descriptive
variable names and try to make my code easy to read so that comments
aren't usually necessary.
Saying that though, I am a big supporter of the new short hand array
syntax. From a grammatical point of view, I see no reason why my code
needs to be scattered with the word 'array'. The simple square brackets
['a'='b'] I find just as easy to understand and they don't confuse me.
(unlike something along the lines of regex, that can easily confuse).
I see the desire to wanting to remove the word function as a similar
issue. When you use inline functions a lot, your code is filled with
lots of the word 'function'. This word doesn't necessarily need to be
there for your code still to make sense.
Also, on a similar vein of thought, if your function is only doing
something small, why do we need to put the word 'return' in there?
I have been thinking of what syntax(s) could work to shorten the code
but not to make the code confusing. I am splitting up my ideas in to
separate sections. I think that if a short-hand function syntax is to be
accepted, it should be useful in many circumstances - eg, it shouldn't
necessarily be limited to one liners.
Okay, here is a base example:
$modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
1) REMOVING THE WORD 'function':
One solution is to simply remove the word function completely:
$modify = ( $x )use($my_constant ){ return $x + $my_constant; };
On first glance, to me, this doesn't look like I'm starting to write a
function. I could perhaps be opening a bracket to do some maths. So,
what could be done to make it more obvious? I suggest using a character
to represent function. Personally I like colon:
$modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
Now, I know this doesn't immediately scream function, but it is a
different/specific syntax which should hopefully lead to less confusion.
2) REMOVING THE WORD 'return':
Okay, my function is still a bit wordy for what it's doing. How do we
remove return? I quite like the use of = that has been suggested in
previous posts.
$modify = :( $x )use( $my_constant )= $x + $my_constant;
3) REMOVING THE WORD 'use':
Personally I don't think use is causing a problem, I find it helps the
grammar of this function. If it was to go though, it could be replaced
with something like a colon:
$modify = :( $x : $my_constant )= $x + $my_constant;
Is this going too far? Is it now too cryptic?
4) REMOVING THE BRACKETS?
In lots of the examples of short hand closures in other languages there
are no brackets. I think that might be going too far, but perhaps not:
$modify = : $x : $my_constant = $x + $my_constant;
Too much! This line simply confuses me!
OTHER EXAMPLES
So, personally I don't think shortening needs to go as far as 3 or 4.
But, I am a fan of 1 and 2.
To demonstrate more how this might look, I'm using the code examples
Lazare used in his original post:
// Mapping:
$a-select( function($x){ return $x-getName(); } );
// Filtering:
$a-where( function($x)use($y){ return $x==$y; } );
// Currying:
$add = function($x){ return function($y)use($x){ return $x+$y; }; };
With my examples of shortening, these become:
// Mapping:
$a-select( :($x)= $x-getName() );
// Filtering:
$a-where( :($x)use($y)= $x==$y );
// Currying:
$add = :($x)= :($y)use($x)=$x+$y ;
Hmm... I don't like my currying example, it's starting to boggle my
mind. How about:
$add = :($x)=( :($y)use($x)=$x+$y );
Much better.
Regardless of all of this, I actually don't find myself using too many
inline functions. (Not to the extent I was writing 'array' all over my
code anyway) - So I can't argue srongly about function shortening making
it's way in to PHP.
Perhaps once we're all using inline functions on every other line of our
code there'll be a bigger demand for it!
Best regards,
Jezz Goodwin
[PHP-DEV] Re: An implementation of a short syntax for closures
On 2011-08-04, Jezz Goodwin jez...@officechristmas.co.uk wrote:
--060805070009050707030403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello PHP Internals,
This is my first message to the list. I've been reading via the archive
since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
loving the new stuff)
Up until now I haven't had anything to say that wasn't already being
talked about, but the topic of short hand syntax is of particular
interest to me.
Before I start, I think I need to make clear that I am in general not a
fan of making cryptic code (ala perl). I tend to use long descriptive
variable names and try to make my code easy to read so that comments
aren't usually necessary.
Saying that though, I am a big supporter of the new short hand array
syntax. From a grammatical point of view, I see no reason why my code
needs to be scattered with the word 'array'. The simple square brackets
['a'='b'] I find just as easy to understand and they don't confuse me.
(unlike something along the lines of regex, that can easily confuse).
I see the desire to wanting to remove the word function as a similar
issue. When you use inline functions a lot, your code is filled with
lots of the word 'function'. This word doesn't necessarily need to be
there for your code still to make sense.
Also, on a similar vein of thought, if your function is only doing
something small, why do we need to put the word 'return' in there?
Well, for one, it'd be a huge disconnect between the current behavior of
functions and the new syntax. In PHP, if you have no explicit return
in your function, a null is implicitly returned. If you were to change
this so that whatever the value of the last assignment or line was is
returned, we'd have a huge BC break -- even if this were only in
lambdas.
I agree that shorter notation is often nice as it allows the syntax to
get out of the way and potentially make code more readable. However,
that's true only to a point -- if you go too far in the opposite
direction, you end up with code that's unreadable as you have to inject
context. I personally feel the proposed (by the original poster) lambda
syntax falls in this category -- I found it _more_ difficult to
understand the execution flow, and I suspect this was in large part
because it stopped resembling traditional PHP syntax.
Of the syntax changes you propose below, the only one that seems like it
retains readability to me is the very first -- and even that one, I
suspect, would cause some issues for the lexer.
I have been thinking of what syntax(s) could work to shorten the code
but not to make the code confusing. I am splitting up my ideas in to
separate sections. I think that if a short-hand function syntax is to be
accepted, it should be useful in many circumstances - eg, it shouldn't
necessarily be limited to one liners.
Okay, here is a base example:
$modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
1) REMOVING THE WORD 'function':
One solution is to simply remove the word function completely:
$modify = ( $x )use($my_constant ){ return $x + $my_constant; };
On first glance, to me, this doesn't look like I'm starting to write a
function. I could perhaps be opening a bracket to do some maths. So,
what could be done to make it more obvious? I suggest using a character
to represent function. Personally I like colon:
$modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
Now, I know this doesn't immediately scream function, but it is a
different/specific syntax which should hopefully lead to less confusion.
2) REMOVING THE WORD 'return':
Okay, my function is still a bit wordy for what it's doing. How do we
remove return? I quite like the use of = that has been suggested in
previous posts.
$modify = :( $x )use( $my_constant )= $x + $my_constant;
3) REMOVING THE WORD 'use':
Personally I don't think use is causing a problem, I find it helps the
grammar of this function. If it was to go though, it could be replaced
with something like a colon:
$modify = :( $x : $my_constant )= $x + $my_constant;
Is this going too far? Is it now too cryptic?
4) REMOVING THE BRACKETS?
In lots of the examples of short hand closures in other languages there
are no brackets. I think that might be going too far, but perhaps not:
$modify = : $x : $my_constant = $x + $my_constant;
Too much! This line simply confuses me!
OTHER EXAMPLES
So, personally I don't think shortening needs to go as far as 3 or 4.
But, I am a fan of 1 and 2.
To demonstrate more how this might look, I'm using the code examples
Lazare used in his original post:
// Mapping:
$a-select( function($x){ return $x-getName(); } );
// Filtering:
$a-where( function($x)use($y){ return $x==$y; } );
// Currying:
$add = function($x){ return function($y)use($x){ return
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
On 04/08/2011 21:00, Matthew Weier O'Phinney wrote:
On 2011-08-04, Jezz Goodwinjez...@officechristmas.co.uk wrote:
--060805070009050707030403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello PHP Internals,
This is my first message to the list. I've been reading via the archive
since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
loving the new stuff)
Up until now I haven't had anything to say that wasn't already being
talked about, but the topic of short hand syntax is of particular
interest to me.
Before I start, I think I need to make clear that I am in general not a
fan of making cryptic code (ala perl). I tend to use long descriptive
variable names and try to make my code easy to read so that comments
aren't usually necessary.
Saying that though, I am a big supporter of the new short hand array
syntax. From a grammatical point of view, I see no reason why my code
needs to be scattered with the word 'array'. The simple square brackets
['a'='b'] I find just as easy to understand and they don't confuse me.
(unlike something along the lines of regex, that can easily confuse).
I see the desire to wanting to remove the word function as a similar
issue. When you use inline functions a lot, your code is filled with
lots of the word 'function'. This word doesn't necessarily need to be
there for your code still to make sense.
Also, on a similar vein of thought, if your function is only doing
something small, why do we need to put the word 'return' in there?
Well, for one, it'd be a huge disconnect between the current behavior of
functions and the new syntax. In PHP, if you have no explicit return
in your function, a null is implicitly returned. If you were to change
this so that whatever the value of the last assignment or line was is
returned, we'd have a huge BC break -- even if this were only in
lambdas.
I wasn't suggesting this to be the default action for functions /
lambdas. You would have to specify that you wanted to return using = Eg:
:($x)=$x+1;
returns $x + 1. where as:
:($x){ $x+1; }
still returns null
I agree that shorter notation is often nice as it allows the syntax to
get out of the way and potentially make code more readable. However,
that's true only to a point -- if you go too far in the opposite
direction, you end up with code that's unreadable as you have to inject
context. I personally feel the proposed (by the original poster) lambda
syntax falls in this category -- I found it _more_ difficult to
understand the execution flow, and I suspect this was in large part
because it stopped resembling traditional PHP syntax.
Of the syntax changes you propose below, the only one that seems like it
retains readability to me is the very first -- and even that one, I
suspect, would cause some issues for the lexer.
I have been thinking of what syntax(s) could work to shorten the code
but not to make the code confusing. I am splitting up my ideas in to
separate sections. I think that if a short-hand function syntax is to be
accepted, it should be useful in many circumstances - eg, it shouldn't
necessarily be limited to one liners.
Okay, here is a base example:
$modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
1) REMOVING THE WORD 'function':
One solution is to simply remove the word function completely:
$modify = ( $x )use($my_constant ){ return $x + $my_constant; };
On first glance, to me, this doesn't look like I'm starting to write a
function. I could perhaps be opening a bracket to do some maths. So,
what could be done to make it more obvious? I suggest using a character
to represent function. Personally I like colon:
$modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
Now, I know this doesn't immediately scream function, but it is a
different/specific syntax which should hopefully lead to less confusion.
2) REMOVING THE WORD 'return':
Okay, my function is still a bit wordy for what it's doing. How do we
remove return? I quite like the use of = that has been suggested in
previous posts.
$modify = :( $x )use( $my_constant )= $x + $my_constant;
3) REMOVING THE WORD 'use':
Personally I don't think use is causing a problem, I find it helps the
grammar of this function. If it was to go though, it could be replaced
with something like a colon:
$modify = :( $x : $my_constant )= $x + $my_constant;
Is this going too far? Is it now too cryptic?
4) REMOVING THE BRACKETS?
In lots of the examples of short hand closures in other languages there
are no brackets. I think that might be going too far, but perhaps not:
$modify = : $x : $my_constant = $x + $my_constant;
Too much! This line simply confuses me!
OTHER EXAMPLES
So, personally I don't think shortening needs to go as far as 3 or 4.
But, I am a fan of 1 and 2.
To demonstrate more how this might look, I'm using the code examples
Lazare used in his original post:
// Mapping:
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
Just two examples, why I think, this is a not a good idea. Simple typos
can produce hard to track errors. Its just confusing
$x = 4;
$y = ($x);{
return $x*2;
}
// and
$x = 4;
$x = ($x)
{
$y = $x*2;
}
On 04.08.2011 21:52, Jezz Goodwin wrote:
Hello PHP Internals,
This is my first message to the list. I've been reading via the archive
since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
loving the new stuff)
Up until now I haven't had anything to say that wasn't already being
talked about, but the topic of short hand syntax is of particular
interest to me.
Before I start, I think I need to make clear that I am in general not a
fan of making cryptic code (ala perl). I tend to use long descriptive
variable names and try to make my code easy to read so that comments
aren't usually necessary.
Saying that though, I am a big supporter of the new short hand array
syntax. From a grammatical point of view, I see no reason why my code
needs to be scattered with the word 'array'. The simple square brackets
['a'='b'] I find just as easy to understand and they don't confuse me.
(unlike something along the lines of regex, that can easily confuse).
I see the desire to wanting to remove the word function as a similar
issue. When you use inline functions a lot, your code is filled with
lots of the word 'function'. This word doesn't necessarily need to be
there for your code still to make sense.
Also, on a similar vein of thought, if your function is only doing
something small, why do we need to put the word 'return' in there?
I have been thinking of what syntax(s) could work to shorten the code
but not to make the code confusing. I am splitting up my ideas in to
separate sections. I think that if a short-hand function syntax is to be
accepted, it should be useful in many circumstances - eg, it shouldn't
necessarily be limited to one liners.
Okay, here is a base example:
$modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
1) REMOVING THE WORD 'function':
One solution is to simply remove the word function completely:
$modify = ( $x )use($my_constant ){ return $x + $my_constant; };
On first glance, to me, this doesn't look like I'm starting to write a
function. I could perhaps be opening a bracket to do some maths. So,
what could be done to make it more obvious? I suggest using a character
to represent function. Personally I like colon:
$modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
Now, I know this doesn't immediately scream function, but it is a
different/specific syntax which should hopefully lead to less confusion.
2) REMOVING THE WORD 'return':
Okay, my function is still a bit wordy for what it's doing. How do we
remove return? I quite like the use of = that has been suggested in
previous posts.
$modify = :( $x )use( $my_constant )= $x + $my_constant;
3) REMOVING THE WORD 'use':
Personally I don't think use is causing a problem, I find it helps the
grammar of this function. If it was to go though, it could be replaced
with something like a colon:
$modify = :( $x : $my_constant )= $x + $my_constant;
Is this going too far? Is it now too cryptic?
4) REMOVING THE BRACKETS?
In lots of the examples of short hand closures in other languages there
are no brackets. I think that might be going too far, but perhaps not:
$modify = : $x : $my_constant = $x + $my_constant;
Too much! This line simply confuses me!
OTHER EXAMPLES
So, personally I don't think shortening needs to go as far as 3 or 4.
But, I am a fan of 1 and 2.
To demonstrate more how this might look, I'm using the code examples
Lazare used in his original post:
// Mapping:
$a-select( function($x){ return $x-getName(); } );
// Filtering:
$a-where( function($x)use($y){ return $x==$y; } );
// Currying:
$add = function($x){ return function($y)use($x){ return $x+$y; }; };
With my examples of shortening, these become:
// Mapping:
$a-select( :($x)= $x-getName() );
// Filtering:
$a-where( :($x)use($y)= $x==$y );
// Currying:
$add = :($x)= :($y)use($x)=$x+$y ;
Hmm... I don't like my currying example, it's starting to boggle my
mind. How about:
$add = :($x)=( :($y)use($x)=$x+$y );
Much better.
Regardless of all of this, I actually don't find myself using too many
inline functions. (Not to the extent I was writing 'array' all over my
code anyway) - So I can't argue srongly about function shortening making
it's way in to PHP.
Perhaps once we're all using inline functions on every other line of our
code there'll be a bigger demand for it!
Best regards,
Jezz Goodwin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
In terms of thinking about typos, I'm sure there would be a solution to
making pretty robust short hand lambdas.
I think a more valid discussion would be whether PHP should have a short
hand lamda notation. A lot of talk on here is against there even being a
short-hand version, whatever syntax it is.
I'm really trying to continue the discussion in to coming up with a good
syntax everyone likes. If there is a good syntax maybe people against
the idea might change their opinion.
Personally I think it would be a good addition to the language. As other
people have pointed out, a lot of common languages have a syntax for
short hand lambdas. Also with the popularity of technologies such as
LinQ increasing, I can see small lambdas becoming more and more common.
In regards to typos, I don't think the following bit of code would be
too easy to put a typo in to?:
// Mapping:
$a-select( :($x)= $x-getName() );
On 04/08/2011 21:20, Sebastian Krebs wrote:
Just two examples, why I think, this is a not a good idea. Simple
typos can produce hard to track errors. Its just confusing
$x = 4;
$y = ($x);{
return $x*2;
}
// and
$x = 4;
$x = ($x)
{
$y = $x*2;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
Hi every one,
This message is also my first one. I've been following internals for few
weeks now.
I really don't think adding more short syntax would be a good idea, at least
this one.
PHP is a very popular language for many reasons, it's C-like, easy readable.
We all had to read some code made by others, most of the time without any
comment. Even with big and complicated code, keywords like function and
return help understanding because you can identify some parts of code
quickly.
Most of developpers use an IDE which use syntax colors and autocompletion so
that writing and analysing code is not a big deal. It wouldn't be that easy
if too many short syntax had been implemented.
All the given examples show closures with one instruction. It would be a
nightmare with more lines...
Jérémy Poulain
2011/8/4 Matthew Weier O'Phinney weierophin...@php.net
On 2011-08-04, Jezz Goodwin jez...@officechristmas.co.uk wrote:
--060805070009050707030403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello PHP Internals,
This is my first message to the list. I've been reading via the archive
since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
loving the new stuff)
Up until now I haven't had anything to say that wasn't already being
talked about, but the topic of short hand syntax is of particular
interest to me.
Before I start, I think I need to make clear that I am in general not a
fan of making cryptic code (ala perl). I tend to use long descriptive
variable names and try to make my code easy to read so that comments
aren't usually necessary.
Saying that though, I am a big supporter of the new short hand array
syntax. From a grammatical point of view, I see no reason why my code
needs to be scattered with the word 'array'. The simple square brackets
['a'='b'] I find just as easy to understand and they don't confuse me.
(unlike something along the lines of regex, that can easily confuse).
I see the desire to wanting to remove the word function as a similar
issue. When you use inline functions a lot, your code is filled with
lots of the word 'function'. This word doesn't necessarily need to be
there for your code still to make sense.
Also, on a similar vein of thought, if your function is only doing
something small, why do we need to put the word 'return' in there?
Well, for one, it'd be a huge disconnect between the current behavior of
functions and the new syntax. In PHP, if you have no explicit return
in your function, a null is implicitly returned. If you were to change
this so that whatever the value of the last assignment or line was is
returned, we'd have a huge BC break -- even if this were only in
lambdas.
I agree that shorter notation is often nice as it allows the syntax to
get out of the way and potentially make code more readable. However,
that's true only to a point -- if you go too far in the opposite
direction, you end up with code that's unreadable as you have to inject
context. I personally feel the proposed (by the original poster) lambda
syntax falls in this category -- I found it _more_ difficult to
understand the execution flow, and I suspect this was in large part
because it stopped resembling traditional PHP syntax.
Of the syntax changes you propose below, the only one that seems like it
retains readability to me is the very first -- and even that one, I
suspect, would cause some issues for the lexer.
I have been thinking of what syntax(s) could work to shorten the code
but not to make the code confusing. I am splitting up my ideas in to
separate sections. I think that if a short-hand function syntax is to be
accepted, it should be useful in many circumstances - eg, it shouldn't
necessarily be limited to one liners.
Okay, here is a base example:
$modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
1) REMOVING THE WORD 'function':
One solution is to simply remove the word function completely:
$modify = ( $x )use($my_constant ){ return $x + $my_constant; };
On first glance, to me, this doesn't look like I'm starting to write a
function. I could perhaps be opening a bracket to do some maths. So,
what could be done to make it more obvious? I suggest using a character
to represent function. Personally I like colon:
$modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
Now, I know this doesn't immediately scream function, but it is a
different/specific syntax which should hopefully lead to less confusion.
2) REMOVING THE WORD 'return':
Okay, my function is still a bit wordy for what it's doing. How do we
remove return? I quite like the use of = that has been suggested in
previous posts.
$modify = :( $x )use( $my_constant )= $x + $my_constant;
3) REMOVING THE WORD 'use':
Personally I don't think use is causing a
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
On 04/08/2011 21:42, Jérémy Poulain wrote:
Hi every one,
This message is also my first one. I've been following internals for few
weeks now.
I really don't think adding more short syntax would be a good idea, at least
this one.
PHP is a very popular language for many reasons, it's C-like, easy readable.
We all had to read some code made by others, most of the time without any
comment. Even with big and complicated code, keywords like function and
return help understanding because you can identify some parts of code
quickly.
Most of developpers use an IDE which use syntax colors and autocompletion so
that writing and analysing code is not a big deal. It wouldn't be that easy
if too many short syntax had been implemented.
All the given examples show closures with one instruction. It would be a
nightmare with more lines...
Agreed about multiple lines. I don't think that there should be a way to
use an explicit return if you want a multiple line function.
In the examples I gave I would do something like this to return $x+1 :
:($x)=$x+1;
If you wanted to use multiple lines, I think you should be forced in to
braces {} and do it the old fashioned way.
:($x){
$x = $x + 1;
return $x;
}
Jérémy Poulain
2011/8/4 Matthew Weier O'Phinneyweierophin...@php.net
On 2011-08-04, Jezz Goodwinjez...@officechristmas.co.uk wrote:
--060805070009050707030403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hello PHP Internals,
This is my first message to the list. I've been reading via the archive
since I read the 5.4RC1 announcement. (Keep up the great work guys - I'm
loving the new stuff)
Up until now I haven't had anything to say that wasn't already being
talked about, but the topic of short hand syntax is of particular
interest to me.
Before I start, I think I need to make clear that I am in general not a
fan of making cryptic code (ala perl). I tend to use long descriptive
variable names and try to make my code easy to read so that comments
aren't usually necessary.
Saying that though, I am a big supporter of the new short hand array
syntax. From a grammatical point of view, I see no reason why my code
needs to be scattered with the word 'array'. The simple square brackets
['a'='b'] I find just as easy to understand and they don't confuse me.
(unlike something along the lines of regex, that can easily confuse).
I see the desire to wanting to remove the word function as a similar
issue. When you use inline functions a lot, your code is filled with
lots of the word 'function'. This word doesn't necessarily need to be
there for your code still to make sense.
Also, on a similar vein of thought, if your function is only doing
something small, why do we need to put the word 'return' in there?
Well, for one, it'd be a huge disconnect between the current behavior of
functions and the new syntax. In PHP, if you have no explicit return
in your function, a null is implicitly returned. If you were to change
this so that whatever the value of the last assignment or line was is
returned, we'd have a huge BC break -- even if this were only in
lambdas.
I agree that shorter notation is often nice as it allows the syntax to
get out of the way and potentially make code more readable. However,
that's true only to a point -- if you go too far in the opposite
direction, you end up with code that's unreadable as you have to inject
context. I personally feel the proposed (by the original poster) lambda
syntax falls in this category -- I found it _more_ difficult to
understand the execution flow, and I suspect this was in large part
because it stopped resembling traditional PHP syntax.
Of the syntax changes you propose below, the only one that seems like it
retains readability to me is the very first -- and even that one, I
suspect, would cause some issues for the lexer.
I have been thinking of what syntax(s) could work to shorten the code
but not to make the code confusing. I am splitting up my ideas in to
separate sections. I think that if a short-hand function syntax is to be
accepted, it should be useful in many circumstances - eg, it shouldn't
necessarily be limited to one liners.
Okay, here is a base example:
$modify = function( $x )use( $my_constant ){ return $x + $my_constant; };
1) REMOVING THE WORD 'function':
One solution is to simply remove the word function completely:
$modify = ( $x )use($my_constant ){ return $x + $my_constant; };
On first glance, to me, this doesn't look like I'm starting to write a
function. I could perhaps be opening a bracket to do some maths. So,
what could be done to make it more obvious? I suggest using a character
to represent function. Personally I like colon:
$modify = :( $x )use( $my_constant ){ return $x + $my_constant; };
Now, I know this doesn't immediately scream function, but it is a
different/specific syntax which should hopefully lead to less confusion.
2) REMOVING THE WORD 'return':
Okay,
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
On Thu, 2011-08-04 at 21:17 +0100, Jezz Goodwin wrote: :($x)=$x+1; :( looks quite sad. I also assume you know that : is a division. In a more complex situation this might, on first sight, be mistaken as a division by $x or such. Mind that a line of code typically is read way more often than written. Readability matters. PHP in many areas makes a good thing by having keywords here and there. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
On Thu, Aug 4, 2011 at 6:35 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/4/11 5:34 AM, Lars Schultz wrote: Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. This is like saying: do not use objects at all and use the DB for storage. verbosity and slowness is something I'd like to prevent. No, it's not even remotely like that. Using one intermediary function and doing the DB call is orders of magnitude apart. You asked how you can solve the problem, I showed you how. You can claim you don't like the solution, that's fine, everybody has his own taste. But you can't claim there's no other solution. maybe it's just me, but I not fully understand your solution. I'm not sure I understand why you need week refs there - can't you just always use $prodDb-getProduct(1) and when you don't need it anymore just do $prodDb-drop(1)? Or let it drop it whenever it wants to? Do not keep object references, keep object IDs. This would make your code a bit more verbose and a bit slower, but weak refs would essentially do the same anyway. from that, my guess is that you propose that nobody should hold a reference for the product, but always use the returned object from getProduct() on the fly. you also suggest that ProductDatabase should also remove the cached object when appropriate. did I get interpreted your solution correctly? I have some problems with this approach: - you cannot guarantee/force the contract that the result of the getProduct cannot be stored. - in a loosely coupled system, it is hard to tell when you don't need it anymore. as you and Lars both mentioned we only care about freeing the cache, because we have memory constraint. Lars mentioned that currently he manually checks the memory usage, and free the cache if needed: http://www.mail-archive.com/internals@lists.php.net/msg52423.html of course one could also write some algorithm, which removes records from the cache either randomly, or as Jonathan suggestion doing something like LRU/MRU. with Weak References, you shouldn't care about that, the gc would do it for your, albeit in a less sophisticated way: if the gc root buffer is full, then free every item which isn't used at that time. and of course you can combine the WeakRefs and some cache algorithm as Jan did in his blogpost. (good article btw. and also good to see that Benjamin Eberlei from the Doctrine project looking into the possible use cases for them) so as I see you didn't really addressed the proposed use-case of the Weak References, just stated what everybody is aware of: one can cache and free objects manually without the need of Weak References. and while that is true, I still think that this could be a great asset for creating high quality components. as we agreed that this won't be considered for inclusion to the core but released as a pecl extension, I think that we should update the RFC accordingly and close the vote. we will see what happens when people start using and experimenting with it. btw. it was suggested before, but I really think, that it would be a good idea to have a register_ function which would allow you to pass a callable, which will be called when the memory usage reaches a given value. that would make a good addition to resolve some of use cases mentioned in this thread. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
Haha, yes indeed. In fact my Thunderbird was changing them to sad smileys until I disabled emoticons! Colon is one of many possibilities. Your argument goes back to whether or not PHP should have short-hand lambdas in general. It's looking like the majority of people think it shouldn't. On 04/08/2011 21:53, Johannes Schlüter wrote: On Thu, 2011-08-04 at 21:17 +0100, Jezz Goodwin wrote: :($x)=$x+1; :( looks quite sad. I also assume you know that : is a division. In a more complex situation this might, on first sight, be mistaken as a division by $x or such. Mind that a line of code typically is read way more often than written. Readability matters. PHP in many areas makes a good thing by having keywords here and there. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hello, On Thu, Aug 4, 2011 at 1:53 PM, Ferenc Kovacs tyr...@gmail.com wrote: so as I see you didn't really addressed the proposed use-case of the Weak References, just stated what everybody is aware of: one can cache and free objects manually without the need of Weak References. and while that is true, I still think that this could be a great asset for creating high quality components. I myself oppose WeakReference in java and I do not see my opinion changing for PHP ... unfortunately I think WeakReference's are even nastier in PHP because of it's error handling. You see it is very common when weak references are used in java too follow one of two paradigms, fall through with NPE's, or state/null checks. With PHP, you may not test the validity of a weak reference simply by accessing it, you will get a uncatchable fatal error. So in PHP your only option when consumers are obtaining weak reference handles, is to check their validity before use, whether that is a call into some registry, or a null check of the reference itself, whatever.. it still leads to checks to make sure that reference wasn't collected. This added complexity in the WeakReference consumer makes me unable see any purpose through the inconvenience and unpredictability they bring. btw. it was suggested before, but I really think, that it would be a good idea to have a register_ function which would allow you to pass a callable, which will be called when the memory usage reaches a given value. that would make a good addition to resolve some of use cases mentioned in this thread. I use ticks to do this in a CLI daemon I wrote, worked out pretty well. Not saying a specialized function isn't needed but I think ticks aren't to far from convenient to require such. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: An implementation of a short syntax for closures
Hi! On 8/4/11 2:02 PM, Jezz Goodwin wrote: Your argument goes back to whether or not PHP should have short-hand lambdas in general. It's looking like the majority of people think it shouldn't. And really, PHP doesn't need more cryptic syntax. There are many things that PHP does need (like people fixing unit tests, though I know it's not as fun as discussing new cryptic syntax ;) but new cryptic syntax wouldn't really allow to do anything that can't be done right now. And saving keystrokes is not really big preference, especially for language like PHP. One should be spending much more time reading code and thinking about it than typing it anyway :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4alpha3
Hello! Stas has packed PHP 5.4.0alpha3 which you can find here: http://downloads.php.net/stas/ The Windows team provides windows binaries which you find here: http://windows.php.net/qa/ Please test it carefully, and report any bugs in the bug system, but only if you have a short reproducable test case. The first beta will be released on Sep 1. regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: changes in the bugsweb
On Tue, Jul 19, 2011 at 2:03 PM, Ferenc Kovacs tyr...@gmail.com wrote: Hi guys. a few days ago I did a little modifications on web/php-bugs/trunk/include/php_versions.php so now it fetch the version information from http://qa.php.net/api.php and http://www.php.net/releases/index.php so if everything goes well, yo don't need to change the php_versions.php anymore. the versions are cached, so worst case, you have to wait an hour or just clean the item from apc (the name of the key is 'bugs.versions') please keep that in mind for the next release, and if everything goes smooth, please update the README.RELEASE_PROCESS acordingly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu I've reloaded the apache on bugsweb to clean the versions from the cache, and it seems that everything is working as expected, the 5.4.0alpha3 replaced the alpha2 in the versions field. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] TameJS syntax for Async/Parallel execution in PHP
Hello,
I came across this little library called TameJS (http://tamejs.org/) and
fell in love with the it's syntax. This had me thinking if it was possible
to add such features to a PHP CLI (or web app):
?php
await { // wait until all calls within this block is
mysql_query_async($sql, $args, defer($rs)); // call asynchronous query
curl_post_async($url,$data, defer($response)); // make asynchronous http
request
}
$rows = $rs-fetchAll();
// do something here
?
The await keyword marks a section of code that depends on externals
events, like network or disk activity, or a timer. An await block contains
one or more calls to defer.
I think the above syntax makes it easier to write asynchronous apps that can
take advantage of multiple threads or processors
What do you think?
__
Raymond
Re: [PHP-DEV] RSS channel or maillist for bugs
Thanks you! I try find it on http://php.net/mailing-lists.php, but there are no this maillists. 2011/8/4 Ferenc Kovacs tyr...@gmail.com On Thu, Aug 4, 2011 at 6:51 PM, Sokolov Evgeniy ewg...@gmail.com wrote: Hi All. I can't find RSS channel or maillist for https://bugs.php.net. If it exists? the general mailing list for bugs is php-b...@lists.php.net the rss feed for it is http://news.php.net/group.php?group=php.bugsformat=rss some bugs goes other lists like: http://news.php.net/php.doc.bugs http://news.php.net/php.pear.bugs http://news.php.net/php.webmaster http://news.php.net/php.pecl.dev you can see the list of the mailing lists here: http://news.php.net/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- -- С уважением, Соколов Евгений
