Re: [PHP-DEV] [RFC] Scalar Type Hints
On Wed, Dec 31, 2014 at 2:27 PM, Andrea Faulds wrote: > > Please read the RFC (and specification patch, if you wish) and tell me your > thoughts. > My thoughts as a long time (non-voting) PHP user: I'd much prefer if they were strict types. I have a bias toward this because I prefer to be as strict as possible. It's not hard to type my_func((int) $_GET['foo']) if I want easy conversion. This explicit cast serves as a reminder that I'm being sloppy. I can quickly scan and see if there are parts of my code that are more prone to bugs. But I'm not opposed to the RFC. I think it's *way* better than nothing, and I understand the arguments in its favor. My one complaint: I don't like that it emits a notice. I treat notices as broken code, and if it's proper to say (int) "7 things", then it ought to be proper to send that into a function. With notices being a possibility, I'll need to manually add (int) in front of everything ... at which point, we might as well have strict types. (Off-topic and different RFC, but I think having return types that auto-cast is weird, which is another reason I'd prefer strict types all around.) Finally, I'm not sure that implementing both (strict / type juggling) with different syntax is a good idea. I think I'd prefer one or the other. I don't really want to keep track as a user of many composer libs (etc) which authors decided I need to use strict types. Because I wouldn't want to have two different styles of code depending on the library I'm using, I'd end up again going back to assuming everything was a strict type. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On Tue, Jan 13, 2015 at 6:16 PM, Andrea Faulds wrote: > I’ve made some quite significant changes to my Scalar Type Hints RFC, and > bumped its version to 0.2. > > Here: https://wiki.php.net/rfc/scalar_type_hints > > This is a new thread because I’ve made a significant revision to the RFC, so > it’d be sensible to separate discussion of the updated RFC from the v0.1 RFC. > > Please tell me your thoughts. > I don't like this at all. I'd prefer raising a new warning type (e.g., E_AUTOCAST) over this. Does the voting system support instant-runoffs? If people could rate their preferences of: 1) strict scalar types 2) weak scalar types (auto cast) 3) both - different syntaxes. e.g, (int) $foo vs int $foo 4) no scalar types we could reach a compromised consensus without some building Frankenstein. I really think having either basic strict or weak types is far preferred to nothing. There are good arguments on both sides ... let the voters decide. After that, additional RFCs could be created to address raising errors on auto case, using declares to toggle behavior, etc - depending of course on what was decided on prior vote. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds wrote: > Good evening, > > The RFC has been updated to cover return types, since Levi’s Return Types RFC > has passed. The patch is a work in progress: it works, but lacks tests for > return types. > > Version 0.3 of the RFC can be found here: > https://wiki.php.net/rfc/scalar_type_hints > After thinking and talking this over, I do think your RFC is the only option that makes sense *if* you want to support both weak and strict. However, I think the usage of declare() makes it dead in the water. Fair or not, I have a hard time looking past that. I'm opposed to other compromises because I think it will be a big mess from the caller's perspective. (Some functions would be strict, some would not ... eventually forcing everybody to just use strict types.) And, as I've stated previously, I prefer strict types. Does the implementation of strict-only work for testing right now? (If so, what branch is it on, etc?) It's easy for everybody to theorize about how this would work, but why not actually take the time to "strictify" some part of a commonly used library and see how it actually works in practice? But a library with type-hints + a script to prepend "use strict" to every PHP file would make testing impact on real-world usage easy for anybody. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Introduce scrpt_path
On Fri, Feb 6, 2015 at 6:02 AM, Yasuo Ohgaki wrote: > https://wiki.php.net/rfc/script_path > > It's work in progress, but I would like to start discuss. > I don't really like it; but I don't really like most INI-based solutions. I agree that this is a problem with poorly written code, but at the same time I don't know that a good solution is to compensate in this regard. Bad programmers will always be bad programmers. Now we're giving them a crutch that almost encourages unchecked includes by relying on an INI configuration. What happens if you are using multiple libraries and they are each overriding their (and your) settings? It just feels messy. The same thing could be accomplished config-less with a callback system that is triggered on script includes (if any callback returns false, an error is thrown), but I think I'd dislike that for similar reasons. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Introduce scrpt_path
On Fri, Feb 6, 2015 at 1:02 PM, Yasuo Ohgaki wrote: > > Basically, it's administrative solution. Application should set these > setting > or administrator should. > > Library shouldn't touch the setting, otherwise they hit their own foot. > If this was a PHP_INI_PERDIR setting, then I wouldn't really mind as much. But as PHP_INI_USER, I don't like it at all. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski wrote: > > proposal everyone can rally behind, it very clearly failed. We didn't have > to wait for a vote by the way, it was clear from the discussion on > internals@. > Controversial RFCs are precisely the ones that SHOULD be voted on. Policy states that 2/3s means consensus on core language changes. The current 63.5% isn't too far from that. Just curious, but do you have a different number in mind for this vote? 90%? 80%? -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski wrote: > I'm well aware of it as I wrote that policy. The goal of the policy was to > prevent a situation where a temporary majority can introduce features into > the language that would later on be impossible to reverse. It's not by any > stretch a good mechanism to solve controversial votes, which again, should > ideally be avoided as much as possible. It's just that there isn't a better > mechanism. > I know I'm unfairly paraphrasing you, but it sounds like you are saying that for things that you don't have strong feelings about, then you're fine if the others vote amongst themselves. But for things that matter to you, you want to reserve the right to prevent change. Is there a way to fairly describe what you consider too controversial to vote on? The problem I see with votes for this type of feature is that you probably have a breakdown of something like: - 10% of people don't want scalar type hints - 20% of people want both, but 50% of them would vote for either weak or strong - 35% of people want strict, but 80% of them are fine with weak - 35% of people want weak, but 80% of them are fine with strong So if a strict-only vote happens first, you get 73% to say yes. If weak-only vote happens first, you get 73% to say yes. (I'm obviously just making up these numbers with no scientific basis, but I think the principle is valid.) The only way to be fair IMO is to hold a vote where you rank those four options (weak, strong, both, neither) and hold an instant run-off vote where the first majority wins. And if 'neither' wins, then agree that the topic cannot be revisited until next major version, so that everybody can rest for 5 years. ;) -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Anonymous Classes
On Tue, Feb 24, 2015 at 7:52 AM, Philip Sturgeon wrote:
> Good day!
>
> https://wiki.php.net/rfc/anonymous_classes
>
> There's a little RFC + patch that Joe Watkins put together, and as
> before with the ArrayOf RFC, I'll be helping out.
>
> So, lets get this discussion rolling.
>
Anonymous classes open up slightly new ways to do things. I like to
write a lot of small classes for the purposes of DI and re-usability.
Because of that, the code often looks like:
$foo = new Foo($depend1, $depend2, function() {
return 'my custom behavior';
});
That's fine when there's only one callback needed, but beyond that it
breaks down. This becomes more readable:
abstract class Foo
{
...
}
$foo = new class($depend1, $depend2) extends Foo {
public function doFoo() {
}
public function doBar() {
}
}
These cases for me are always single-use for the scope of the
application, and often it's inside configuration blocks that are
custom per environment. I have no need to name the class other than
PHP doesn't support anonymous ones.
I'm +1 on the concept, depending on what the maintenance impact that
this would bring to PHP's core. There are enough other ways to
accomplish the same goals that I don't think this is "must have", even
though I'd definitely use it.
Regarding this syntax (from other discussions on the list):
$foo = class { };
I think if such a thing were supported, maybe $foo would just be a
ReflectionClass object. (I haven't really thought that one through...)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A different user perspective on scalar type declarations
On Thu, Feb 26, 2015 at 9:28 AM, Theodore Brown wrote: > I am a full-time PHP developer responsible for maintaining several large > enterprise applications, as well as a number of libraries and personal apps. > I have been following the scalar type proposals quite closely, as along with > return type declarations, scalar types have the potential to reduce errors, > simplify API documentation, and improve static code analysis. > > I am in favor of Anthony's Scalar Type Declarations RFC, for two simple > reasons: > > 1. It doesn't change the behavior of existing weak types. > 2. Strict types are important in some cases. > After carefully reviewing both proposals and testing the implementations out, and switching opinions many times, I've come to the same conclusion as this. (I'm glad the define() syntax was simplified.) With more and more discussion, I feel like the coercive version is just degrading back into the same weak casts as we already have. If I can pass null or " 1 " or bool to an int, then it becomes less like a different RFC and more like the same strict types RFC but without the strict mode! To be clear, I'd actually be fine with a weak-only implementation that follows the same exact rules as the explicit casts. And I'm okay with strict-mode optionally tacked on top of that -- because it can be useful and won't get in my way. But I'm no longer in favor of any in-between coercive implementation. Not a voter, so just my 2 cents. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PR] DateTime::createFromImmutable() method
On Mon, Mar 9, 2015 at 5:35 AM, Derick Rethans wrote:
> On Thu, 5 Mar 2015, Trevor Suarez wrote:
>
>> Good morning internals!
>>
>> I would like to propose a small addition be made to the DateTime class.
>>
>> https://github.com/php/php-src/pull/1145
>
> When the factory method was added, we had this same discussion. And the
> discussions lead to the conclusion that it does not make sense to have
> this "createFromImmutable" factory method on DateTime. Basically with
> the same reasons that people should type hint against the Interface
> instead.
>
If you have a method that needs to modify the DateTime, then you must
choose between DateTime or DateTimeImmutable. (The interface is read
only.) That is, I think it is poor practice to repeat the following
over and over in every method:
function changeTheDate(DateTimeInterface $dt)
{
$immutable = new DateTimeImmutable($dt->format('c'));
$immutable->setTimeZone(...); // etc
return $someCalculation;
}
That function really needs a DateTimeImmutable, so the burden of
converting it ought to be on the caller. It might be able to optimize
the number of conversions, etc.
I almost always use DateTimeImmutables ... fewer side effects, etc.
However, many libraries and code I interface with require a DateTime
for such things. (Yes, perhaps they just incorrectly type hint for a
DateTime, but I cannot help that.) So I need to convert from
DateTimeImmutable to DateTime.
e.g.,
function foo(DateTime $dt) { }
$dt = new DateTimeImmutable;
foo(new DateTime($dt->format('c')); // the method I use
foo(new DateTime($dt)); // doesn't work
foo(DateTime::fromInstance($dt)); // doesn't exist
(It's possible that
DateTimeImmutable::fromInstance($dateTimeImmutable) could just return
the same object.)
So while not a pressing issue, I do think a more straightforward way
of converting would be good because the reality is that you're going
to need to do the conversions at some point if you interface with
other people's code, no matter how hard you try to use good practices.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A plea for unity on scalar types
On Sun, Mar 15, 2015 at 4:52 AM, Pavel Kouřil wrote: > So - are you saying that it would be easy to remove this feature from > the language once people would realize it's register_globals (and any > other settings that change how code behaves) all over again? > Actually, it would be very easy to remove this from the language. There is no possible way to rely on strict hints over auto-cast hints in such a way that would break your application by any meaningful definition of the word. Output, after strict_types has been removed from language: E_NOTICE: strict_types is no longer supported. 2 Yes, that would have previously thrown an exception, but the behavior after removing strict types from the language really hasn't broken anything. This is nothing like removing register_globals... where entire apps silently break without any good way to track down how and where. Honestly, I think the reverse of your scenario is more likely. 1) Only the "strict_types=0" mode is implemented, using same rules as standard PHP casts. (basic_scalar_types) 2) xdebug adds a feature to enable the equivalent of strict_types=1 for debug mode. 3) People realize this is super useful and request "please allow a whitelist while debugging so I can debug my app in pieces" and ask "how can we optionally enable this during production mode?" 4) declare(strict_types=1) is proposed for support in PHP without xdebug, and is accepted. :) Finally, the voting process on these two RFCs is absurd, and even more absurd with the proposal of a third one. Very few people are going to play fair and vote YES on multiple of them, even if they would vote YES if it was the only proposal. As I've said before, the best way to reach consensus on *large, grand ideas* (i.e., not petty details) is to hold an instant runoff on a single vote. e.g., Rank your choices in order of preference: scalar_type_hints_v5, coercive_sth, basic_scalar_types, none. First to 2/3's win, after eliminating the least popular vote each round. (Could still end up with a winner < 2/3s, which would just mean the RFC failed.) I sincerely hope this type of vote is added as an option for future RFCs when appropriate, so that we never have to go through this terrible process again. (PS: I have nothing against the RFC authors; on the contrary, I respect all of the work they have put into their proposals. So big thanks to all of you!) -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Sun, Mar 15, 2015 at 9:19 AM, Anthony Ferrara wrote: > All, > > I ran some numbers on the current votes of the dual-mode vote right > now. There were a number of voters that I didn't recognize. So I > decided to pull some stats. > ... > > Something that I think we need to discuss as a group. > > So consider that discussion open. > I think this is likely because the votes are made public during voting phase. To me, that is a bad thing. It makes for an ugly voting period. That sort of politics should happen during the discussion phase. So I don't think there's anything wrong with "first time voters" voting No en masse here. I just think there's a major problem in having a real-time count of votes during the voting period. If votes weren't made public during the voting, then more people would vote on more issues... avoiding this situation where people come from "nowhere" to cast a vote as word gets out on blogs that something terrible is about to happen. In short, I think the real-time public vote results causes a few problems: 1) Bandwagon voting, or "vote for the winner" mindset. The early wave of voters can impact the results by discouraging people from voting. (Look at Zeev's RFC vote count vs Anthony's.) 2) The losing side feverishly drumming up votes, often with scare tactics - i.e., vocal minority. (It's much easier for the "No" side of any vote to appeal to this.) 3) In rare cases, Gaming the system - closing the vote at the exact time that benefits the owner of the RFC. So I don't think there's anything sinister here. It's just the natural result of the voting rules. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 12:55 AM, Xinchen Hui wrote: > That is why I don't see it before (thousand times, too long to read... > but not in RFC) > It's in the RFC: "Whether or not the function being called was declared in a file that uses strict or weak type checking is irrelevant. The type checking mode depends on the file where the function is called." If it were the other way around, then you'd be correct -- it would be a disaster. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] "strict_types" should be renamed "raise_type_error". WAS: About declare(strict_types = 1)
On Mon, Mar 16, 2015 at 2:53 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> I think this is important, but not many people realize the importance.
> Therefore I created this as a new thread at the last minutes of vote.
>
...
>
> "strict_mode" is just controlling errors, then it should be named as error
> controlling directive and raise E_WARNING/E_TYPE or whatever.
>
> Even if what its controlling is error that can be overridden by caller, yet
> calling it "strict_types" is not correct. Proper name would be something
> like "raise_type_error".
>
> Let's see how it looks if "strict_types" is renamed to "raise_type_error"
>
...
> declare(raise_type_error = 1);
> require "lib.php";
> foo("123"); // will give an error
> ?>
>
I agree that the name doesn't by itself explain the feature, but how
could it possibly? You'd end up with something like:
declare(raise_type_errors_on_parameter_mismatches_when_calling_functions_from_this_file_regardless_of_where_the_functions_are_defined_and_what_the_setting_is_in_other_files=1);
I don't think your suggestion explains the feature any better than
strict_types. (Although the irony of using =1 instead of =true isn't
lost on me!)
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Access-Control-Allow-Origin header in CLI server
Hello, I commonly use PHP's built-in CLI server for development, using two running instances on two different ports, one for dynamic PHP content and the other for static content. But because PHP does not send the Access-Control-Allow-Origin header, Firefox will not load custom web fonts. See http://www.red-team-design.com/firefox-doesnt-allow-cross-domain-fonts-by-default The attached patch unconditionally sets it for all static files. Should I submit a bug report, or is this email sufficient to get somebody to look at it? -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Access-Control-Allow-Origin header in CLI server
On Fri, Jul 5, 2013 at 5:48 PM, Daniel Lowrey wrote: > This is not the sort of thing that belongs in an HTTP server by > default. It's a one-off header that some users may elect to send but > the vast majority will not. > Of course I agree if you were speaking about a production web server. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Access-Control-Allow-Origin header in CLI server
On Sat, Jul 6, 2013 at 7:59 AM, Mario Brandt wrote: > You can use the router script to add that header of your desire into > every request. > That's what I currently do. And I agree that if somebody wants to deviate from the reasonable set of defaults that PHP provides, then he must set them in a router script. I don't think the CLI server should be a configurable web server. But IMO, this is no different from PHP maintaining and delivering a small set of Content-type headers. Of course you could take the same hardline approach and tell the developer to set all of the content headers himself because you're worried that somebody might use PNG as a data file that holds ping pong scores. But neither the existence of this nor the content-type have any reasonable side effects. I'm just throwing this out here; I've got nothing more to say and am fine with the powers-to-be doing whatever they feel appropriate. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Syntax for variadic functions
On Wed, Aug 28, 2013 at 10:47 AM, Nikita Popov wrote: > Hi internals! > > I'd like to propose an RFC, which adds dedicated syntax for variadic > functions: > ... > > What are your thoughts on this? > I think it's great way to clean things up and add some subtle new functionality, particularly with Lazare's follow-up proposal about expanding an indexed array into arguments. Would any functions get deprecated as a result of this? e.g., func_get_args() I assume it's a syntax error to do function fn(...$foo, $bar) or function fn(...$foo, ...$bar) I assume that function fn($a, $b = null, ...$c) is possible, and the only way to populate $c is to call fn with three or more parameters. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: crc32() and ip2long() return values
On Fri, Aug 30, 2013 at 10:29 AM, Rasmus Schultz wrote:
> No replies probably means no one cares. oh well.
>
> For the record, the examples I posted are wrong - the correct way to
> convert the long values consistently appears to be:
>
> list($v) = array_values(unpack('l', pack('l', ip2long('255.255.255.0';
>
I had spotted the error, but didn't want to reply because I don't
really understand what you are getting at.
The core issue is that PHP doesn't provide a 32-bit unsigned integer
on a 32-bit platform ... and/or that the size of integer changes
depending on the platform. But I doubt that is going to change any
time soon. Crippling 64-bit systems due to old, legacy 32-bit
platforms is shortsighted.
What's wrong with the manual's approach?
$checksum = sprintf("%u", crc32("The quick brown fox jumped over the
lazy dog."));
Are you going to do further mathematical operations on it? You can
take that string and stuff it into an uint32 field into a db without
an issue.
At the end of the day, there's no getting around that PHP programmers
need to be aware of the difference between 32-bit and 64-bit systems
... it affects far more than these two particular functions.
But if these two functions are particularly bothersome, a better "fix"
IMO is just:
$crc = crc32("12341234", CRC32_UINT32_STRING);
Where the second parameter is CRC32_INT (default & current behavior),
CRC32_INT32 (always negative if high bit is set), CRC32_UINT32_STRING,
CRC32_HEX_STRING
Forgive the poor names.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: crc32() and ip2long() return values
On Fri, Aug 30, 2013 at 11:48 AM, Rasmus Schultz wrote:
> array(2) {
> [2130706433]=>
> string(3) "foo"
> ["4294967040"]=>
> string(3) "bar"
> }
>
> The keys are now two different types (string vs int) on 32-bit platforms,
> which leads to problems with strict comparison.
>
Prefix your keys with any alpha char to enforce a consistent string type.
> Another issue is persistence - if you save these to unsigned integer columns
> in database, and your data access layer converts them back to integers on
> load, the values are going to change again depending on what platform you're
> on.
>
I've never had that issue with any database layer I've ever worked
with. Not saying that no such db layer exists, but if you use PHP with
big integers, then you should treat them as strings in and out. If you
want to do math on them, then you have to use one of the bigint
libraries. If you want them for display purposes, keep them as
strings.
> To quote the specific case where I encountered this, I have an audit trail
> system that logs a lot of user activity - as an optimization, I hash and
> store certain keys using crc32() numeric values, since storing a 32-bit
> number is much cheaper (in terms of storage) than storing strings, as well
> as giving much faster queries.
>
Again, you should be able to store them from a string int to database
int without any issues. If so, I'd suggest fixing this at the database
access layer.
> Why would you consider a consistent function "crippled"?
>
It's crippled in the sense that it punishes people who are using
modern hardware from intelligently processing the return value. I have
a 64-bit system, and it returns a negative number for a 32-bit CRC?
> Look at the sheer number of comments on the crc32 manual page and tell me if
> you still think this works well for anybody... many of the comments
> (including mine!) aren't even correct and don't lead to predictable
> results...
>
A lot of PHP functions have tons of user error from people who haven't
bothered to read the existing manual entry or other comments.
> This should be easy but it is extremely hard.
>
There should never be the expectation that things "just work" without
having to understand the core features and limitations of the
language. To me, the examples you are giving are just two cases of the
larger problem of 32 vs 64 bit. There really is no getting around the
fact that scripts with integers behave differently depending on the
system.
So while I don't mean to sound dismissive of your complaints (because
they are valid), I just don't see how two bandaids over specific
instances of a larger problem do much good. Although, to be pragmatic,
I offered what I feel is a better solution than your extra functions.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 11:39 AM, Nikita Popov wrote: > The RFC and implementation are not yet complete. I mainly want to have > feedback on the idea in general and on the Open Questions ( > https://wiki.php.net/rfc/named_params#open_questions) in particular. > I feel like this will just encourage more core PHP functions with an unmanageable number of parameters. Will there be any proposed guidelines to how future functions will make use of named parameters? e.g., Will we see native functions with 20 arguments? What I don't like about named parameters is that if I build a library, now even my parameter names are unchangeable if I don't want to break any backward compatibility, since I never know if somebody will decide to call my single parameter method with named parameters. Are we prepared to go through every PHP function and make sure the names of the parameters are set in stone before this feature would go live? So I'm neutral to this proposal, as I would never purposefully build a function that is so convoluted that it needs named parameters, but I understand that's how some people like to write code, and it could be useful in extreme cases. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 8:56 PM, Ryan McCue wrote: > Matthew Leverton wrote: > This is already the case. In libraries that accept options via an array, > those array keys are pretty much set in stone (although you can map them > if you need to change a key). > The big difference here is if I accept an options array, I understand that the keys are important and would never break backward compatibility by changing a parameter name. This isn't a case of "if you don't like it, then don't use it" because every function I create now has to respect the possibility of accepting named parameters, whether I care about it or not. And I sure hope every function I call is created by and maintained by somebody with those same sensibilities. My opinion is that this really isn't as cool as it sounds, especially since we have short array syntax. Again, I don't really care if it's accepted into PHP, but I think it will be more of a minor nuisance for me than anything else. -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 5:05 AM, Michael John Burgess
wrote:
> The position of parameters and the name of the function must already be
> maintained... I dont see why appropriately naming variables is such a
> burden.
>
I wouldn't necessarily make this objection if this were a day-1
feature. But it does bother me somewhat that all of a sudden code
retro-actively starts supporting named parameters.
The OCD in me shudders to think about now having to parse through
people's code like:
substr('length' => 1, 'string' => 'Hello World');
Now I see the function, and I have to see how they ordered their
parameters. Why was 'start' omitted... is this a warning due to using
NULL as an int.. did the person mean 'start', etc? It's just one
example, but I know that this sort of code will start cropping up
everywhere. So that's why I call this a nuisance. It just seems like a
very marginal gain for lots of potential headaches.
But I don't mean to make a mountain out of a molehill. After giving it
some thought, I'd like some consideration to be given to providing an
explicit syntax in the RFC at least so people consider all
alternatives.
I just don't think that giving people the ability to call a function
with two well ordered parameters by using named parameters is worth
causing all future code to diverge into two drastically different
calling styles.
My strong preference would be a syntax that separates the two types of
parameters, such as the following:
function func($a, $b, ...$params, [$c = 'foo', $d = 'bar'])
{
}
func($a, $b, $extra, 'd' => 'override');
Here $a and $b are not named parameters and must be present. Extra
positional parameters are sent to $params. The parameters enclosed in
square brackets must be passed in by name as the last parameters, but
can be omitted.
I don't like the $ on the named parameter when calling because it
implies that this works:
$d = 'c';
func($a, $b, $extra, $d => 'override');
Now is 'c' overridden or 'd'?
So I'll give this issue a rest unless somebody wants to further
discuss what the concrete syntax might look like.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Keywords as identifiers
On Tue, Sep 17, 2013 at 7:50 PM, Stuart Langley wrote:
> To be honest, looking at the example in the RFC, being able to define a
> member function 'new' on a class that completely changes the semantics of
> the new operator is a great example of why you would not want this feature.
>
It doesn't change anything because $foo->new() has no intrinsic
meaning in PHP. And I don't think the argument "the programmer might
do something stupid" ever holds much weight as a no vote against
anything. If somebody wants to create a confusing misnomer, he doesn't
need this proposed feature to do so.
But I agree that the RFC is missing any real-world examples of why it
might be useful, and that any new language feature should have
real-world benefits. Hopefully some more compelling reasons will be
added to the RFC.
Here's something that I've personally done with much shame:
class Where
{
private function _or($lhs, $op = null, $rhs = null)
{
}
public function __call($func_name, $args)
{
if ($func_name == 'or')
return call_user_func_array([$this, '_or'], $args);
}
}
$query->where('foo', '=', 1)->or('bar', '=', 2);
Imagine that $query->where() returns a Where object. I really want an
"or" method because it make things concise & readable, but this is not
allowed. So I override the __call method to add such functionality,
which adds useless overhead.
There are a few keywords, such as list and unset, that I often wish I
could use in PHP. So in terms of readability, I think any sane
programmer would use this proposed functionality for good...
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Expectations
Since this would throw exceptions, could it look like (or be) a final/abstract (although PHP doesn't allow that combo for some reason) class with static methods? Assert::isTrue($expr, $msg); That syntax is already valid (so of course there are BC issues) and I don't know how practical it is to optimize that away to nothing, but it would be more consistent with regard to throwing exceptions and would allow for a variety of different class methods. -- Matthew Leverton On Sun, Oct 20, 2013 at 8:52 PM, Joe Watkins wrote: > On 10/20/2013 12:15 AM, Ferenc Kovacs wrote: >> >> On Sun, Oct 20, 2013 at 12:36 AM, Robert Stoll wrote: >> >>> Heya, >>> >>> I do not know how much it concerns this RFC but I came across the >>> following >>> page about an extension named "Expect" when I was searching for RFC >>> Expect >>> with google. >>> http://php.net/manual/en/book.expect.php >>> >>> I suppose there would be a name clash between the extension and the new >>> expect keyword. I do not know how internals usually deal with such >>> problems, >>> especially if it is within an extension, but I am sure someone will know >>> it. >>> >>> Cheers, >>> Robert >>> >>> >> it was discussed on irc, there is not problem here, because the ext name >> and the function name can't clash, and the ext doesn't have a function >> with >> the name of expect, so everything is fine afaik. >> > > Rasmus has pointed out that there is an expect:// stream wrapper. > > So looks like we need a new name ?? Ideas ?? > > > Cheers > Joe > > -- > 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][RFC] Scalar Type Hinting with Cast
On Sun, Sep 14, 2014 at 3:22 PM, Derick Rethans wrote:
> We can either have casting where:
>
> function bar(int $foo) { }
> bar("42");
>
> Means the same as:
>
> function bar($foo) { }
> bar((int) "42");
>
> Or we can have it as a strict cast, or we can have it like it currently
> (ie, not at all). I can live with those three options, but not an
> option where casting/checking does something different again.
>
I totally agree with this. I can understand any of the following:
1) function f(int $a) { } == f( (int) $a); -- with NO notices
2) function f(int $a) {} means $a must be exactly type int -- or
recoverable error is thrown
3) current behavior (no scalar type hints)
But a new set of rules that require a 23x7 table to describe what's
going on ... not a big fan.
--
Matthew Leverton
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
