Re: [PHP-DEV] [RFC] Importing namespaced functions
Hi, Are there any thoughts regarding importing multiple functions of a namespace with a wildcard? A use case being, for example, assertions from a testing framework. use (or use function) TestingFramework\Assertions\chosen wildcard here; // in java * is used for wildcard Regards, Marcello On 15 Aug 2013, at 14:06, Igor Wiedler wrote: Hi Daniel, Thanks for the suggestion. Since it is less straight-forward I would rather just move forward with the current syntax. I'd hate to see the proposal rejected because people did not like the syntax. Regards, Igor On Aug 8, 2013, at 10:30 PM, Daniel Bingham daniel.bing...@ellislab.com wrote: Hey Igor, I love the RFC, but how about: use bar\baz() as baz; As an alternative to use function. Still new syntax, but a little less wordy. I have nothing for use const, but use const feels more natural to me than use function does. Just an idea for pondering! Dan On Thu, Aug 8, 2013 at 2:44 PM, Michael Wallner m...@php.net wrote: On 8 August 2013 14:29, Igor Wiedler i...@wiedler.ch wrote: Hi everyone, I just wanted to bump this topic, since there's not been much feedback during the last few weeks. Comments on the patch are also welcome. RFC: https://wiki.php.net/rfc/use_function Patch: https://github.com/php/php-src/pull/388 I like it. It improves the state for non-OOP in PHP. -- Regards, Mike -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Abstract properties
On 1 Dec 2012, at 12:34, Sebastian Krebs wrote: Hi, Don't want to start a big discussion, but is there a concrete reason, why abstract properties (or a kind of abstract) are not supported? Hi, The reason for not having abstract properties is that when you are defining a type you don't care about how the implementation will store the state. The contract is about message exchanges, how the objects will talk to each other, via the public interface, e.g. the public methods. Also, think of the keyword abstract as something that is incomplete. An abstract class is an incomplete class, an abstract method is an incomplete method. So an abstract property doesn't make sense, as it doesn't need anything to be complete. Reinforce the implementation to store state in a particular way would be a bad feature for PHP. This is one the things we got it right. Kind regards, Marcello -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Short syntax for anonymous functions
Inspired by Sara, here is another RFC, I finally got around to draft: https://wiki.php.net/rfc/short-syntax-for-anonymous-function Please feedback, -- Marcello Duarte
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
Thanks for the feedback. I get most people here don't appreciate the value of
the feature.
I can understand that If you haven't tried to write a tool like capistrano,
rspec, chef, puppet, etc, etc in PHP you probably won't see much value in
implementing such things.
On 19 Feb 2013, at 13:19, Derick Rethans wrote:
On Tue, 19 Feb 2013, Marcello Duarte wrote:
Inspired by Sara, here is another RFC, I finally got around to draft:
https://wiki.php.net/rfc/short-syntax-for-anonymous-function
I'd be really reluctant to add this -- it's yet another (superfluous)
syntactical sugar, there is no patch, and how does this work with bound
variables (use keyword)?
I added an example with the use keyword.
What is superfluous for is useful for other users. It would be useful building
DSL. At my company we use loads of ruby tools for deploying, provisioning, etc.
just because of the DSL they provide. The array short syntax was great news.
Adding a short syntax for closures would make it possible to write such scripts
in PHP – where the syntax would not stand on its way.
On 19 Feb 2013, at 13:28, Patrick ALLAERT wrote:
BC break detected:
?php
{
echo foo\n;
return bar;
};
echo baz\n;
return 42;
?
I am actually more concerned with Patrick's feedback regarding BC. I can't
think of a solution for this right now.
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Marcello Duarte
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 19 Feb 2013, at 16:29, Morfi wrote:
($n) = { echo $n; }
($n) use ($m) = { echo $n; }
Morfi, the problem pointed out already is when you have no arguments it would
be the same as the statement block, which would cause BC issues.
On Tue, Feb 19, 2013 at 8:11 PM, Levi Morrison morrison.l...@gmail.comwrote:
IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:
function ($n) use ($m) { return $m * $n; }
Versus one potential option:
($value) |$m| = $m * $n;
My apologies, this was meant to read:
($n) |$m| = $m * $n;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Best regards, Andrey
--
Marcello Duarte
marcello.dua...@gmail.com
http://marcelloduarte.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 19 Feb 2013, at 14:16, Leigh wrote: I can understand that If you haven't tried to write a tool like capistrano, rspec, chef, puppet, etc, etc in PHP you probably won't see much value in implementing such things. Your RFC doesn't go to great lengths to explain the value either. Pretend the reader has no experience with any of those tools you mention, pretend the only language they know is PHP, please explain where the value for this syntax is in PHP? Very good feedback. Very much appreciated. I will see if I can expand on what I have that. Thank you. I find the existing syntax easy to understand. I find the proposed syntax disproportionally difficult and unintuitive in relation to any benefit it is supposed to give. What is superfluous for is useful for other users. It would be useful building DSL. At my company we use loads of ruby tools for deploying, provisioning, etc. just because of the DSL they provide. The array short syntax was great news. Adding a short syntax for closures would make it possible to write such scripts in PHP – where the syntax would not stand on its way. insert PHP is not Ruby rhetoric If Ruby is the right tool for the job, and PHP is not the right tool for the job, the answer to which language to use seems obvious right? I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application. I disagree wholeheartedly that this proposed syntax would make code in any way more readable, or maintainable. Please understand that there is a difference between code you write and other people maintain, and code you write for other people to use. The purpose of this feature is focused on the later, to allow the construction of DSLs, so users of your code can focus on the task at hand. -- Marcello Duarte -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 19 Feb 2013, at 17:32, Leigh wrote: On 19 February 2013 16:46, Marcello Duarte mdua...@inviqa.com wrote: I find that more and more my developers have to learn ruby just to be able to work in our projects. We are one of the largest PHP shops in Europe and even the proprietary tools we are writing for DevOps stuff we are writing in Ruby. This small syntax arrangement would make it possible to write DSLs in PHP. The result is that I can have my PHP developers focusing on one language only and get the job done. The problem of the web is a bit more complex now, if you look on all you need to develop and deploy a large PHP application. That is one of the choices you made for your projects. You looked at what was available, and decided that Ruby was the best choice for the task at hand. While I agree it's unfortunate that your developers to have to waste their time learning Ruby, when they could be doing more productive things, that doesn't mean it's a good idea to try and retrofit some evil syntax into PHP just for you, no matter how large an organisation you are. I am curious: evil syntax? I am not attached to the syntax I have described. I am open to discuss the syntax. It would be good with using the callable as last argument converted into a block for DSLs. I don't think this is evil, but I don't want to fall into a personal taste debate. I want something I can use. And just for you is also inaccurate. You will find that the technologies I've been referring to are becoming the tools you will use for DevOps, etc... tasks. Do you guys listen to people outside of internals? It would be good to have a feedback mechanism that actually involve PHP developers in real world projects. I take that if you are coding with other languages like C, all the time, that you may loose contact with the way things are done. By the way, PHP is open source, feel free to make the parser do whatever you want. On 19 February 2013 16:40, Levi Morrison morrison.l...@gmail.com wrote: Say we agree on the syntax above ($n) |$m| = $m * $n; What happens when my one liner function needs to do one more operation like checking the value of $n before multiplication? As I stated before suggesting the syntax: It's only meant for a single expression. It's purposefully NOT intended to cover multiple expressions. In that case the current (verbose) syntax is better for all criteria I care about. Additionally, neither Python nor Dart allows multiple expressions in their short-syntax functions. I prefer this. In this case (imho), a simplified syntax *should* go hand in hand with simplified functionality. If PHP is to adopt such a syntax I'd much prefer it takes the single expression approach. This does achieve the goals of easy readability and maintenance because you know the expression is bound by certain limitations. -- Marcello Duarte Head of Training Inviqa enterprise open source e-mail: marce...@inviqa.com mobile: +44 78 3316 8193 phone: +44 20 3179 9555 twitter: @_md @Inviqa inviqa.com Disclaimer This email and any attachments may be confidential and are intended solely for the use of the addressee. Any views or opinions expressed are those of the author and may not represent those of Inviqa. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.
Re: [PHP-DEV] Wiki account
On 18 Oct 2012, at 02:20, Hannes Magnusson wrote: On Wed, Oct 17, 2012 at 2:49 AM, Pierre Joye pierre@gmail.com wrote: Marcello likes to write a RFC On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte marcello.dua...@gmail.com wrote: Hi, Can I please have a wiki account? People who cannot read do not get wiki karma: https://wiki.php.net/start?do=register :( Ok, ignoring the rudeness... I have an account, and I can read (pun intended), however I cannot write or create pages. I assumed it was a privilege issue. That's what I kept repeating to Pierre on twitter, to which he reply: send an email to the internals asking for a wiki account. Any real help is appreciated. Thanks, Marcello -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wiki account
On 18 Oct 2012, at 09:13, Hannes Magnusson wrote: On Thu, Oct 18, 2012 at 1:08 AM, Marcello Duarte marcello.dua...@gmail.com wrote: On 18 Oct 2012, at 02:20, Hannes Magnusson wrote: On Wed, Oct 17, 2012 at 2:49 AM, Pierre Joye pierre@gmail.com wrote: Marcello likes to write a RFC On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte marcello.dua...@gmail.com wrote: Hi, Can I please have a wiki account? People who cannot read do not get wiki karma: https://wiki.php.net/start?do=register :( Ok, ignoring the rudeness... I have an account, and I can read (pun intended), however I cannot write or create pages. I assumed it was a privilege issue. That's what I kept repeating to Pierre on twitter, to which he reply: send an email to the internals asking for a wiki account. I don't know why he is asking you to send an email here. The registration page I linked to explicitly says php-webmaster@ and the instruction to get write karma. -Hannes Hannes, that page doesn't have any explicit reference to write karma. Pierre, should I write to php-webmaster? Thanks, Marcello -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wiki account
On 18 Oct 2012, at 09:37, Derick Rethans wrote: Marcello Duarte marcello.dua...@gmail.com wrote: On 18 Oct 2012, at 09:13, Hannes Magnusson wrote: On Thu, Oct 18, 2012 at 1:08 AM, Marcello Duarte marcello.dua...@gmail.com wrote: On 18 Oct 2012, at 02:20, Hannes Magnusson wrote: On Wed, Oct 17, 2012 at 2:49 AM, Pierre Joye pierre@gmail.com wrote: Marcello likes to write a RFC On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte marcello.dua...@gmail.com wrote: Hi, Can I please have a wiki account? People who cannot read do not get wiki karma: https://wiki.php.net/start?do=register :( Ok, ignoring the rudeness... I have an account, and I can read (pun intended), however I cannot write or create pages. I assumed it was a privilege issue. That's what I kept repeating to Pierre on twitter, to which he reply: send an email to the internals asking for a wiki account. I don't know why he is asking you to send an email here. The registration page I linked to explicitly says php-webmaster@ and the instruction to get write karma. Hannes, that page doesn't have any explicit reference to write karma. Pierre, should I write to php-webmaster? That page clearly says: Once you register with this form and receive your wiki username you still won't be able to edit the wiki until we manually authorize access. This reduces wiki vandalism. To get authorization you must send a quick introduction to the php-webmaster mailing list. Mention your wiki username and say what you're planning to do. This email lets us know you're a human (and not a robot) and what you'll be working on. So yes, mail php-webmaster. Derick Done. But I am still confused by this write karma thing. Feel free to ignore my confusion. I will now sit and wait for the php-webmaster mercy. Thanks, Marcello -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Wiki account
Hi, Can I please have a wiki account? Regards, Marcello -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closures: Object extension
Hi, What is the status of this RFC: Closures: Object extension? https://wiki.php.net/rfc/closures/object-extension _md
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
+1 to being able to omit the function keyword.
2010/11/27 Johannes Schlüter johan...@schlueters.de:
Hi,
every now and then while writing classes I forget to add the function
keyword between my visibility modifier and the method name in a class
declaration. I don't think it is required for readability and it is not
needed by the parser to prevent conflicts, I therefore propose the
following RFC incl. patch to allow writing
class Foo {
public bar() {
echo Hello World;
}
}
Without T_FUNCTION token. In my opinion an access modifier /public,
private protected, static, final) should still be required for keeping
readability.
RFC: http://wiki.php.net/rfc/optional-t-function
Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
johannes
--
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
