Re: [PHP-DEV] Why are serialized strings wrapped in double quotes? (s::"")
Hi Michał,
Thursday, February 8, 2024, 2:58:52 AM, you wrote:
>You inspired me to play with serialization format to spot even more
>unnecessary chars https://3v4l.org/DLh1U
>From my PoV there are more candidates to reduce and still keep the safety,
>for eg:
>removing leading ':' before array/object and trailing ';' inside brackets,
>you reduce by 2 bytes
>
>a:4:{i:0;i:123;i:1;b:1;i:2;d:1.1;i:3;s:3:"baz";}
>
>Could be simply
>
>a:4{i:0;i:123;i:1;b:1;i:2;d:1.1;i:3;s:3:baz}
>
>This example saves 4 bytes: double-quotes, one ; and :
>
>If you go further all types that require size/length also don't need extra
>double-colon meaning:
>a:4 could become a4
>s:3 could become s3
>
>The same could apply to O: and E:
>
>O3:Foo:5{s4:date;O17:DateTimeImmutable:3{s4:date;s26:2024-02-08
>08:41:10.009742;s13:timezone_type;i:3;s8:timezone;s16:Europe/Amsterdam}s6:*foo;s11:Foo
>bar
>baz;s8:Foobar;i:123456789;s3:tbl;a4{i:0;i:123;i:1;b:1;i:2;d:1.1;i:3;s3:baz}s8:*color;E12:Color:Yellow}
>
>This is still readable by humans and keep the size/length in all places
>where needed.
Amazing. To my eyes it's more readable too.
Here's another one: leading numeral *implies* Integer 'i' (so only
'd', 'b' and 's' are necessary). Or maybe that goes too far.
>Interestingly when an array is serialized as object property it is not
>followed by ; in field list https://3v4l.org/4p6ve
>
>O:3:"Foo":2:{s:3:"foo";a:3:{i:0;i:1;i:1;i:2;i:2;i:3;}s:3:"bar";s:3:"baz";}
>
>Missing ; between }s was a surprise to me.
Yeah, that almost seems like a bug that unserialize() tolerates.
— S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Why are serialized strings wrapped in double quotes? (s::"")
Nice work, Jim. >I enjoy spelunking in the history of the project, so I did some digging. It >looks to me like Kris didn't quite get the history correct. Boris did propose >a form of serialization first, but it looks like what became serialize() and >unserialize() came into the project another way. > >https://marc.info/?l=php-general=90222513234434=2 > >The serialize() and unserialize() functions were first added in PHP 3.0.5 >with that same encoding for strings that you're asking about. Here is the >original proposal for adding the functions from Jani Lehtimäki: > >https://news-web.php.net/php.dev/1444 > >The were originally conceived as var_save() and var_load() and operated on >files, but you can see the file format uses the same string encoding, although >it used single quotes. > >It was committed to CVS by Stig here, but unfortunately the emails to the list >didn't include newly-added files. > >https://news-web.php.net/php.dev/1540 Huh. So the quotes may have just stuck around from eval()-related approaches without being officially discussed. In the grand scheme even if you're wasting 2 bytes for every string that could be a tiny % on average. The format's fascinating because it unmistakably *works*, and binary igbinary/msgpack aside, it's a pretty good byte-stream encoding. If you take Sergey's results it's way faster than JSON, at least when it's PHP doing the unserialization: https://grechin.org/2021/04/06/php-json-encode-vs-serialize-performance-comparison.html — S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Why are serialized strings wrapped in double quotes? (s::"")
> I don't have the historical context, but I'm assuming that's it. PHPs > serialization format is not efficient, and I don't think that was ever > the primary focus. Thanks Ilija. That'll have to suffice unless someone remembers a specific decision (searching all the old Internals posts nothing came up). Most of my readers are pretty junior but I hate to say something that conflicts with their intuition. — S. On Wed, Feb 7, 2024 at 7:28 AM Ilija Tovilo wrote: > > Hi Sandy > > On Tue, Feb 6, 2024 at 9:19 PM Sanford Whiteman > wrote: > > > > I'd like a little background on something we've long accepted: why > > does the serialization format need double quotes around a string, even > > though the byte length is explicit? > > > > Example: > > > > s:5:"hello"; > > > > All else being equal I would think we could have just > > > > s:5:hello; > > > > Was this just to make strings look more 'stringy', even though the > > format isn't meant to be human-readable? > > I don't have the historical context, but I'm assuming that's it. PHPs > serialization format is not efficient, and I don't think that was ever > the primary focus. If you need something more efficient, you can try > https://github.com/igbinary/igbinary which is aimed to be a drop-in > replacement. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Why are serialized strings wrapped in double quotes? (s::"")
Howdy all, haven't posted in ages but good to see the list going strong. I'd like a little background on something we've long accepted: why does the serialization format need double quotes around a string, even though the byte length is explicit? Example: s:5:"hello"; All else being equal I would think we could have just s:5:hello; and skip forward 5 bytes. Instead we need to be aware of the leading and trailing " in our state machine but I'm not sure what the advantage is. Was this just to make strings look more 'stringy', even though the format isn't meant to be human-readable? I read (the archive of) Kris's blog post: https://web.archive.org/web/20170813190508/http://blog.koehntopp.info/index.php/2407-php-understanding-unserialize/ but that didn't shed any light. Zigzagging through the source wasn't getting me there as fast as someone who was there from the beginning. The reason for my question is I'm writing a blog post about a SaaS app that (don't gasp/laugh) returns serialize() format from one of its APIs. In discussing why the PHP format can make sense vs. JSON, I wanted to point to the faster parsing you get with length-prefixed strings. Then I started wondering about why we have both the length prefix and the extra quotes. Thanks, Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Mailing list moderation
Tony, you have a point in the sense that a proposed Code of Conduct -- which would have been binding on posts to lists @php.net -- provoked a fiery debate (to put it mildly) and was eventually withdrawn (http://news.php.net/php.internals/90726). The dominant objections to the CoC did not focus on relatively apolitical cases like calling someone a habitual liar or implying non-augmented humans can write bug-free code. Yet the point remains that there is no doc whose letter or spirit can be debated, AFAIK. As Stas points out, having a CoC for the list would not be a free speech issue in the wider sense. But in the *absence* of such a yardstick, I do agree with you that there's nothing to justify ejecting you from the list. You obviously love using PHP and do not come here simply to bash the language (to me, that would be grounds for ejection because one would not legitimately be joining the community, in essence a spam signup). While I don't agree with your technical viewpoint in the recent flame war, perhaps you do still have the right to express it here without fear of suspension/ejection. But consider this takeaway: while you may not realize it since you're in too deep at present, the (scalar-pseudo-type-related) war you're currently in with the other fellow has devolved into silliness. Neither of you are in my killfile; more the reverse, as it's become so over-the-top that it's funny. I know, though, that you take this topic seriously -- but the way things are going are entirely comedic, with accusations of fabulism (I don't know where that's from) met by accusations of lack of coding skill (just as unlikely for a longtime Internals participant). Assuming you'd rather we take the technical aspects of the debate seriously, for that reason alone it's worth a reset and a rethink. —— S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's mail servers suck
> > the wording "bounce" is wrong as you don't send active mails, you reject > messages FYI, while incorrect, the wording comes from ezmlm, not Aidan: Messages to you from the internals mailing list seem to > have been bouncing. I've attached a copy of the first bounce > message I received.
Re: [PHP-DEV] [VOTE] Reserve even more type hints
rather than having a single untyped parameter amongst typed ones Yes, when experimenting with strict types, I'd rather move things in and out of 'mixed' than remove the notation completely. Like you said, 'mixed' means, I've reviewed this area and concluded it needs to be dynamic. Also, maybe I missed this upthread, but are the docs still going to refer to 'mixed'? -- Sandy
Re: [PHP-DEV] Reviving scalar type hints
I like 2) No possible confusion, and it's a clear tag. I agree, but it feels like it gets away from PHP's underscore-heavy syntax. The poll omitted ?php_strict -- that feels most PHP to me. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http
Caching connections within the same request and reusing them is not spooky, but caching them long term, across requests, across security domains, for extended time - is spooky. This is exactly what reverse proxies like Nginx and the Akamai CDN do: reuse the connection between the proxy and origin even after the browser endpoint has disconnected from the proxy. Like Mike said, it isn't spooky, since the reuse of an HTTP persistent connection makes no claim about HTTP state. Heck, Firefox could take over Chrome's HTTP connections and it would still be to-spec, regardless of whether they shared credentials. Of course it is incumbent on the remote server to keep things stateless above the TCP level, but if it can't do that it shouldn't advertise persistent connections. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Scalar Type Hints
...cases that make sense to nearly everybody for abstract bondage-and-discipline notion Well, the 50 Shades of Grey movie is coming out soon, so let's wait and see how that does. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Faster zend sorting implementation
Sounds more like a bugfix to me and def'ly an acceptable BC break in
either case. The behavior isn't specified and if anything I would
assume there _wouldn't_ be a swap with SORT_FLAG_CASE on. Interesting
though that many sorting examples (across languages) sidestep this
clearly common case.
-- S.
On Mon, Jan 5, 2015 at 12:36 PM, Xinchen Hui larue...@gmail.com wrote:
Hey：
On Jan 6, 2015, at 1:27 AM, Julien Pauli jpa...@php.net wrote:
On Mon, Jan 5, 2015 at 6:09 PM, Xinchen Hui larue...@php.net wrote:
On Tue, Jan 6, 2015 at 1:08 AM, Xinchen Hui larue...@php.net wrote:
Hey:
I was working on zend_qsort improvement. but I got a problem need
to be disscussed with you fist..
first
as we know, previously zend_qsort is not a stable sorting algo.
my draft patch (which already get 0.1% IRs reduce in wordpress)
is kindof a stable sorting algo, you can find it here
(https://github.com/laruence/php-src/compare/zend_sort)
so, there is a bc break, like for :
$array = array(o, O);
sort($array, SORT_STRING|SORT_FLAG_CASE);
var_dump($array);
previously implementation does the swap:
array(2) {
[0]=
string(1) O
[1]=
string(1) o
}
but new implementation doesn't not:
does not
array(2) {
[0]=
string(1) o
[1]=
string(1) O
}
Hum, I dont think such a BC is acceptable.
I am not sure if you get the problem?
O and o are equal is that script
The flags means using case-insensitive string sorting mean
Thanks
There are tons of userland code out there relying on alpha case sorting that
could get impacted
IMO :-)
Q: why extract the swap function from the qsort algo ? Is there an interest
of replacing it at runtime ?
Julien.P
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
I think that usage may have originated in PHP, actually. Eh, dunno about that... http://lists.w3.org/Archives/Public/ietf-http-wg-old/1995SepDec/0277.html for example. Even some W3C specs use header instead of the more accurate header field so it's kind of a done deal. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
Nowhere did I suggest that the request verbs themselves (i.e. PUT and POST) have the same intent. Just that the handling of multipart-form data is not specific to either one of those verbs. Define handling. :/ Handling as in interpreting multipart/form-data as key-value pairs: a specific, intimate relationship with POST exists in RFC 1867 and in the HTML4 and 5 specs. These documents show the relationship between POST and multipart/form-data to be a very special one, one in which the innards of a form-data entity-body are meant to be expanded at runtime to replay the individual fields of an originating form. There is no such document that relates to PUT. Handling as in accepting data that happens to be multipart/form-data: of course that's not method-specific. It's not even HTTP-specific anymore. As of RFC 2388, form-data can be sent from Adobe Acrobat over IPX/SPX to an AS/400. That's great, it's a real standard. MIME decoders/encoders will grok it as a specialization of multipart MIME, and apps can apply stricter validation than for multipart/mixed (for example, mandatory part names). The expanded standard also means that intermediate systems may be designed to *transport* or *save* multipart/form-data messages instead of *reading* them. Which brings us back to the point: hands off PUT entities, unless there's overriding local knowledge that they must be read instead of stored. I see no reason why this would be a negative impact on PHP. Because if someone PUTs 2 GB of multipart/form-data I don't want it decoded just because somewhere in my code path there's a reference to $_POST. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
Specifically, parsing the form data and populating it somewhere accessible to the user as it is today in $_POST and making any binary upload available in $_FILES or some other fashion. Ideally, making handling PUT more consistent with the way PHP handles POST. OK, the first definition: handling means parsing multipart/form-data automatically into form field names and values. And again there are specific documents that expect this to be done for POST (and understandably so) but no such documents for PUT. Which means you want PUT to act as if it were as formally defined as POST. Which is where we started from: you are transplanting a standard from one method to the other. This doesn't mean you are violating an extant standard, it just is very, very far from compelling. And your best justifications for a present-tense need were wontfixes submitted by relative newbies. First of all, RFC 1867 is not a standard. It's an experimental protocol definition. Oh nonsense. You know very well that RFC 1867 conformance is an industry standard for file uploading When 2388 says originally set out in [RFC1867] and subsequently incorporated into [HTML40] it is not treating 1867 as some fringe document. Non-HTML uploaders (Flash/Java/Silverlight/cURL/all of them) use RFC 1867 as their design spec, not as some wacky experiment. http://lmgtfy.com/?q=rfc+1867+file+upload+support No where in the internet standards tracking documents do I see a definition that restricts multipart/form-data to POST. You're deliberately phrasing it backwards. The documents re: POST enshrine multipart/form-data as one of two encodings. There are no documents re: PUT that refer to form encoding. And I never said there was a restriction; in fact I specifically outlined how 2388 breaks all restrictions on multipart/form-data. However no restriction !== an automatic connection. I think what you're referring to is the fact that the client UAs typically only ever handle form data as multipart/form-data mime as POST-specific requests. This is of course tied to the fact that client UAs don't typically follow the same intents of a RESTful API client/server relationship. Allow me to re-iterate the fact that this is one of the primary focuses of this discussion. That people normally want to deal with PUT requests in PHP under the umbrella of building their own RESTful APIs. Show me the RESTful justification for decomposing PUT requests *automatically*. There is none. There may be local knowledge that justifies decomposing PUT requests as if they are POST-like but it is not RESTful. I've read all the REST cookbooks there are. You're trying to make this a thing, and it's not. It's the same thing as with a POST request today in PHP. Nothing is stopping anyone from sending a you 2 GB multipart/form-data POST request either. Stop moving the damn goalposts and stay on topic. We are talking about a ***PUT*** today in PHP. Right now, that doesn't cost me anything. In your model it can cost me a lot. We have plenty of ways of warding off oversize requests depending on method. should be checking intent before dealing with $_POST from the $_SERVER['REQUEST_METHOD'] anyway, since you can't relay on $_POST necessarily being indicative of the request method anyway. Certainly with your new feature one would be ill-advised to assume that anything is what it seems. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
PUT is not intended to necessarily store the request entity body on the file system. Its intention is to store the entity body at the request URI. I never said it was. I used the expression store at the URI about 10 ten times on this topic. You are arguing in bad faith by putting words in my mouth. Stop. In a barebones implementation with just an HTTPd, PUT does mean the filesystem, which gives an easy example of how incredibly semantically different it is from POST. Most people do not understand the concept unless you give them a simple example. So this unfounded claim that decomposition should not happen within PHP at the request level, isn't a justification for prohibiting PHP from decomposing the body. I made no such claim. I maintain that decomposition not be *required to happen* within PHP. I couldn't care less if you make it optional and don't use the $_POST superglobal. I've said this over and over. Expose the core MIME parser to the user. That'll make it easily used by frameworks, or via auto_prepend_file. Do not do it automatically for all requests. For example, if the Content-type designated in the request indicates application/binary it is safe to say that PHP should not attempt to disassemble the input stream beyond applying the decoding from the Content-encoding header (which may actually happen at the web server level). However, in this event it would make it a lot more convenient for the client if the entity is stored in $_FILES where its access is still more manageable through the receiving code. I noted this case in the other thread and let it be laughed off, but I actually believe that this is a relatively sensible option, since it doesn't require any decoding. For that matter, I ninety-percent-kiddingly wondered if an application/tar body could be decomposed and its constituent files put into $_FILES, since that's a case we actually use daily. Again under user control, and not for every request to a given PHP install, but a kind of pre-superglobal API would be cool. Of course I know it'll never happen and I'm fine with that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
Prove I believe a multipart/form-data mime cannot be sent along with a PUT request using messages I have sent to this list. You are basically lying for effect at this point. I never said that, took pains to explain that I am not saying that, gave examples utterly to the contrary... yet you make stuff up anyway. I'm done with this. I hope you find a more honest way to defend your proposals in the future. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL
FWIW, there *is* a practical in-use (de facto if nothing else) convention of using _ in hosts for DKIM: _domainkey is actually in all the DKIM RFCs and in the formal STD 76, see § 3.6.2.1. Namespace, so it's more than a convention! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
For the umpteenth time, *in what situation must you PUT multipart/form-data or multipart/x-www-form-urlencoded only to treat it, semantically, as a POST*? Which UA cannot send a POST? It's like we're completely upside down on this thread. If you're PUTing such POSTful content-types for any reason other than storing the entire resource, you're doing HTTP wrong. Truthfully: if someone said, Yeah, so we got into PUT lately, we use it for Ajax form, er, posts, for, um, speed or something, would you not be like, Wat? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Standardized HTTP Interface
The HTTP specification doesn't restrict how the request body is encoded based on the request verb. I never said it did... please don't put words in my mouth. As Will notes, you're sidestepping the point, which standards-savvy people have been driving at for years: the semantic differences (== intent, == meaning) among HTTP methods. HTTP specifications *do* define -- in your words, restrict -- the intended disposition of the entity-body based on the HTTP method. The methods *do* distinguish whether the entity-body is intended as a precomposed resource to be stored at the request-URI (PUT) -- or whether it may contain key-value strings, multipart MIME data, or arbitrary text and/or binary data ranges (POST) which must be interpreted by application code at the request-URI (which must itself exist) as they have no inherent final disposition. It's easy to certify the semantics in your lab. Set up a capable web server with no preprocessor at all (no PHP, no SSI, nothing). Choose a URI that currently returns a 404, like /test.abc. PUT a well-formed multipart/form-data body to that URI. What you will get is the entire multipart stored within the filesystem at the mapped URI. And provided the server's file extension - MIME mappings are consistent, you'll then be able to GET the file as multipart/form-data. Now POST that body to another nonexistent URI. You'll get a 404 or 405. Full stop. This core difference is really not that hard to understand, and there's no reason for PHP to act, stupidly, like it it isn't there (as in make-people-dumber stupid, not make-life-easy stupid). multipart form data is useful for including both form data and binary data with successive parts Of course. Multipart MIME is also key to the modern e-mail ecosystem. And, similarly, multipart e-mails are kept as opaque as possible in transit. Antivirus and spam scanners need to peek inside multipart mail, but they don't decompose them and put the parts back on the wire separately, because that is not the meaning of transfer this e-mail. Neither do end-user apps aim to decompose MIME messages when they're idling in a message db, because that's not the meaning of save this e-mail. On the other hand multiparts *are* intended to be decomposed by mail apps when a user opens them: in that case, there's a clear semantic justification for expanding the contents for the user: read this e-mail. In sum, multipart is useful is quite obviously true, but it's a straw man, as it does not respond to the question about expanding multipart entities in all contexts. but many APIs may apply a PUT request using multipart form People do dumb things. You haven't answered why they would fixate upon PUT, since they cannot possibly lack support for POST. What, now for the umpteenth++ time, is the technical/business/personal justification for this design, with POST available? Again this whole debate is upside down. People have to *choose* to use PUT, even in cURL. It doesn't happen by accident. It's not the XMLHttpRequest default. It can't happen from an HTML form. Why are they doing it? https://github.com/symfony/symfony/issues/9226 If you read that report carefully you will see that it starts with people name-dropping POST and PUT (because they don't understand the difference), including bugs that appear to deal with POST alone. Then, the feature request that does appear PUT-related is shot down by the Symfony maintainers. Obviously, it wasn't wontfixed because it couldn't be done, but because there was insufficient cause, despite the initial claim that Symfony's update API was broken. https://www.drupal.org/node/1270190 A wontfix bug report that doesn't even try to justify why PUT would be used, only that it doesn't work. If a newbie confuses POST and PUT when creating an Ajax object, is that a bug on the server? http://uncorkedstudios.com/blog/multipartformdata-file-upload-with-angularjs There's no mention *at all* in this post of a need for PUT, just a note that Angular applies the same default content-type to POST and PUT. https://bugs.php.net/bug.php?id=55815 I see no compelling use case here, only an unsourced claim that every RESTful interface would make use of this feature, which would be better phrased one particular not-at-all-RESTful interface. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
$_FILES (whose name is already method-agnostic) The name appears method-agnostic but the implementation obviously isn't. It works with multipart/form-data, which is tightly coupled with POST, but which isn't the only way to transfer files, not by a long shot. If you ignore the HTTP method you're being completely arbitrary if you still only decode form-data into $_FILES. For example we PUT and POST bytearray/binary files thousands of times per day. You can PUT application/xml as a valid file, heck, you can PUT a tarball, a great way to send multiple files. Would the enhanced $_FILES be populated in those cases? And if not, why not? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. In addition to PECL HTTP, you might try PECL Mailparse, which is also going to be better-tested than anything written in userland. I sympathize with your overall point: even without a new superglobal, it would be cool to be able to reuse the same parser from $_POST. Still, just to put this out there: receiving multiparts via PUT can be part of a legit RESTful interface, but that doesn't mean that decoding multiparts should be automatic. It shouldn't be surprising that it PHP treats the entity as an opaque block of data by default, since it's perfectly RESTful for _the MIME-encoded body_ to be the stored resource. Imagine an e-mail archive that PUTs to /user/$username/sent/$messageid. Decoding the MIME message on resource create/update would be inappropriate in that case, a huge waste of resources. You might lazy-decode the resource only upon GET /user/$username/sent/$messageid/part/1. Within the same installation, you might want to decode other PUTs upon upload, so having a simple on/off for a new superglobal wouldn't work. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
You're right. Guess the build system didn't update http://pecl.php.net/package/pecl_http with the DLL link as for other exts. -- S, On Mon, Oct 27, 2014 at 12:31 AM, Will Fitch willfi...@php.net wrote: On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureone...@gmail.com wrote: pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downloads/pecl/releases/http/. Did I miss something? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably If the quibble were with file_get_contents(‘php://input') that's not sufficiently uncomfortable to warrant a new superglobal. I assume you mean parsing the contents of php://input into an associative array regardless of the content-type of the HTTP entity-body. However, you're glossing over the semantic difference between POSTing an entity-body and PUTing that same body. multipart/form-data is specified in RFC 1867 as POST-specific, with deliberate notes about expected server behavior. RFC 2388 expands form-data into a general mimetype regardless of transport, and theoretically regardless of HTTP method, but AFAIK there's no equivalent to 1867 that reasonably leads to auto-decoding PUT form-data into an associative array. Rather, the PUT payload has always been designed to _become_ the target resource, as-is. The POST payload is designed to be interpreted via the server's own semantics before changing any resource state. Thus there is a very strong reason to present POST data to the server in an easily accessible and mutable form. Not so for PUT. This doesn't mean PUT payloads must stay opaque to PHP, of course. If there's a need to validate the payload before overwriting the current resource state, that may require that it be passed through some binary image verification, validated against a DTD, or -- indeed -- decoded from multipart MIME into its parts for validation, even if it's the multipart representation that eventually gets stored. Yet if you feel that PUT content should be automatically decoded, you might as well apply this to other multipart content as well -- if I PUT an MHTML file or, as noted before, an RFC 822 e-mail, by this assumption those would also populate the new superglobal. Honestly if it didn't consume any extra resources to always populate, I wouldn't care. But to be unable to avoid decoding every giant multipart payload just because I _might_ want to look at the parts is highly inefficient. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
You can already do:
$a = 1;
$b = 2;
switch( $switch_value = $a + $b ) {
default:
print $switch_value;
}
No magic or new operator required
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Little switch improvement: get the used variable
Hi Martin,
The `get_the_used_switch_variable()` is just a placeholder, name can be
changed to something natural...maybe a constant.
I feel this has diminished utility once you consider that the switch
variable is actually an expression and could well include multiple
$variables. Plus there's also the pattern switch(true) { } where the
interesting variables appear in case statements. Hard for me to see
the justification, but maybe I'm missing it. My $0.02...
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
I don't think you tracked the behavior in the bug report.
If checkdnsrr() is doing an MX query -- not including implicit MX,
only explicit MX -- it must fail when there is no MX record. It can't
return `true` when there is a CNAME (and no MX record for the
canonical hostname, only an A) but `false` when there is an A (and no
MX record). That isn't an MX query, nor is it the way smtp-senders
operate, now or 16 years ago.
To quote the bug report, if somehost.example.com is a CNAME for
example.com, and example.com has an A record but no MX,
checkdnsrr('somehost.example.com') must not return different results
than checkdnsrr('example.com'). Either the function is trying to be
smart and emulate an smtp-sender (bad idea) and succeeds on both, or
it stays dumb and fails on both.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
if somehost.example.com has the MX, it should return true with
checkdnsrr('somehost.example.com'). If example has the MX set to
somehost.example.com or similar, it should return true as well. Or am
I missing your point?
You are missing it, as there are no MX records involved. I'm
demonstrating that the function gives incorrect results in the absence
of an MX record because there is a bug in CNAME handling (or a bug in
A handling, if you prefer).
somehost.example.com has no MX RR. It has a CNAME (per DNS rules, the
CNAME must thus be the only record for somehost.example.com). The
CNAME points to example.com.
example.com has no MX RR. It has an A pointing to 1.2.3.4.
checkdnsrr('somehost.example.com') should return false. It returns true.
checkdnsrr('example.com') should return false. It returns false.
You could try to revise the docs and say, Oh, it doesn't really mean
an MX lookup, it means an explicit MX *or* implicit MX, like how a
basic smtp-sender works. So that's why the CNAME -- A one returns
true. Except then 'example.com' should return true as well. It does
not: it returns false. Changing the docs does not fix the bug.
BTW, I've been reading SMTP RFCs since we were on good ol' 821, and
I'm plenty intellectually curious. I don't care if a function is
supposed to partially emulate an smtp-sender when verifying a domain,
or if it's supposed to run a dumb DNS MX query. It either does what
it's supposed to to do or it's broken.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
Hi Mike, So it could still be seen as works as expected, because it just checks if any answer is received. If that functionality is useful could be debatable. That's not expected. Chasing (dereferencing) CNAMEs is one of the understood burdens of any DNS app; you can't treat the CNAME itself as a positive response. Luckily standard apps don't rely on DNS-to-boolean conversion like this or else the 'Net wouldn't work. I'm glad you see I wasn't blowing smoke here. -- S. P.S. chekdnsrr() does the same thing for CNAMEs w/other RRtypes as well, by the way. It'll confirm that www.php.net has an SRV record. I mean, geez... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
Hi Kris, On a broad level, your RFC asserts that checkdnsrr() is used to determine whether or not a hostname exists, but you don't actually define exists. It seems to me you're glossing over the fact that existence is application-specific and doesn't add up to one single RR type or set of types. For example, when setting up a web hosting account (www.example.com), or, say, an organization-wide account for a web app (sharepoint.example.com) when example.com's DNS is managed by the tenant, we may want to determine whether the hostname exists: Is there an A or CNAME RR in the DNS for that hostname? [1] Of course, that A/CNAME needs to eventually point to your servers to be useful, but with this barebones, non-professional-grade check, we could at least tell the tenant they pre-created a record successfully. (Or, contrariwise, we could tell them the hostname already exists, so it may already be used by one of their other apps.) Note if checkdnsrr() did an ANY query, `true` would be meaningless in this context. It would be an instant false-positive if there were only an SOA and a coupla NSs. But when setting up a new user for a different kind of app, we may use their e-mail address (j...@example.com) as their username and we'll most certainly use it for a verification e-mail. Here, we might quick-check whether example.com exists in the mail context, giving a reasonable expectation that it will accept mail (maybe not ours, of course!): Is there an MX, A, or CNAME RR in the DNS for that hostname? [2] This is a different, perfectly valid way that a hostname may exist. Note again if checkdnsrr() defaulted to ANY, `true` would be meaningless/misleading. And also note (I'll explore this again below) that an MX record is not required to accept mail. You can't decide that a domain is SMTP-nonexistent just because there's no MX. Users will just be angry if they are already receiving mail and you tell them their address hard-failed your preflight check: warn them, perhaps, but leave it up to the SMTP layer to make those hard decisions. For another example, if you run a purpose-built DNS management app, you may want to know if a domain is in the DNS at all: Are there simply SOA and NS RRs in the DNS? This is another completely valid meaning. You wouldn't want to check for CNAME, MX, or A here, since none of them are mandatory. True, you could in theory waste your resources on an ANY query for this one. But it is not a compelling reason to have ANY be the default. For yet another example, if I'm building an SPF test tool I want to check if TXT or SPF/99 records exist for the hostname. I don't care if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF record solely to discourage Joe Jobs doesn't need to prove its existence in any other way. I mean, that's the thing about DNS. It serves tens of different purposes. It's not possible to assume what people are looking for when they build a specialized PHP app. It could very well be that an app doesn't ever test for existence of A/CNAME, but only existence of SRV records. Or only PTRs. On one note I fully agree. The defaulting to MX sucks. But as others have pointed out it's a BC break to try to manipulate the arg list at this point in time. I think it would be good, maybe, to update the docs with something like (though less clumsy): This function's default behavior is to verify the existence of MX records for a hostname. MXs prove the domain owner's intent to receive mail. However, a result of `false` does not mean a domain *cannot* receive mail, as MXs are not mandatory. Perhaps try to condition people to be more aware of what they're looking up and why. As someone else said in the original thread, it's not too much to ask that PHP users who decide to use DNS functions know what they're looking up. Oh, and I also just caught a bug in the default behavior anyway. Gonna log that now! -- S. [1] Here and elsewhere A means A or , although as of late 2014 the IPV6 variant isn't sufficient to establish existence on the public 'Net. [2] I'm deliberately setting aside the vario us CNAME interactions with MX records, which may result in successful mail delivery in many, but not all, permutations: it may be safer to consider such setups broken, as long as you let the user confirm Yes, I vouch for my domain's setup/existence/operation even though you found problems. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior
What would happen is it'd throw an E_DEPRECATED for at least the remainder of 5.x, then throw the usual E_WARNING for a missing argument starting in 7.x with no default. Sounds OK to me now that I've noticed this: https://bugs.php.net/bug.php?id=68081 Pretty sure that's a sane report, and it's enough to make me say checkdnsrr() doesn't work now at all. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why does checkdnsrr() default to MX??
ANY (*) requests are key to many DNS amplification attacks and may fail, even if the RR you want exists when individually requested. Such requests should be discouraged by clients, IMO. It's disappointing that PHP's dns_get_record() defaults to ANY. But more to the point, what is the client-side utility? You are basically flooding yourself if you make such requests -- what exactly are you going to do with the TXT records, NS records, the SOAs, the unknown types? This is just a ton of extraneous data, even if the overall payload is small. Maybe if you're building a PHP app whose sole purpose is to troubleshoot DNS. But if so I would sooner fork `dig`, since most likely you are trying to show people the results that a non-PHP app would see, so better to avoid any PHP bugs/specialness and miss any DNS features (such as new RR types and new DNS extensions). I don't think there's anything particularly askew in MX being the default for checkdnsrr() if you think of it as a cut-down generalization of getdnsmx(). Still I can't remember the last time my PHP apps cared only about whether an RR existed, not its value (our mail server cares about that of course when checking blacklists, and we care when we're troubleshooting... but not within PHP). And I've *never *wanted to get a true/false *if there is an RR of any type, *as opposed to a true/false if the domain exists at all in the public DNS. Can you explain the use case? -- Sandy
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
I was just composing an e-mail advising you to follow general netiquette rules and read the original post. :) I disagree utterly that I did not sufficiently address the question. I addressed it in multiple ways: [1] ANY queries create extraneous traffic, so you want fewer PHP functions defaulting to them, not more; [2] ANY queries may fail, giving a false negative, when individual RRs would succeed; [3] An ANY query that only reduces to a *boolean *is a particular waste of energy and network traffic if you're trying to see whether a domain has any records, as you can use SOA for that, with no loss of fidelity; [4] *if* checkdnsrr() is generalized from dns_get_mx() that is another explanation I think [4] is actually my weakest point. -- S. On Thu, Sep 18, 2014 at 5:32 PM, Rowan Collins rowan.coll...@gmail.com wrote: On 18 September 2014 22:19:46 GMT+01:00, Rowan Collins rowan.coll...@gmail.com wrote: I hope this message doesn't sound too negative, and look forward to clarification of your thoughts. Apologies, I've just realised that that message wasn't in fact the beginning of the thread, so some of my comments are way off base. Out of context, it looked like a bit of a rant about how ANY could never be a useful option. Still, the only line that really addressed the question was this: I don't think there's anything askew in MX being the default for checkdnsrr() if you think of it as a cut-down generalization of checkdmsmx() (Sorry, that's not a direct quote because I'm having copy and paste issues.) Sorry again for the misunderstanding. -- Rowan
Re: [PHP-DEV] Why does checkdnsrr() default to MX??
... thought I just top-posted for the first time in, like, ever -- b/c I guess janky Gmail does that by default (I had to switch my subscribed address as php.net was deleting mail relayed through my ISP).
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
... ESPECIALLY since userland implementation is so trivial. Trivial for most users means copy-paste an unmaintained class library you found somewhere so you haven't solved the problem. Unless something comes from one of the few trusted security extensions or from a top framework, it's doubtful it'll be thoroughly reviewed and/or correctly implemented. I think security measures belong in the preprocessor if possible. If they are known to be useful, yet rejected only because they're trivial -- despite not being commonly available to the majority of PHP developers -- you are failing the community. On the other hand, if they are known to be useful, yet rejected because they're complex, requiring too many config options, new classes/functions, core documentation, AND user education to write companion logic in userland then I think that's better reasoning. And that's *clearly* the case here. This is not a simple implementation; it requires flexible control from userland and some delicate app logic to interact with the user, and the language can't do the last part AFAICS. As sketched out so far, it is outright harmful. I could publish a post now about the vulnerability it creates, where sniffing a session allows you to force an elevated login, from which you can sniff credentials. (Maybe my first vuln note was tl;dr but please consider this.) The core of the problem is education, not lack of tools by the side of the language. And that's where the focus should be. How do we do it? I don't know. Blog posts? PHP manual? Conferences? Maybe. The first round of objections showed that senior developers *on Internals* didn't understand how PHP session regeneration works! How do you solve that? If the language offered features like this in the first place, PHP users would have known about for years. The fact that it wasn't grokked here reveals that no matter how trivial' it seems, most people aren't doing it (as yohgaki noted) and not because they understand the consequences, they just don't get it at all. Again, if it were simple to implement and didn't have unintended security consequences of its own, the fact that the sharpest users don't totally get it would *prove* that it should be left to the internals team. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Let's be clear here: this won't happen (in most cases), because the client will simply get a new cookie and the session will keep working; it's like what you would implement if your user level goes from anonymous to logged in and vice versa. I'm glad you addressed this because I'd been thinking that a lot of people were misinterpreting the common (non-hijacked) scenario, thinking that session regeneration meant a client-facing logout, which of course it doesn't as long as the client uses the new id on the next request. The concerns about forward and reverse proxies (you would typically use x-forwarded-for in the second case) seem also off-topic; even going through multiple proxies of each type won't matter as long as cache privacy is respected and the end user receives the new id. (One can argue that the more individual HTTP circuits you need to traverse, the more likely packets will be dropped, but that seems excessively paranoid for discussing this feature. I do agree with the server-side performance impact of very frequent changes on the forward proxy side forcing thrashing of the session store.) But the main problem, to me, is handling the aftermath of a hijack detected in this way. First, the UX factor: is it really feasible to provide the user with feedback like You have been logged out for your protection because your session may have been hijacked by another user on your network -- now go find out which guy in the coffeeshop is listening! That's quite a challenge. I'm sure many of us have seen the white hat studies of just how easy it is to get people to ignore warnings in the browser chrome or from runtimes like Java and Flash: look up the guy who got his office of techie Tor users to ignore redirects between https and http! I suppose if the victim accepts that something security-related has gone wrong, they don't have to understand what it was as long they can do something in response, and the most actionable advice is You MUST leave this network immediately because it's insecure. But many people will ignore this message, and then (if I'm not misunderstanding the intent here) they will be prompted to log in again, on the same network. Problem: now the person who's still sniffing the network, who might have had only their session info before, can possibly sniff their username and hashed password, which is potentially much, much worse! (If a fresh login is over SSL but regular traffic is not, and the attacker was only using primitive sniffing of plaintext, that would be a mitigator.) Assuming a fresh login is not itself vulnerable, after authentication, do you offer (or force?) all other sessions linked to the user id to be expired? If so, this would of course include a legit session in another browser or device. In sum, I'm curious about the expected use of the feature _after_ the alert goes off. yohgaki? Aha! I'm glad that you brought up mobile devices, because for those it's more likely that in certain cases the updated cookie is not received while the server believes that it was; scenario: I stepped into an elevator and was disconnected when I got out.. This makes it an unattractive option to have enabled by default. Maybe the feature just needs to be disabled by default, yet not being able to protect against mobile session hijacking because of fear of lost responses seems like weakening it to the point of uselessness. I don't know the actual numbers, but I worry most about my users using their tablets in a coffeshop or hotel and if I had to turn this off for most mobile browsers, that would be a bit silly (AFAIK, there's not yet a universally-supported way of distinguishing wifi from mobile data, i.e. navigator.connection.type). We all accept that request-response cycles don't always complete on mobile, particularly on 3G, but I haven't yet seen anyone get metrics on how common it is based on network behavior _and_ user movement... also figuring that huge packet loss, once felt by the user, influences people to decide the network is effectively down and to not attempt any more requests for a while. It would make for an interesting study and forcibly changing a test cookie on every request (regardless of IP change) would be part of figuring out how bad the real-world situation is, at least for a given app and its users. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Users who are concerned for this situation should disable it. Users who are concerned security should accept this case. I assume users are as we understand them here, i.e. me. But as a developer-user I would likely want to empower my end-users to turn off this feature themselves. With high-volume sites (not that I really have any anymore, but a guy can dream) there isn't going to be a one-size-fits-all regarding connection quality, but there can be a default INI setting and then a function that we can call to override it. Paranoid users will turn/leave it on any user in a sketchy connection situation will turn it off (per session or for all their future sessions). Which is kind of why this is sounding more and more like a nice discussion... about a userland solution. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
When URL based session is used, this feature should be disabled as pages are cached by browsers. OK, I suppose, but that seems to be an edgier case than what we're already discussing. BTW, if connection is unstable and an app force user to logout, is it going to be a problem? It would depend on message displayed, but I guess users think it is due to unstable connection. I definitely (!!!) would not think that if an app forced me to log in again that it had to do with my connection quality unless I had already decided the connection was practically unusable -- and that all bets were off as to whether anything would work as expected. Even if I intuited the reason and/or was told about it, I would not accept being logged out of an app because I went into an elevator (to use Tjerk's point) or through a train tunnel as appropriate. At all. You're basically adding insult to injury: not only do you have a bad connection, but you need to always log in. Makes for a very, very bad user experience. I would hate an app that did that to me... if I encountered the situation. And what I was interrogating is _how common_ such a situation would be in each developer's real world, predicting it would be different based on the ecosystem of a particular app + its users. For example, my main app is too heavy for most people to use over 3G connections, period, so they are unlikely to run into the problem with us because they wouldn't be trying to use the site in the first place. Other apps have a lightweight version that is otherwise usable over slow/sporadic connections and thus its users are more likely to encounter timeouts, which the app has previously been tolerating. This why I referred to _the end-user_ (not _PHP users_) being able to turn such a feature off. Only a site that is 100% sure that it only is useable over WiFi/WAN/LAN should roll out such a feature without giving users control, because otherwise you are _ensuring_ your site won't work on 3G! Why would you do that if it used to work? If mobile apps are native, almost all apps store username/password or some credential that automatically reconnect to service. Native apps can have different levels of resilience -- we MUST consider sites that just happen to be accessed from mobile. And in those cases there can't be any question that being logged out because you didn't receive the updated id is not acceptable. The question is only _how often_ you are pissing off users, not _whether_ you will piss off a user when you do this. I also want to know how you deal with the other insult-to-injury that I mentioned, where logging out someone after a _real_ session hijack then reveals their credentials to the attacker who's still listening on the same network. I'm starting to think there are unintended consequences here that are approaching considered harmful levels. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Regenerating session ID automatically when IP address has changed
Under normal circumstances, entering elevator or tunnel would not loose session ID most likely since lost connection would not loose session ID. When end-users simply lost their connection, IP address wouldn't change. There's good reason to believe that the event of being assigned a new IP from a forward proxy farm will be triggered by the event of dropping and reconnecting to the mobile network repeatedly. So, in general, if ever there were a time to be sensitive to preserving sessions, it's when someone has a sporadic connection. I might be too pessimistic... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
I suggest you read this recent thread for related commentary. http://www.serverphorums.com/read.php?7,71 In there, I refer to your proposal as Contractual Call Super and I find it an interesting concept that helps avoid the advisory call super antipattern. However -- If the introduction of a new keyword is problematic, perhaps this same behaviour could be enacted in cases where an inheriting class has a constructor and the base class' constructor is defined as final i.e. rather than causing an error, the final constructor is executed first, followed by any other constructors in the hierarchy. -- this is a horrible idea. `final` has distinct semantic meaning. It means cannot override. It doesn't mean overrideable, but we'll call any/all supers before/after we run yours. It's a BC break. Fuggedaboutit. The feature you want isn't in the language -- maybe it should be -- and you can't change the meaning of existing keywords. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
Most often if I need a super __construct(), I don't need it exactly
before or exactly after the bottom constructor but at a specific point
where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly implemented, the Call Super
antipattern by putting the call at the bottom of sub code.
It's true that it's an antipattern regardless of advisory placement.
But to me, somewhere-in-the-middle is even smellier than usual, since
in human hands that's got to be more prone to failure.
I think if Contractual Call Super were considered for the language it
should have before and after variants, not just after. There isn't a
practical way to declare at some point, is there, even if you wanted
it?
What is the typical use case for calling all supers (before or after the
class' __construct itself) ?
I can't think of a valid case in my memory for _all_ supers. Typically
you mean to call the immediate super _or_ the root super. Which is of
course the problem with the advisory form of this pattern, since
innocently inserting an intermediate class breaks your code.
If this feature were introduced, I see no reason for it to be allowed
to call more than one method for each occurrence of 'sequential'
keyword.
That is,
class A { sequentialBefore function __construct() {} }
class Asub extends A { function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct and then Asubsub::construct()
class A { sequentialBefore function __construct() {} }
class Asub extends A { sequentialBefore function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct, Asub::__construct, Asubsub::__construct
class A { sequentialBefore function __construct() {} }
class Asub extends A { sequentialAfter function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct, Asubsub::construct(), Asub::__construct
I'm not particularly cheering for this feature but enjoy thinking
about how it might work. If you see my notes on the previous thread
you can see I'm pretty adamant about Call Super being very bad
_unless_ it's baked into the language in an interesting way.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
No, that's why I am asking. Why is it an anti-pattern to call a known super constructor? Guess I'd send you to my comments in the earlier thread as I think I exhausted my ability to dismantle (advisory a..k.a. pretty please) Call Super there. Or ?call super antipattern. Of course, most every antipattern began as a brand name for a common approach, then once it graduated to a non-judgmental recommendation the backlash began. The cynic in me knows that some patterns are declared anti- so they can make developers feel cool about their code even if it works no more efficiently, is no better documented, and is only negligibly more manageable than uncool stuff. Nevertheless I find the arguments against Call Super compelling even in a closed environment where you control your own API. YMMV... -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
Not that it would be an argument but just for understanding: Do you know any scripting language which has this? Dropping the scripting part... IIRC, C++ calls ctors without arguments automatically like in my 'sequentialBefore' napkin sketch. C# has language-level support for 'sequentialBefore' type logic in its initialization list as well (which helps to smooth away the anti-ness by keeping it out of the ctor code). Also, here's a fascinatingly stupid bug-as-feature in AS3 (which I don't remember anything about, having used it basically procedurally along time ago) http://blogs.adobe.com/cantrell/archives/2008/09/be_careful_how.html. (Call Super hoisting out of conditionals? How could that have seemed like a good idea?) So there is precedent for Contractual Call Super. I don't think the above implementations are ideal, though, so if someone did go down this path I think it should be (a) not automatic but dependent on keyword(s); (b) flexible as far as executing before/after; (c) deeply-thought-through as far as its impact on class hierarchies that expand and contract over time. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
I've been thinking about this for a bit and even if you are right about being nice to have a way to call a function always after constructor. It could happen. You could have a DB class and in constructor the user/pass/host/options and then a separate method for init(). But that's not Call Super. Call Super specifically refers to always calling an overridden method of the same name (and usually same signature in languages supporting overloading) in a base class (usually the closest parent). Let's not mix up concepts: the relationship between methods of the same name in the a class hierarchy has specific semantic baggage, if not a single agreed-upon meaning, thus how some people say you should always be able to call super while others say you should never just assume you can call super *and* should never author an API that requires it and still others say you can't assume, but the requirement happens, and when it is required the language should be able to enforce the requirement. But more often than not, I want to be able to dictate what the program is doing when I'm using libraries and so on that I'm extending, not the libraries do stuff on their own. The question regarding Call Super isn't about libraries doing stuff on their own vs. stuff you dictate. It's about doing stuff on their own vs. dictating that you remember to do stuff for bug-free operation, being unable to do that stuff on their own. Languages that have Call Super as a flexible, baked-in language feature are able to contractually ensure Call Super _if a superclass author chooses to use the pattern_. Doesn't mean you have to use it, but it means you don't have to cross your fingers if you do use it. (In the case of C++, you're always using the pattern if you have a base ctor.) Languages that don't support Call Super still have to support code using the pattern in the real world, because not every user will use the alternative Template Method due to seeming complexity (even if TM is less prone to error). But those languages won't offer any way of catching omissions in a subclass. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
In my opinion UTC is a good compromise. I agree that _in the absence of any other setting_ there's nothing wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off default rather than issuing a warning. Non-technical end users will guess you're on London time but whatever. I am simply making the point that UTC is not the default default even when sysops or devs put their hands in. The choice isn't just UTC or what the end user personally sets. Domain time exists, no matter if Pierre has experienced it or not. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
And if you think 'London time' is UTC then you will get just as many problems half of tbe year. I said the *end user will assume* UTC timestamps are London time. Not that London time is UTC. People try to fit what they see into something they know. People in US-East see stuff 4-5 hours off, that's what they think. I hear it all the time: I think they're in the UK. A one-hour shift doesn't make them instantly have a come-to-UTC moment. Anyway, that's the unavoidable consequence of defaulting to UTC for storage and display. That's why using domain time as the display default is preferable, when there is a relevant one, further allowing people to set their tz as applicable for their session or user profile (profile == default for future sessions). I do not believe in forcing people to choose this setting before passing authentication in any old web app, as putting up such a barrier can be obtrusive; also, for our apps, it can lead to confusion because the domain time is always known, so we put the option in the user's control panel but don't lead them to it. I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default and changed only based on end-user input. I think there are five legitimate levels of consideration (storage tz, sitewide display tz, domain/corporate display tz, stored user profile tz, and transient session tz). -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
It can be perfectly ok to allow the lib to be extended and the constructor extended/replaced with a compatible one. Well sure, it's great to override constructors completely. If the lib authors didn't want you to do that, they should've made it final (which is what I said they should do now). You have every reason to expect this will work and keep working. Without call super. But extending a constructor in some made-up way where you override and just *guess* you need to call super if one exists -- after your additional code? before? why one over the other? -- without any formal documentation at all about the consequences? I think that's a stink bomb and I'm sticking with that view. It's like you're treating the superctor as simultaneously opaque and knowable. Say it happens to work at first b/c you don't touch any resources that the superctor needs, or you assign them and the superctor runs afterward and resets them to a workable state (unbeknownst to you). For the sake of argument, let's call this compatibility instead of luck. And how do you keep it compatible? You don't. They could change the superctor signature (oops! you're out of luck because you don't pass them what they need). Internally, they could change what resources superctor expects you to leave alone, what it doesn't, and in what order. It's simple to break this kind of thing, where a third-party doesn't want you to do something but they forgot to stop you. Either the lib author needs to add an empty constructor into every class just to make sure that it will be there to provide a painless upgrade when the need arises for a constructor There's no guarantee at all that it will be painless, because the signatures could mismatch, not to mention every single other dependency being subject to your guesswork. If the authors change their approach, it should be to the Template Method/subinit pattern, not making an official Call Super reqt that'll still be doomed to failure. otherwise the lib consumer has to write boilerplate to make sure that the parent constructor will be only called whet ot is there. Which is still just a guess, and basically doomed. Why would you think you can run an opaque parent:__construct() at any time? I would never just trust that. And I'm hardly risk-averse. :) Look, my gripe isn't with silencing/catching the call to unknown methods in lieu of method_exists(). If that gets easier to do in the language, fine. But I think this use case stinks as a justification. Still, I'll lay off after this e-mail because I will have said my piece. :P Your example also shows an overengineered solution for a simple problem. But it's 4 lines long! The rest is comments and examples of usage. And it's a _real_ solution to the problem, so it could only be overengineered vs. something else that is functionally equivalent. The Template Method pattern ensures that the child classes do not need to remember to invoke a particular method within their initializer. Simply by having an init() method in your derived class, you ensure that upper-level dependencies will be taken care of, and you don't have to have an init() method at all if you don't want to, or you can have an empty one with no side effects. The initialization hierarchy is baked into the object model at the outermost possible layer (since you can't go one more level out into language constructs). This doesn't mean you don't need documentation of what you should/shouldn't do when you init, but it is way closer to being manageable over time. The Call Super pattern requires that the user remember to call within their ctor code, and even worse, the situation under discussion is truly the worst possible argument for the pattern, since _you don't even have any word from the library author_ that call super is recommended or required... so not only can you not enforce the contract, you're making up the notion of the contract off the top of your head. Cheers regardless -- -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Then set the TZ to UTC or whatever else fits your needs. Server side TZ from a php point of view can be set to whatever you want, be at the php.ini level or in your application configuration (and call the appropriate function). Was there something that indicated I don't know how to do this? I have always done it and have no problem with it. I don't mind how it works now at all. Lester's point is UTC is the right default (and thus the battle over the E_WARNING should be settled that way). I happen to agree with that part, but disagree from heavy experience with the notion that UTC or end-user-selectable is the only choice you have once you set a value. Let the user has an option and use this option to set the right TZ at the beginning of each request. That's what every tool I know does. (a) You don't know all the tools in the world. (b) Please show me how every major web app gives you a clearly visible and encouraged option to set the tz _at the beginning of each session_ (I don't think you mean request). Happy to send screenshots to the contrary. (c) When a web app lets the user change her/his profile parameters (which is certainly common) this is irrelevant to their session (so if they change it when they're in City A, they have to change it again in City B and C as they jump around), (b) on an advanced setup tab somewhere. You're dead wrong if you think traveling telecommuters are always looking at -- let alone want to look at -- their local time. That being said, I do not knwow which apps you use to organize your time plans but all we used here do the conversion for you. Users hate, me included, to have meetings and other time related activities notifications using a different TZ that the one where I am (which can change). Well... that's not the way every set of organizations work, hate to break it to ya. For some apps the Chennai office is at least in part on San Francisco time. This can be because they remote in and don't constantly set the TZ in their Citrix session, or because they use a web app and, like most real users, can't be bothered to find the setting and are not in any way nagged to do so. This doesn't mean that some scheduler app doesn't display their local time _as well_ as the origin time. But have you ever seen the ol' wall of world clocks? There's a reason for that. I like to work that way and so to lots of humans. Then do it this way: - default in php.ini - override default is an user has his TZ option set I don't need these instructions, which are quite condescending. (And if you think *I* need them, how can this coexist with the fantasy that non-programmers always tightly manage their TZ?) -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
TZ setting is meant to be the timezone that your site is serving. Of course, if the site is meant to serve multiple zones, then UTC may be appropriate. But if your site is a local shop in Elbonia, then all your times would be appropriate to Elbonian timezone, because all activities are done with regard to this timezone. That's my view to a T... UTC is not the universal best-fit default, nor is end user-defined the only other fit. Depends. Plenty of sites are best seen as geographically fixed even if they have contributing clients who travel outside the local timezone. In general, I use the principle of domain time. If a site serves a (stock) exchange that closes at 4:00pm Eastern time, people hitting that site from all over the world are not going to necessarily remember that close-of-business is such-and-such UTC or such-and-such Tokyo. At best they will need to see the times side-by-side (like the example of world clocks on the wall). And the fact that our clients' end users see the time at corporate HQ by default is just another manifestation of the domain time principle. Some domains don't pretend to be timeless and spaceless. Note this doesn't mean all client software is ignoring roaming time -- we send iCal invites in UTC of course -- nor that, in our case, users they can't change what the site displays if they insist (though they rarely do). It's a question of the best-fit default. Of course, there are many sites for which the best default *is* user-defined or UTC, whichever is found first. It's just not a universal assumption. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
Encouraging call super is still not the right way to go about this. As
I said before, even with the changes proposed, there's no way to
*contractually enforce* the call super pattern in this language.
That's why it is and will remain an antipattern. So all you're doing
is allowing people to more easily use the antipattern, instead of (a)
baking auto-super (contractual call super) into the language or (b)
pushing people to use a preferred pattern (Template Method or other).
Template Method in userland is not difficult (lightly tested):
trait templateInitializer {
private $inited;
final public function __construct( $arg1, $arg2 ) {
print __construct in super calling inits...BR;
$this-init( $arg1, $arg2 );
$this-inited or self::init( $arg1, $arg2 );
}
protected function init ( $arg1, $arg2 ) { print init in
super...BR; $this-inited = true; }
}
class superClass3 {
use templateInitializer;
}
class subClass3a extends superClass3 {
protected function init ( $arg1, $arg2 ) { print init in
sub...BR; }
}
class subClass3b extends superClass3 {}
class subSubClass3a1 extends subClass3a {
protected function init ( $arg1, $arg2 ) { print init in
sub-sub...BR; }
}
new superClass3 ( null, null ); // runs root init
new subClass3a ( null, null ); // runs child init, then root
new subClass3b ( null, null ); // runs root init
new subSubClass3a1 (null, null); // runs grandchild, then root
You can extend this model to preInit() and postInit() methods, giving
even more flexibility. And in none of these cases does the subclass
need to remember to do anything.
This thread arose in response to what is undeniably a bad API
authoring practice (first allowing full ctor override and later
breaking BC without fanfare). Why are we letting the authors of
Richard's library off the hook and putting it on ourselves to develop
hacks? They obviously screwed up. What next? Do we let API consumers
override a `final` that they don't like? Just use the right pattern in
the first place. IMO.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot call constructor
I use some OOP library, that is a black box and I like it that way. Hmm, there's well-documented, change-controlled, trustable API that you shouldn't try to work around and then there's black box. I'm not sure the latter ever sounds like a good thing... I've always used it as a bad word. Suddenly my code doesn't work. Maybe the resource is only needed under certain conditions. So their __construct doesn't get called, but nothing bad happens until the circumstances where they need the __construct called. If their __construct suddenly becomes mandatory, they are deprecating something they (I presume explicitly) supported in the past: ctor overrides without call super. So either they put this in giant blinking text in their UPDATING file and you missed it, or they broke backward compatibility and didn't know it or didn't care. If I were faced with their situation, I'd make the ctor final to make damn sure you realized something was wrong. Then I would say overriding __construct is no longer supported because continuing to support it means mandating call super, which is an impossible contract for the language (this anguage) to enforce. I would abstract the whole thing out to an initChild() type pattern and so on. If you have to change your code, them's the breaks, as long as they give a clear path. I don't think the solution is to work around such mistakes on the part of a lib developer by silencing (?) calls to a nonexistent method _in addition to_ mandating call super -- IMO, that's even smellier than call super on its own. Why not add auto-super contracts to PHP instead (which would include skipping nonexistent super methods)? Making the undefined method error catchable instead of fatal I agree with, though. More like the more catchable world of Reflection. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] more secure unserialize()
And what about automatic un/serialize() of objects in $_SESSION?
People don't even see those function calls in their code, so dropping
the function/ality would be a wildly drastic move.
Nothing about it, the change is for unserialize() function.
OK. I thought of this as one core security issue with multiple
possible ways of getting a payload to the internal (C) unserialize
code. (If not, guess I could draw up an RFC for the other vector.)
It is harder to inject arbitrary objects into session storage than to
exploit blind-request-variable-unserialization type stuff (though the
latter can be a stepping stone to the former). But the potential
payoff in $_SESSION is so huge, I think having secure unserialize
for sessions is fully justified. Otherwise you're saying I can't
guarantee objects with killer wakeups/dtors were not injected via one
of the apps on my server, and I have no way to stop them from
instantiating magically provided they get through the right way.
We have to get away from mentality of if we need to modify some
behavior, we just put a variable in global state to control it.
Global state is the last resort, not the first one.
I guess it could be another argument to session_start() instead.
-- S.
P.S. Sure you'll shoot down this idea as well, but I think it would be
good if Filters had a corresponding validator, such as:
FILTER_VALIDATE_UNSERIALIZED: detect strings in PHP bytestream format.
Flags FILTER_ALLOW_SERIALIZED_SCALAR,
FILTER_ALLOW_SERIALIZED_NONOBJECT to fine-tune.
Otherwise, if you are still expecting bytestream format from the
client and want to detect tampering on input, you have to write a
best-guess regex to try to differentiate between 'Some:free { text;
}' and 'O:8:class:0:{}' and 'S:12...' etc.
.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] more secure unserialize()
This is not a good situation, and presently there are no way to avoid it except dropping serialize() completely - which may not be an option is some cases and in any case would require serious changes to the production code. And what about automatic un/serialize() of objects in $_SESSION? People don't even see those function calls in their code, so dropping the function/ality would be a wildly drastic move. IMO, there's a minefield of most surprise to worry about unless you tread gently, as in your suggestion of an extra param. And probably want two optional PHP.INI settings: one for when unserialize() is called automatically (so you can't pass it anything), and one for when unserialize() is called in user code without a second argument but you want a default whitelist to be applied (say, to instantly harden a codebase and sort out consequences later). -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method check - Can someone create a RFC for it?
Create something like $foo-bar?() or $foo-bar()?, where you don't
care whether the function exists, or if $foo is an object. If it
doesn't exist you just return null.
[1] Don't do this.
[2] What everyone else said.
[3] If you feel you must, this at least colors within the lines a
bit more than '@' by forcing you to set a class as wildcard-able:
class bitbucket {
function __call($name,$arguments){
return default value;
}
function __get($name){
return new self;
}
}
class myClass extends bitbucket {}
$myInst = new MyClass;
print $myInst-noExist-nexistePas(); // default value
[4] Goto [1].
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP Wiki] new user: fabpot
How do I verify it, and which projects are applicable? Does it depend on how many contributors it has? Users? How long it has been around? Commercial? OSS? Library? Framework? Applications? Websites? I've long had the same question. Not that I think I've earned such honor, believe me, but if you have a running commercial concern (i.e. web app) yet have never open-sourced your application code, can you ever be considered to have a project? Are there set boundaries for this? Thinking of Facebook, HipHop was obviously a huge donation on the OSS side, but what if Sara (and whoever else) weren't there? Does Facebook itself as an 800-pound PHP-based gorilla qualify as a project even if if it never open-sourced anything? Or would the worldwide PHP-based brand be like 99% of the way there, but they'd still need a non-frivolous OSS project? On the flip, several small-adoption, high-quality, stable OSS frameworks are out there that I think show great loyalty to PHP as a language (Konstrukt is one). But when do they become projects as such? Seriously curious. Having a karma-certified project might be an exciting carrot for people. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
While I'm thinking about this (though I should leave it alone): who's
to say that PHP won't some day get inner classes? By deciding the
default inner member of a class will be a function, you're choosing
the one that has a global/procedural equivalent where the short syntax
won't work, instead of leaving the concept unused for the possible
future when:
class myClass {
mySomething { // is equivalent to class mySomething {
(Yes, you could say mySomething(...) { } is a public function and
mySomething { } is an innner class, but you get the idea.)
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Global functions remain its requirement for keyword, just methods
lose
I understand that. You didn't read my post carefully because I was
noting this exact inconsistency.
it. And it doesn't mean that you can't write
class Foo {
function bar() {}
}
No, it means you _have to_ write it that way if you want the same
function definition to work in and out of a class. Like I said, I
expect the simplest function def to Just Work (as it does now) in
either scope.
This is not a technical BC break but a conceptual break that
disregards existing realities of refactoring (as well as realities of
who writes the code we end up maintaining).
What about readability - removal of this keyword will make a better
readability of methods. Instead of
abstract class Foo {
public function make()
{
// some code
}
public abstract function do();
}
You will need to read just
class Foo {
public make()
{
// some code
}
public abstract do();
}
That's no more readable to me. And even if I pretended to find it so,
I want to to read other contemporary languages with relative ease as
well, rather than being coddled by sugar that doesn't exist in other
C-style languages. PHP is not Java or C#, yes; yet the more
streamlined we get while those languages are adding actual features,
the worse off we'll be when we have to get the gist of something in a
verbose foreign language. And I don't want to drop function on the
server and then forget it in JavaScript. That's a net loss for me and
the millions of other users jacking both trades.
It's not function a keyword who lets you recognize function
definition/declaration, but it's usually a pair of brackets.
The function(){} construction is critical to recognizing a function
definition. Simply looking for curly braces is not sufficient, since
obviously a {} block does not mean you're in a function. {} is perhaps
more predictive at the second level of a class file, but in a codebase
in general it would be reckless to treat {}, or even (){}, as denoting
a function definition, since the former squarely does not and the
latter is more likely to mean an forgotten semicolon in real-world
code.
This function keyword is just noise for now, it doesn't serve any
purpose aside from typing grep 'function funcname' instead of grep
'(private|protected|public|abstract|static)funcname' , but, you
know, if you love shell so much (or are forced to use it) you are
probably familiar with creating 'shortcuts' for it, scripts or
aliases.
I could scarcely disagree more with your minimizing view of how people
seek and scan code.
I think I'd better stop discussing it as well -- I don't have voting
karma so good luck either way
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Classes always should be declared with class keyword, because there could
be ambiguity whether it's class, interface or trait.
If only inner classes are allowed in a given PHP version, there's no
ambiguity about whether something{} just inside a a class is an
inner class.
That's the justification for removing function just inside classes,
isn't it? That it's not ambiguous because the only thing as of PHP.now
that can take the form sometype somevisibility something(){} is a
function?
Well, if in PHP.later, the only thing that takes the form sometype
something{} is an inner class, then leaving off the sometype there
is also unambiguous (but also similarly gratuitous).
And if in PHP.later.still you have inner interfaces, then the
unmodified one still defaults to inner class and only a literal
interface something{} is an inner intf.
(I'm attempting a RAA argument but maybe failing)
-- Sandy | FigureOne Support Team
--
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
It still looks like some random characters bashed together by a monkey with a keyboard. +1, I am a fiend for ternary expressions and crazy one-liners, but this makes me want to go back and unroll everything I've ever done into readable code. :) -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
So no you are not saying PHP is not Java or C#. I don't want to touch any religious views but it's really funny to read :) Not sure I get your remark... of those languages, I've said, in essence [1] Don't *force* PHP to look less like Java, ECMAScript, C#, or C++ without a good reason and a new feature and [2] Don't preclude other languages' advanced features from being added to PHP later -- even much later -- with their most obvious syntax by clipping syntax in PHP.now so that later additions are more difficult. And PHP is looking more like ES in some ways (array literals). I like that. I don't insist on it, but it's a leg up. CF did that too a while back, and that brought me back to it for a project. As I said, if inner classes are ever added to PHP, it stands to reason they would follow the syntax of other C-style languages. And you might then apply your (I believe flawed) argument that any token that could be considered superfluous in a given parser context *and* PHP version should become optional with the default meaning being permanently fixed as of that PHP version. It doesn't stand up to scrutiny because you just end up with more magic to remember and no real advantages, especially over time. But really, really truly, I am not going to comment again on this thread but just wish you luck in swaying the people that count! Cheers, -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
As for classes/interfaces/traits and so on, if they are ever added in PHP
to be declared inside classes and so on then I see no issues with this.
A class/interface or a trait keyword would still be needed to make the
difference between a them imho.
No, if you *only* allow inner classes at any point, you don't have
ambiguity. So by your standard, that version of PHP should drop the
keyword because there's only one unambiguous something{}
construction in that context.
I'm not saying you _should_ drop the keyword, I'm just explaining what
I think is the slippery slope of this kind of non-improvement.
Grepping for sources is like a daily operation and by using IDEs like
Netbeans/Eclipse/PHPStorm one has the ability to just search for a
symbol directly, regardless if you can click of function name or not.
I don't think you followed the matter of complex search/replace and
the new regex you'd have to just use all the time. I use a
sophisticated IDE as I mentioned, but its s/r function is separate
from its find declaration function. Not to mention searching for
duplicate declarations or in files you don't have in your workspace.
This is a real problem and I'm very happy we don't have it now.
No voting karma here as well but I do tons of code reviews and this is
just my opinion, you know, from the userland.
I am debating from userland as well. But I'm all done w/this one.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Seems this would complicate the transplanting of (global) functions
into (default public) class methods and vice versa. This is a common
refactoring task -- at least IME -- and before I adjust visibility I
would expect the function to Just Work.
So this works in a class to define the function:
function my_function() { }
And I expect to be able to pull that out into the global scope as-is.
But if people start using this super-shorthand in the class:
my_function() { }
Then when I pull it out into my function library, I'll get errors.
The reverse is also true: I expect to get a fatal from leaving off a
semicolon between function_call() and {} but at the top level of a
class it gets smoothly compiled as a function definition.
Look, I know there are similar cases throughout PHP (and other
languages) already, but why add more for no (IMO) payoff? Perhaps not
the most compelling case against this new sugar, but it would suffice
to stop me from ever using it.
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
I am something of a language guru and to me syntax is *extremely* important. Am I of the opinion that removing the function keyword from the class definition will help? Yes, I am. I'm missing the help. It saves 9 characters and creates a disjunction between global function syntax and function-as-method syntax? Sorry, I can't see this as anything better than neutral. And for those who like to grep for method definitions they can keep the keyword present. ... in their own code, not in all the code they are forced to maintain (whether that be newbie sloppy code or super-cool library code). -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc
Let's stop pretending that the vast majority of PHP users actually grep source code looking for `function foo`. They don't. *They don't even know how to use grep.* I don't grep as in `grep`, but as in regex search that is part of my IDE but is not also tokenizing/whateverizing/PHP-aware. My IDE lets me search for the declaration of a method by right-clicking class-method(), but it's only able to do that because it knows how to find the class definition and look there (and it doesn't use an autoloader). If I want to do a bulk search, it switches to regex, which doesn't share that intelligence. But I haven't upgraded to the v8 of this thing, only v7, so who knows... I find it indispensable and I'm not going to switch to another one because it isn't smart enough to do a PHP-aware bulk search. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questions regarding DateTimeImmutable
I think it was done to ease adoption even though it was known to violate LSP. To quote Stas, As for established practice, everybody expects DateTime, so IMHO we should leave DateTime as base class even though it's not strictly OO-pure. This way does let users sub in DateTimeImmutable more easily and patch over a ton of unintended -- maybe not even fully noted or understood -- defects in their apps? I dunno. I looked at the first discussion from late 2010 after Benjamin E. sketched out the language addition and Larry G. suggested making them siblings as opposed to subclassing, but those discussions seemed to peter out and by the time Derick wrote the patch, the class model was kind of accepted. The discussion from 2012 is rather mild considering some pretty disparate viewpoints are represented, viz. users don't care about mutability vs. users have been coding as if DT were immutable. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
I think it'd be great to have a library with unified interface and an extension that uses it. However, I'm not sure if these libraries are useful in common php use case - short-lived requests. Could I get the changes since the last request? Or is it useful only for long-running persistent processes? You're right of course that you are implicitly lengthening a request. But if you are already embracing a long-polling model that waits for filesystem changes, the back-end service can actually use fs events instead of looping -- much more efficient. In fact I do this already on Windows by running an external FileSystemWatcher EXE and waiting for it to return (+ a timeout in the wrapper). -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
There are native APIs for that (read: non .net, aka C) on Windows Well aware of that. The EXE does use the Win32 API, not a .NET wrapper. I've used that API ever since it's been documented. using an external process for this purpose would be horrible, in all possible ways. Well, yeah, that's my very point... having the engine/extension do this is the proper direction (I only use this hack to check completion of some scheduled tasks, it's all private). Stas says typical PHP apps don't have a need for file system hooks. Sure, long-polling may not be good with thread-per-process webservers, but those aren't the only PHP environments in the wild. Once you accept that people already roll out long-polling back ends with PHP, the next step is to minimize the check-sleep-loop hackery and offer true event-driven alternatives when possible. Nothing I'm saying is controversial. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] File system watcher/monitoring
P.S. This was the very extension I was referring to when I posted to Internals sometime last year about developing extensions, latest books, etc.. It'd been a longtime fantasy of mine because I use PHP for a lot of sysadmin-type tasks on Windows servers -- DB import/export, nightly HTTP and FTP transfers from data feed providers, things like that -- and having this API supported right in PHP would be great (instead of relying on Windows apps that do use the API but have their own arcane embedded scripting languages, if they have any at all). But my C and Win32 are not what they were when I was writing DLLs as part of my day job, so there's almost zero chance I could do the job. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Questioning the future of PHP
This is something of a wet dream of mine TMI, my friend. TMI. Anyway... I think your Subject is unnecessarily trolly even if the substance of your post isn't. So maybe you could re-post with a WAS: Questioning... to avoid p'ing off the dev team? If I'm understanding your statement of The autoload problem correctly, the language-default spl_autoload function indeed allows you to install a package safely -- in an environment that you know has not completely overridden the default autoloader. If you want to make sure the default is called for your directory structure, then you can make sure to tell the people using your package to put the default spl_autoload in their autoloader chain. Can you explain how this departs from your vision? I don't think what you want is another default autoloader, but a way of ensuring the system default is called once your package is physically installed on a system. Unfortunately, there would always be file I/O overhead if it were to be called even if the PHP install has nothing in the default file layout. You could argue that the default spl_autoload should run unless deliberately turned off (never mind BC for the moment), but then it would just become a popular best practice to turn it off and you're back at the same place. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context (example of real usage that will break)
If addPreserveText() uses anything from Footer, it should not be called
from TextRun, but if it does not, it should be in Section.
No, if it was in Section, all the child classes would have to override
it and throw errors. That results in quite a bit of pointless
boilerplate code to solve a problem that has just been created by this
change (and really the original E_STRICT one). If the code path results
in a call to addPreserveText in the other classes, it's a pretty serious
error, and we need to catch that quick...
Not going to sound off on other subtopics in this thread, about which
my feelings are mixed, but your note here is pretty strange. I agree
with Stas and others that you are already using an antipattern, so if
a major justification is that you need to manually authorize a
subclass to call the super, you don't need to override and throw in
every possible subclass, how about something like this instead to
whitelist:
interface preservable
{
public function addPreserveText();
}
abstract class section {
public function addPreserveText()
{
if (!isset(class_implements($this)[preservable]))
throw new Exception(can't call super from disallowed
subclass);
echo ready to rumble;
}
}
class footer extends section implements preservable {}
class header extends section {}
$myfoot = new footer();
$myfoot-addPreserveText(); // ready to rumble
$myhead = new header();
$myhead-addPreserveText(); // error
-- Sandy
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Things move slowly in the real world ;)
Lester, are you seriously suggesting we coddle providers who either [a] Willfully misrepresent the PHP versioning system, showing they are utterly tuned out of the PHP support community? or [b] Play unfunny practical jokes on their users and/or troll this very list? If anything, their behavior is a call for some official censure, IMO. I have sympathy for their users, but the only cure for that is to find a responsible provider. If providers just told the truth about the whys of what they support, instead of lying about stability, security, or other boldface reasons, users would be better served. One such reason: We should have done this long ago, but held off longer than necessary for budget reasons. Now, we're behind the curve and can't get new customers who are version-aware. You'll enjoy the performance rewards of re/building for the new version. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
So... I was thinking of proposing that we perhaps leave Arrays as is w/r/t undefined indices, while fixing up the ArrayObject gaps and making that the smart one (wrap/box in an AO if you want expanded/overloadable functionality). That idea was based on my belief that ArrayObject::offsetGet already failed gracefully, from the docs: Returns: The value at the specified index or FALSE. Don't think so. Seems like it returns NULL and fires a notice as with an array. Doc bug I guess, as as returning FALSE would be pretty ambiguous. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
My feeling is that either more complex expressions for operators with an implicit isset or !empty shouldn't work, or that they should cause notices. That's exactly why I think we're going in the wrong direction by speaking of an alternate ternary operator. You're saying the basic ternary is (expr1) ? (expr2) : (expr3) But the only notice-free alternate is (var) ?? (expr2) : (expr3) This alternate is just going to cause confusion as it has a different, more limited signature. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
I think that you can compare the situation to the short if syntax ($a $b ? $c : $d) Not sure I understand... that *is* the situation under discussion, no? $a $b ? ... and $a ? ... both use the ternary operator. You do raise (maybe on purpose, not totally clear what you were getting at) the question of whether a more complex (expr1) in one of these theoretical ternarys w/implicit isset, however it is implemented, would apply the isset to _any_ variable in (expr1)? That is, if $a or $b do not exist, does $a $b ?? ... return an error? What if both do not exist? I think the conclusion (as reached by other people) is that the operator needs to apply to each individual variable, not to a multi-step deal like the ternary where there are more cases to consider. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset in ternary operator
Use functions. I understood your post; I was replying to Yahav. Anyway, I don't agree with you that (built-in) functions are all we can add because there'll be too much debate. Other languages still consider adding operators over time and/or allow overloading. Getting functions added to the language is far from easy anyway. And IMO there are waay too many places where something bound closely to the variable like $?a would be instantly useful and portable; adding functions for each of these would be impossible. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and two phase commit transactions
MySQl and MyISAM can not be used in conjuction with LIXA for distributed transaction processing. Should be very clear about this in your documentation, as MySQL as RM will be unsupported in practice in the majority of *MP installations. You didn't mention MSSQL, I assume because you develop only on Ubuntu and/or because of other issues, nor SQLite. These cut out wide slices of general PHP users. (As a side note, I am very frustrated when extensions act like PHP on Windows doesn't exist so it isn't even worth a not supported note.) Again, none of these rule out interest, even gotta-get-it-now interest, in a LIXA extension for PHP, but it mitigates the portion of users who have the technical environment to act on that interest. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and two phase commit transactions
1. Is there any interest in two phase commit inside PHP community? Without a real interest, every effort would be useless. I can't speak to a critical mass of interest, but as PHP and MySQL are closely coupled in the real world, until relatively recently (when Inno became the default) that meant that PHP and MyISAM were best buds. I don't know how you could do 2PC between two transaction-unaware back ends. I could see one transaction-aware and one transaction-unaware working by running synchronously w/the transactional one first (?). So my sense is that PHP, because of MyISAM's ubiquity, isn't the ideal language target for 2PC (compared to Java/.NET where the most enterprise back end is assumed, however inaccurately!). That doesn't mean there wouldn't be some interest, though. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
I'm not sure I understand where the conflict is. 2/3 * 50 == 33 1/3. Therefore, 33 states would be just below the required 2/3, while 34 states would be just above it. So the 34 figure you quoted seems to match this perfectly. The article does mention some ambiguity, but that's pertaining to whether the total includes everyone who *can* vote or just everyone who *did* vote. As far as I know, that's not relevant to this discussion. I agree, don't see any relevant edges. From what I can see in the bylaws for writing bylaws world, it is understood that you must have whole persons unless you *specifically* make an exception that you will use the ceiling. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
Whether that article addresses rounding up, down or sideways, it's an awfully long article for what should be a fairly simple thing... It does seem long-winded toward the top. I guess it's notable that in all that text, it doesn't even note the floor/ceiling concept. I interpret the absence as because it's obvious, but you could argue (given the inanity of the Ask.com answers) that isn't obvious enough to be left out of the 'pedia of record. Maybe someone on Internals is also an active Wiki editor. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
Ah, this is why one should trust a coder over a butler: http://www.ask.com/answers/112530521/5-people-are-voting-what-is-2-3-s-of-a-majority Ugh. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internals books (c) 2007+ ?
Sara’s book is still the best we have, nevertheless it shows its age. In Theo Schlossnagles Scalable Internet Architectures also has a chapter on PHP internals. The rest is more or less reading existing code and playing around. Looks like somebody on Internals should land a book deal :) Thanks, Lars. I first learned about zvals from a chapter in George Schlossnagle's Advanced PHP Programming, so it seems like there are deeper dives here and there. I don't know about the book deal if I'm the only to ask about it in so long, though. :) -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Internals books (c) 2007+ ?
Hi All, Trying to ready myself for some possible work w/the core (after I resurrect all my never-that-great C, heh), I went looking for a recent book. (I still like old-school supplements.) I see Sara's from 2006 on Amazon, but nothing after that under 'PHP internals'. I'm sure that one's not totally obsolete, but I don't know if programming styles and patterns have changed even if the bulk of the code has not. At the risk of fanning some flames I don't know about... is there a more recent book that's generally liked? Thanks, S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
At most, I'd remove the part that truncates numeric strings like 123abc and always convert them to 0, because that's almost *never* an intended effect. I too find it hard to think of the situation in which data must be stored, even in a temporary form, as 123abc but is meant to be equivalent to 123. But it obviously has happened a bunch after all these years. Maybe a non-accidental example is where 123a, 123b, and 123c are all expected to be juggled to 123 -- i.e. the code is purposely utilizing the PHP behavior in place of explicit truncation in order to group certain items together. I'm 99.999% sure I've never done this, but it would be devilishly hard to find the bugs that would come from changing this behavior. Enough that I could see it being a major event that tarnishes the release of PHP-dot-whatever-makes-this-change. I also want to point out, as I did the other month when this came up, that MySQL does autoconversion that is identical to this case [1], and with **MP pairings so absurdly common, it makes sense to keep this behavior in PHP for this reason alone. -- S. [1] SELECT '123abc' = 123 // true in MySQL (but not in all RDBMSes) One could argue that 123 == 123 is, however. On May 7, 2012, at 6:25 PM, Raymond Irving wrote: I was very surprised when I came across the == issue sometime ago. IMO strings should be compared as strings. They should never be converted to integer. 1==1 // always convert the number value to a string and then compare it foo == 0// should return false 123abc == 123nth // compare as string. Do not convert to numeric values 0==0 // true 0==0. // false PHP is great but if we can work together to remove the flaws, then we can make it even greater. We have to leave the past behind us and look at where we want PHP to be in the next 5 years Best regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
Then one can strip off the exif info with the comments, I believe. This presupposes that your users don't expect embedded metadata to be preserved when people redownload the images. Not only do photo professionals/hobbyists expect you to keep the metadata, you also should leave it in for reasons of legality. Hosting a bunch of stripped images can make you look really bad. We only strip metadata that is known to cause browser display problems (mostly old IE6/Adobe comment bugs). Bottom line is you have to make sure PHP never parses the files. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
Moreover, that still doesn't protect you, as it would be possible to make a valid image where the payload happened in the image data... Agreed. But sanitizing input by silently removing blocks of data your users rightfully expect to be preserved? That's egregious, even if it worked. (Like many such discussions, I almost can't believe we're having this one... I mean, executing images is just not normal whether or not you can bear the (performance) cost. Who is doing this on purpose?) -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
Or find a way to have (some of) your users have some level of trust. Or don't execute anyone's uploads. If you allow people to upload code, make them say it's code (via extension *and* by putting it in an executable area). It is not difficult to predict whether a file will be processed by PHP before worrying about what PHP would do with it. If people really worried as much as they claim to about execution of any old document, robots, htaccess, ds_stores -- and php.inis, for that matter -- would be considered highly dangerous. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?
But I just wanted to point out that this is something the author (and I) would never expect to happen ... in_array(123abc, array(3, 7, 123, 28)) === true Well, would you never expect select ( '123abc' in (3,7,123,28) ) to return boolean true in SQL? Because it does. Me, I'm happy with the parity of these two languages that so often must work in tandem. YMMV but I don't see anything kooky. As Adam others have pointed out, the author of that blog post used the original input as-is. Akin to passing a var into a sanitization function (by value), getting a return true, and continuing processing w/the initial var. I'm not saying I haven't done plenty of similarly stupid things, but I don't see them as evidence to be entered against, well, anything except my own incompetence. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_SESSION_* constant values
I believe comparing the value against a constant, is always more readable than wondering what truthy means. if(session_status() === PHP_SESSION_ACTIVE) is much self-documenting than the proposed change. ... also an obvious BC break for anyone who was using the values instead of the constants before. Not that anyone should ever do this, but the change presupposes that people *do* use the values, so it basically contradicts its own acceptability as it is a breaking change! -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_SESSION_* constant values
There is no BC change here as session_status() has been added in the 5_4 branch as far as i can tell. OK, fair enough, I didn't understand it was trying to get into 5.4. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP_SESSION_* constant values
Someone actually just pointed out to me that if(-1) returns true. In that case, I suppose my suggestion doesn't quite work. Well, it still works depending on what conclusion you want to draw in your local environment. Sessions_disabled || yes_active_session might go through the same code path, while no_active_session might go through another. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changed behaviour for strtr()
Right now strtr('anything', 'anything', '') === 'anything', which
means that anyone relying on this behavior is doing something strange
and dumb imo, doing a function call for nothing.
How is relying on by-design behavior that turns the call into a no-op
(instead of wrapping the call in an empty() check or whatever) dumb?
Is there some performance hit for entering strtr() that makes this
true?
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
As ordered, I will stick to what I feel are community issues and try to be impersonal. If PHP users want to be clear that we have made an educated choice to use/maintain the language, we should appear impeccably well-versed in the technologies which complement and compete with PHP. I feel strongly that one should use the best-fit terminology when referring to outside technologies whenever possible, avoiding poorer-fit misnomers. In the case of syntax that -- · will never validate as JSON -- a syntax which is the subject of a well-trafficked IETF RFC; has no standardized non-strict/quirks/ compatibility mode that would suggest that the term can have multiple meanings; and has no understood history of multiple meanings by experts in its use; ·recognizablyviolates JSON quoting rules, not as a secondary/optional syntax, but in the primary examples given in the RFC; and · recognizably violates the JSON security concept that excludes assignment and invocation [RFC 4627] when using host variables or function invocations on LHS or RHS -- yet -- · is recognizably similar to JavaScript object literal syntax, especially wrt quotation marks, with the notable exception of allowing interpolation/invocation on LHS; · thanks to recent major moves in server-side JS (nodeJS), does not need a poor-fit comparison to an interchange/serialization format in order to be understood, but can be recognized as JS-like by server-side folks; · allows PHP string interpolation within RHS, which is not in direct conflict with JS object literal syntax -- as JS simply doesn't support interpolation that would have to be allowed/denied in this context -- but which is in direct conflict with the JSON standard, which _conceptually_ denies such dereferencing; and · insofar as it does directly conflict with JS object literal rules in allowing the LHS (key) of a key:value pair to contain variables or function invocations, still _does not_ add or allow anything that is allowed in JSON, as JSON is more restrictive than JS object literals and prohibits all these syntaxes _and more_ -- I do not feel that the acronym JSON has any clarifying nor edifying place in the RFC describing this syntax. Rather, I would suggest one of the following: · JavaScript-like [object|array] literal syntax · bare-bracket [object|array] literal syntax · short [object|array] literal syntax · compact [object|array] ... · quick [object|array] ... · colon-pair [object|array] ... I have actually been excited about the discussion of this feature area and anticipate my eventual +1 if JSON could be removed from the RFC. Even though the term doesn't affect the way the feature works, by upvoting the RFC one is approving of wording that may make it to the general public, and I think this would be bad for PHP. It might also be noted (h/t David Vega) that Ruby adopted a syntax similar to that proposed here and completely avoided using the term JSON in final documentation, as I hope will be done with PHP even if this RFC continues to use the term. Somewhat on a side note, I do not understand the statement that using a strict syntax would not conform with the PHP way or at least how it relates to this RFC. It is my understanding that, while concepts including (but not limited to) type-juggling, dynamic typing, and use of undeclared vars are emblematic of the PHP way, what I would call strict syntax[es] are encouraged in many areas (without E_STRICT). For one example, missing semicolons may be fatal in PHP while symmetrical syntax works in JS. For another one off the top, PHP's XML modules require well-formedness by default, not what I would expect if there were such a thoroughgoing loose approach to syntax. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Also matter of opinion, and of experience. Apart from the fact that my use of jQuery amounts to a few weeks out of a (mumble)-year programming career, no I don't use pure JSON for it - Javascript object literals, yes, but not pure JSON. It's not just you. The claim that people regularly pass JSON strings within JS frameworks is comical; it would be about as smart as passing serialized PHP vars between PHP functions. I *want* my PHP arrays to look different from my Javascript/JSON arrays, especially as I might be looking at both as part of the same project -- I *want* a big data structure to scream I'm PHP or I'm Javascript/JSON at me, to help trigger my brain into the right programming mode. +1 -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
There's no need to be rude. If you can't make your point without
attacking people, then you need a better argument.
If you can't make your point without misusing terms to the point of
making yourself untrustworthy on that level alone, stop trying to
argue.
The lazy programmer axiom doesn't apply to terminology.
JSON in this case just means a simple object notation using {, [,
and :. You know that.
Nope. I have NEVER heard a knowledgeable developer use JSON in this
way. I consider myself a mid-level Javascript developer, so I'm always
learning both formal coding patterns and informal jargon from people
at the expert level -- but I've never heard this. Evidence, please,
for this claim that the term JSON is so abused by people who
provably know better.
JSON is the best word available.
Give me a break.
JavaScript object literal.
As above, no knowledgeable JS dev refers to
{ name : function(args) }
as actual or informal JSON.
Unless you can suggest a better word to differentiate this format
from the others (one that isn't designed to insult anyone who
disagrees with you) stop fussing about it.
You explicitly claimed that any browser will take your
JSON-with-interpolated-function-return. And you firmly stated you
wanted par with all the other JSON parsers in the world.
You're saying that, um, JSON parser and JavaScript engine are
known to be interchangeable?
Please, just... stop. The time taken here could be better spent
reading the JSON and ES-232 specs than making up false common
knowledge.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Vs. the JSON form:
{
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
}
That isn't valid JSON for many different reasons... if you think
that's pure JSON, you need to spend some time with JSONLint.
If you (and others) mean Javascript object literal, say it.
(Similarly, if you mean Javascript, don't say jQuery gags.)
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
I don't think anyone cares about JSON for the sake of being perfect
JSON, I didn't intend to give that impression.
Then you should stop saying pure JSON and true JSON constantly!
I'm only hoping for something that generally works on par with all
the other JSON parsers in the world.
OK, that trashes your example, where values were set based on the
result of a PHP function. There is no par for JSON parsers running
methods _at creation time_, within the server (author) context.
Setting vars to the return value of a function is something we take
for granted in real languages, but it cannot happen within what a
knowledgeable person would call JSON.
Yes, JSON is a very specific encoding, but when a developer writes
something jsony, what they mean is an object/array with the
following structure/values, because that is what the encoding
really represents.
Not Javascript developers. Maybe jQiddies think that
{'$gt': strtotime('-1 day')}
is JSONy more than it is JS objecty?
This is like starting from Wouldn't inline CSVs be great for creating
arrays? and drifting to I mean, not like with that comma-escaping
stuff, and, uh, newlines would be allowed in the middle of a record,
and you'd have to allow create-time interpolation of function calls.
You know, CSVy!
Only thing I might generously refer to as being JSONy, while
provably not being valid JSON, is a string that conforms in every way
_except_ for using single quotes -- everywhere that doubles are
required -- instead of using doubles. Anything else is someone's
mangled JankySON or just not JSON.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unmaintained SAPIs
isapi (is FastCGI now preferred on Win?) Pls don't remove ISAPI, as it still workswindofor 5.3 even if deprecated. We still use it as part of third-party x64 Windows builds. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
First post here; been watching for a while though. Same here. Here's my take: [1] I don't like ?? / ? because it is disjunctive with === / ==.. The extra equals sign strengthens equality comparison, while the extra question mark essentially _weakens_ the ternary operator (making it more forgiving). (Sure, a case could be made that an extra duplicate operator has no inherent meaning overall, but these two operators seem to be in a similar domain.) [2] I would prefer @?. This makes the error-suppression obvious. But this leads to... [3] ... are we saying that [a] we are still suppressing a deep error or [b] or that an error state does not exist anywhere when you use a special operator? In other words, is it now going to be fully supported to use undefined variables, as long as we always use operators that take them into account? This seems to be inviting criticism from other language fanboys (if we care) since they already hold the non-fatal use of undefined variables in contempt. [4] Strange idea: what about treating the variable as defined after you test it with the special operator, even if you don't specifically assign it a value? So: $varor2 = $var1 @?: 2 // $varor2==2, no warning because special ternary is used $varor3 = $var1 ?: 3 // $varor3=3, but no warning because $var1 has been implicitly defined in special expression [5] Sort of the opposite of [4] and continuing the question of [3], what about only letting a variable be special-op-checked once before throwing a warning. So you can suppress (or not throw) the undefined warning once, but it is assumed that you will define the variable in that statement. So this would discourage the continuous use of the same undef var throughout code (which seems like a code smell), while allowing for the real case that you're using the special-op to filter $_REQUEST or whatever -- one time. I haven't really thought about the edges, but thought I'd put those out there. Cheers, Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
