Re: [PHP-DEV][DISCUSSION] Multilingual PHP
Hi,
On Do, 2019-04-11 at 15:32 -0500, Michael Morris wrote:
> Submitted to the floor is a Wired article from 2 days ago I came
> across
>
> https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-spea
> k-english/
>
Oh, memories. Microsoft Office has (or had) localised macros. This lead
to many problems since localisaton depends on language installed and
macros from one don't work on the other ...
I don't believe the language itself should be translated. This limits
portability and there are just a few keywords.
If somebody wants to create localised libraries they can of course do
...
An area I would find interesting is error messages. To a little degree
we already have them localized:
$ php -r 'setlocale(LC_ALL, "de_DE");fopen("/etc/passwd", "w");'
PHP Warning: fopen(/etc/passwd): failed to open stream: Keine
Berechtigung in Command line code on line 1
Expanding might be interesting, but it is not a trivial task, as this
might make error reporting (also suppressed one, i.e. deprecation
warnings) slower and it is a big translation and maintenance work and
has impact on support (I myself run my machines typically in English so
I can Google error messages and receive better results or can grep the
source for the origin)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
On Fri, Apr 12, 2019 at 1:10 AM Derick Rethans wrote: > > My favourite annoyance is using a non breaking space in > function/method names ;-) "Better" yet, you can use characters that are different, but look the same as Latin chars e.g. CYRILLIC SMALL LETTER ES (U+0441) instead of (LATIN SMALL LETTER C U+0063). Incidentally these two chars also share the same physical button in English/Russian keyboard layouts, so it's a mistake easy to make and very hard to spot visually: https://3v4l.org/rjjU9 -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
On Thu, 11 Apr 2019, Walter Parker wrote: > I also am old enough to have used/remember using BASIC. I remember German > and Japanese friends that wrote in BASIC. It was interesting to see German > programs where all the keywords were in English and all the text was in > German. The Japanese was even more strange as the system had to switch > between the code pages for ASCII/LATIN and the one for the Japanese > Language. > > Today to get something other an ASCII/LATIN, we would have to support > Unicode for source code. Does PHP currently work if Unicode is used for > identifiers? Yes. You can use UTF-8 for function names and variables (but please don't!). My favourite annoyance is using a non breaking space in function/method names ;-) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
I also am old enough to have used/remember using BASIC. I remember German and Japanese friends that wrote in BASIC. It was interesting to see German programs where all the keywords were in English and all the text was in German. The Japanese was even more strange as the system had to switch between the code pages for ASCII/LATIN and the one for the Japanese Language. Today to get something other an ASCII/LATIN, we would have to support Unicode for source code. Does PHP currently work if Unicode is used for identifiers? Walter On Thu, Apr 11, 2019 at 2:36 PM Bruce Weirdan wrote: > On Fri, Apr 12, 2019 at 12:17 AM Benjamin Morel > wrote: > > > This may be harder for people having a native language with a different > > alphabet, though. > > > > That's unlikely to be a problem. Even to get to the PHP manual you have to > type `www.php.net` (or `google.com` if you want to google something), > so it implies you have a way to enter latin characters. Keyboard layout > switching is a problem solved decades ago. > > -- > Best regards, > Bruce Weirdan mailto: > weir...@gmail.com > -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
On Fri, Apr 12, 2019 at 12:17 AM Benjamin Morel wrote: > This may be harder for people having a native language with a different > alphabet, though. > That's unlikely to be a problem. Even to get to the PHP manual you have to type `www.php.net` (or `google.com` if you want to google something), so it implies you have a way to enter latin characters. Keyboard layout switching is a problem solved decades ago. -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
Hi! > I'll stop there cause I know there are problems I haven't thought of. And > I'm not going to argue the syntax I just kicked out from the top of my head > is the best either. For better or for worse, English is the lingua franca of the internet technology. You can, of course, create a compiler which would understand keywords in other languages. This compiler will be used by 0.001% of the main language user base, code written with it will be inaccessible to any person who does not read that language, and communication between the users of different language-branches of the project would be virtually zero because they literally would have no common language. I don't think this would help anyone. Yes, basic knowledge of English is currently a requirement to engage with most technologies. Once you have mastered it, however, the whole technology world is available to you, at one-time investment. Fragmenting this world into tiny pieces, each with its own language, would not make these parts more accessible to each other. > But I think it's worth the effort to at least look into the problem. Wired > has a point - people learn to code faster when they are working with their > own language. One of the stated goals of PHP's design has been My native language is not English. Moreover, my first foreign language wasn't English either. I had no more trouble learning BASIC (yes, I am that old) or Pascal than I had learning programming languages based on my native tongue. The only difference is that the former translated pretty well into other languages I encountered when I progressed with my learning, while the latter did not, it was an isolated island not connected to anything else. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV][DISCUSSION] Multilingual PHP
The problem with this approach is that while it may become more readable for the native speaker, it becomes pretty much impossible to read for the rest of the world. Having one single syntax for everyone allows all programmers in the world to share code. I can't imagine a world where I'd find a library based on Russian PHP on GitHub, that I can't contribute to or even understand (I probably wouldn't use it). English has the huge advantage to be quite simple to learn for basic purposes, and it has a limited alphabet, composed only of ASCII letters. I'm not a native English speaker but have never been bothered by keywords being called IF and THEN, even when reading BASIC books as a child before taking any English course at school. This may be harder for people having a native language with a different alphabet, though. - Ben On Thu, 11 Apr 2019 at 22:32, Michael Morris wrote: > Submitted to the floor is a Wired article from 2 days ago I came across > > > https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-speak-english/ > > The manual of PHP is translated into multiple languages - but what are the > development hurdles of the language itself being multilingual? > > From what I understand of the compiler - maybe not that much. The language > requires an opening tag, so we could hook into that like this example for > Japanese > > > A PHP opening tag with such a qualifier would change over all function > names and reserved words. Could these would be set on a per file basis? > > The php.ini file could set the default language, the .htaccess file could > also on per directory. > > I'll stop there cause I know there are problems I haven't thought of. And > I'm not going to argue the syntax I just kicked out from the top of my head > is the best either. > > But I think it's worth the effort to at least look into the problem. Wired > has a point - people learn to code faster when they are working with their > own language. One of the stated goals of PHP's design has been > accessibility so this seems to be appropriate. > > I yield the floor to those smarter and wiser than I. >
[PHP-DEV][DISCUSSION] Multilingual PHP
Submitted to the floor is a Wired article from 2 days ago I came across https://www.wired.com/story/coding-is-for-everyoneas-long-as-you-speak-english/ The manual of PHP is translated into multiple languages - but what are the development hurdles of the language itself being multilingual? >From what I understand of the compiler - maybe not that much. The language requires an opening tag, so we could hook into that like this example for Japanese
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> From: Robert Korulczyk [mailto:rob...@korulczyk.pl] > > Personally, I'm surprised by the controversy around this change. So far it > was an > obvious anti-pattern for me, and never seen anybody who was aware of the > consequences of using http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
On Thu, Apr 11, 2019 at 1:48 PM M. W. Moe wrote: > > @Benjamin Morel > > you must certainly have basic comprehension troubles; read me back; it is > public; keep for yourself your > emotional false projections to myself and infantile behaviors to yourself; > I would never dare simply by following > the basic rules of education; maybe english grammar should introduce a > point of `ironism`; would help or not. > > You have a good day; thank you. > Hello internals, I am ALL for academic discourse and constructive criticism. This value system has gotten many folks far in life and produces a better product, which I know we all want. However, mo.mu@gmail.com's behaviour on this list is not the type of academic discourse or constructive criticism that inspires individuals to contribute and share their knowledge, in my opinion. mo.mu@gmail.com: could you please temper your language to consider that a human is on the receiving end of your comments. Could you keep your comments within the realm of the RFC discussion-at-hand and away from personal or hyperbolic illustrative language? This RFC is really straight-forward and really, really well documented, prepared and presented. I perceive your hyperbole as a disrespect to the time of contributors to the project and to this thread. Please, temper your language. I hesitate to single you out (as there are other non-ideal behaviours; certainly on this list, but particularly in this thread), but in my opinion, you are the individual with the power to bring us back to a productive discussion. Thanks! -Dustin -- Dustin Wheeler | Software Developer NC State University mdwhe...@ncsu.edu "If you don't know where you're going, it's easy to iteratively not get there." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@Benjamin Morel you must certainly have basic comprehension troubles; read me back; it is public; keep for yourself your emotional false projections to myself and infantile behaviors to yourself; I would never dare simply by following the basic rules of education; maybe english grammar should introduce a point of `ironism`; would help or not. You have a good day; thank you. On Thu, Apr 11, 2019 at 10:41 AM M. W. Moe wrote: > @Robert Hickman > > yes somehow that's a valid conclusion; however, I can walk and talk; it > does not > bother me at all; I like distractions. > > You have a nice day. > > On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman > wrote: > >> @M. W. Moe If you don't like the java-isms you can ignore them to a >> large extent, which I do. However in doing so you're going against the >> grain and will end up writing a lot of stuff yourself. I do find it >> weird how PHP has morphed so drastically from it's origins and also >> wander why. If people wanted a Java-esque language, why not use Java >> in the first place? >> >> This discussion is off topic. >> >> On Thu, 11 Apr 2019 at 17:15, Benjamin Morel >> wrote: >> > >> > > why? if voicing reasonable criticisms is bothering you; then you >> should >> > do something else in life; >> > > because engineering is built on this `very` concept; >> > >> > You're very welcome to challenge the "java impurities" that have been a >> > foundation of the language for 15 years—although you may better invest >> your >> > own time by switching to another language that's already closer to what >> you >> > expect. >> > >> > But calling people pigs when they disagree with you is not what I'd call >> > reasonable criticism. >> > >> > > I am not in the apex or any emotional trend; it does not interest me. >> > >> > Oh that's exactly the impression you've left so far. >> >
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@Robert Hickman yes somehow that's a valid conclusion; however, I can walk and talk; it does not bother me at all; I like distractions. You have a nice day. On Thu, Apr 11, 2019 at 9:38 AM Robert Hickman wrote: > @M. W. Moe If you don't like the java-isms you can ignore them to a > large extent, which I do. However in doing so you're going against the > grain and will end up writing a lot of stuff yourself. I do find it > weird how PHP has morphed so drastically from it's origins and also > wander why. If people wanted a Java-esque language, why not use Java > in the first place? > > This discussion is off topic. > > On Thu, 11 Apr 2019 at 17:15, Benjamin Morel > wrote: > > > > > why? if voicing reasonable criticisms is bothering you; then you should > > do something else in life; > > > because engineering is built on this `very` concept; > > > > You're very welcome to challenge the "java impurities" that have been a > > foundation of the language for 15 years—although you may better invest > your > > own time by switching to another language that's already closer to what > you > > expect. > > > > But calling people pigs when they disagree with you is not what I'd call > > reasonable criticism. > > > > > I am not in the apex or any emotional trend; it does not interest me. > > > > Oh that's exactly the impression you've left so far. >
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> Turning it on permanently would also solve the problem Well, yes, although it creates "another way of doing the same thing". So far PHP was on a way to remove redundant tags. Permanently enabling of short open tags looks like a move in the opposite direction. Personally, I'm surprised by the controversy around this change. So far it was an obvious anti-pattern for me, and never seen anybody who was aware of the consequences of using On 4/11/2019 1:12 AM, Robert Korulczyk wrote: >>> Sorry for the sarcasm, please don't consider this as a personal attack. The >>> whole community (not just you) considers short open tags poison because not >>> XML-compatible... >> >> This is rather removing another trap from the language. As long as short >> open tags exist and depend on INI directive, there will be bugs and source >> code leaks after moving application to a different environment. Using > over > external tool to enforce this. > > I wouldn't say it is the ONLY safe way. Turning it on permanently would also > solve the problem and there's also allowing ' as a permanent always-on option. (Native XML compatibility is a complaint, > not a requirement of a language. XML is also basically dead in my corner > of the PHP universe, only ever cropping up on very rare and very confused > occasions.) > > It's going to be interesting to see how many people who rely on and *prefer* > using short open tags in internal systems come out of the woodwork when > PHP 7.4 and 8 drops. Maybe I'm the only one who likes saving a few > characters here and there and thinks code is more readable without the > verbose tag. > > The vote is on the knife's edge of passing/failing at the moment and could go > a couple of unusual directions as already noted elsewhere. This is > probably the most interesting RFC *vote* to happen in a long while. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@M. W. Moe If you don't like the java-isms you can ignore them to a large extent, which I do. However in doing so you're going against the grain and will end up writing a lot of stuff yourself. I do find it weird how PHP has morphed so drastically from it's origins and also wander why. If people wanted a Java-esque language, why not use Java in the first place? This discussion is off topic. On Thu, 11 Apr 2019 at 17:15, Benjamin Morel wrote: > > > why? if voicing reasonable criticisms is bothering you; then you should > do something else in life; > > because engineering is built on this `very` concept; > > You're very welcome to challenge the "java impurities" that have been a > foundation of the language for 15 years—although you may better invest your > own time by switching to another language that's already closer to what you > expect. > > But calling people pigs when they disagree with you is not what I'd call > reasonable criticism. > > > I am not in the apex or any emotional trend; it does not interest me. > > Oh that's exactly the impression you've left so far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
> why? if voicing reasonable criticisms is bothering you; then you should do something else in life; > because engineering is built on this `very` concept; You're very welcome to challenge the "java impurities" that have been a foundation of the language for 15 years—although you may better invest your own time by switching to another language that's already closer to what you expect. But calling people pigs when they disagree with you is not what I'd call reasonable criticism. > I am not in the apex or any emotional trend; it does not interest me. Oh that's exactly the impression you've left so far.
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@Fabien S yes, I think you could remove decoration; but still lambda capture process must be clarified i.e iterating your ruleset; you don't want to capture every scope variables. On Thu, Apr 11, 2019 at 8:22 AM Fabien S wrote: > Thanks a lot for all your efforts Nikita. > > I really like the Haskell `\($x)` syntax, could someone confirm if it > would possible to drop the parenthesis (like `\$x`) if we have one argument > ? > > Thanks in advance, regards
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On 4/11/2019 1:12 AM, Robert Korulczyk wrote: Sorry for the sarcasm, please don't consider this as a personal attack. The whole community (not just you) considers short open tags poison because not XML-compatible... This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source code leaks after moving application to a different environment. Using I wouldn't say it is the ONLY safe way. Turning it on permanently would also solve the problem and there's also allowing 'character]' as a permanent always-on option. (Native XML compatibility is a complaint, not a requirement of a language. XML is also basically dead in my corner of the PHP universe, only ever cropping up on very rare and very confused occasions.) It's going to be interesting to see how many people who rely on and *prefer* using short open tags in internal systems come out of the woodwork when PHP 7.4 and 8 drops. Maybe I'm the only one who likes saving a few characters here and there and thinks code is more readable without the verbose tag. The vote is on the knife's edge of passing/failing at the moment and could go a couple of unusual directions as already noted elsewhere. This is probably the most interesting RFC *vote* to happen in a long while. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
Thanks a lot for all your efforts Nikita. I really like the Haskell `\($x)` syntax, could someone confirm if it would possible to drop the parenthesis (like `\$x`) if we have one argument ? Thanks in advance, regards -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@Benjamin Morel why? if voicing reasonable criticisms is bothering you; then you should do something else in life; because engineering is built on this `very` concept; I am not in the apex or any emotional trend; it does not interest me. You have a good day! On Thu, Apr 11, 2019 at 7:58 AM Benjamin Morel wrote: > > yes php still suffers of > > it's java-like-transform; historically named php5; > > repeating the same design traps almost 20 years after it; > > Maybe you could just switch to another language then, and bother another > mailing list? > > > On Thu, 11 Apr 2019 at 16:51, M. W. Moe wrote: > >> @Stephen Reay >> >> i) Good for you!, if you say so must be the truth; yes php still suffers >> of >> it's java-like-transform; historically named php5; >> repeating the same design traps almost 20 years after it; and in the >> real-life the most interesting inquiries about the language evolution are >> blocked by this fact and make tedious what would look like very simple >> changes. >> >> ii) BTW, that's you making personal experience an absolute rule and >> projecting your own limitations as a valuable intellectual argument; , not >> myself; my remark was just an illustration. >> >> You have a good day! >> >> >> >> >> >> >> >> On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay >> wrote: >> >> > >> > > On 11 Apr 2019, at 00:32, M. W. Moe wrote: >> > > >> > > I have never seen ML programmers being improductive; >> > >> > Great. I’ve never seen a pig crash a plane, therefore all pilots should >> be >> > pigs? >> > >> > Given your previous comments regarding removing “java impurities” it’s >> > hard to take anything you suggest seriously. >> > >> > >> > >> >
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
> yes php still suffers of > it's java-like-transform; historically named php5; > repeating the same design traps almost 20 years after it; Maybe you could just switch to another language then, and bother another mailing list? On Thu, 11 Apr 2019 at 16:51, M. W. Moe wrote: > @Stephen Reay > > i) Good for you!, if you say so must be the truth; yes php still suffers of > it's java-like-transform; historically named php5; > repeating the same design traps almost 20 years after it; and in the > real-life the most interesting inquiries about the language evolution are > blocked by this fact and make tedious what would look like very simple > changes. > > ii) BTW, that's you making personal experience an absolute rule and > projecting your own limitations as a valuable intellectual argument; , not > myself; my remark was just an illustration. > > You have a good day! > > > > > > > > On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay > wrote: > > > > > > On 11 Apr 2019, at 00:32, M. W. Moe wrote: > > > > > > I have never seen ML programmers being improductive; > > > > Great. I’ve never seen a pig crash a plane, therefore all pilots should > be > > pigs? > > > > Given your previous comments regarding removing “java impurities” it’s > > hard to take anything you suggest seriously. > > > > > > >
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
@Stephen Reay i) Good for you!, if you say so must be the truth; yes php still suffers of it's java-like-transform; historically named php5; repeating the same design traps almost 20 years after it; and in the real-life the most interesting inquiries about the language evolution are blocked by this fact and make tedious what would look like very simple changes. ii) BTW, that's you making personal experience an absolute rule and projecting your own limitations as a valuable intellectual argument; , not myself; my remark was just an illustration. You have a good day! On Wed, Apr 10, 2019 at 9:23 PM Stephen Reay wrote: > > > On 11 Apr 2019, at 00:32, M. W. Moe wrote: > > > > I have never seen ML programmers being improductive; > > Great. I’ve never seen a pig crash a plane, therefore all pilots should be > pigs? > > Given your previous comments regarding removing “java impurities” it’s > hard to take anything you suggest seriously. > > >
[PHP-DEV] Re: default_charset and mb_internal_encoding
On 02.04.2019 at 11:42, Nicolai Scheer wrote:
> I'm currently in the process of migrating an old application from php 5.6
> to 7.2.
> In the process, I fiddled with the default_charset ini setting.
>
> The documentation states (c.f.
> https://www.php.net/manual/en/ini.core.php#ini.default-charset):
>
> "In PHP 5.6 onwards, "UTF-8" is the default value and [...] The value of
> default_charset
> will also be used to set the default character set for [...] and for
> mbstring functions
> if the mbstring.http_input mbstring.http_output mbstring.internal_encoding
> configuration option is unset."
>
> As such, I'd expect to be able to set default_charset to iso-8859-1 and
> mbstring to pick that same setting for its internal encoding (if the
> mentioned directives are unset, that is).
>
> This seems not to be the case:
>
> ini_set( 'default_charset', 'iso-8859-1' );
> var_dump( ini_get("mbstring.internal_encoding") );
> var_dump( ini_get("mbstring.http_input") );
> var_dump( ini_get("mbstring.http_output") );
> echo mb_internal_encoding() . "\n";
> echo mb_strlen( "\xc3\xb6" ) . "\n";
> echo mb_strlen( "\xc3\xb6", '8bit' ) . "\n";
>
> This outputs (7.2.15 on a CentOS box):
> string(0) ""
> string(0) ""
> string(0) ""
> UTF-8
> 1
> 2
>
> The default_charset is set but mbstring settings are not, so I'd expect to
> get 2 as the character/byte count in both cases.
>
> If I throw a mb_internal_encoding("iso-8859-1") in the mix, both string
> lengths are equal.
>
> Since the mentioned mbstring directives are deprecated as of 5.6.0 - do I
> really need to use mb_internal_encoding() instead?
> Is the documentation wrong or am I just misinterpreting it? I thought that
> default_charset should act as some kind of "master setting" in order not to
> have to set all specific settings as well (e.g. iconv, mbstring).
>
> Usually we use UTF-8, so I did not come across this before...
>
> Any insight?
confirms the reported behavior. A quick look
at the code, too. I suggest you file a ticket on
Re: [PHP-DEV] [RFC] Nullable Casting
On 11/04/2019 08:52, Guilliam Xavier wrote: Honestly as a newbie here I'm feeling more tired than I had expected and I'm not sure if we'll find a syntax+semantics pair that will reach a consensus... Suggestions and comments very welcome! Don't stress yourself about it. At the end of the day we're all just here because we want to improve the language, and a person's willingness to debate the pros and cons, and adjust if necessary, is naturally a extremely valuable part of the RFC authoring process. When you eventually call the vote itself, regardless of whether it passes or fails, you should both be holding your heads high that you've made the effort. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On Thu, 11 Apr 2019 at 12:14, Peter Cowburn wrote:
>
>
> On Wed, 10 Apr 2019 at 11:44, G. P. B. wrote:
>
>> Hello Internals,
>>
>> As there have been no further comments the voting for my RFC [1] to
>> deprecate PHP's
>> short open tags has started and will run for two (2) weeks.
>>
>
> Firstly, I apologize for not mentioning this before the vote was opened.
>
> Does the primary (it's probably not fair to call it that, for this RFC)
> vote include changing the default (php -n) from On to Off? That's what is
> specified in the very concise proposal section, so it seems reasonable to
> assume it's the case, but I just want to be sure since the actual vote
> question doesn't mention changing the default value.
>
> With the current state of voting, it is looking like we could end up such
> that we don't deprecate (and disable by default, maybe) the feature, but
> jump straight to removing it. That's not usually how feature removal
> works. It would've been better, IMO, to just take the proposal
> ("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short
> open tags in PHP 8.0.") and make that a yes/no vote.
>
Hello Peter,
For changing the default from On to Off it more something I realised during
the implementation of the patch that the in-engine default is "On",
which I found to be unexpected (probably because the doc says it's only
enabled with a compile flag) so I changed it.
But the default could stay the same as I'm starting to realise that with
current state of voting we are getting kind of a mess of a split vote as
you said.
It would have been nice that someone would have noticed the problems with
the voting structure before I start it but not to sure how to proceed.
I don't know if people vote against the deprecation notice in PHP 7.4 as
the default value changes because if this is the case maybe leaving the
default
as is and only deprecating would be better?
Also I do agree that having deprecation notices before a feature removal is
wise but from my understanding the RFC which removed the ASP tags also
didn't have deprecation notices, so there is already a precedent for
removing features without warning (not that I agree with it).
So not sure how to proceed ATM and some more feedback would be probably
necessary as it is my first RFC.
Best regards
George P. Banyard
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
On Wed, 10 Apr 2019 at 11:44, G. P. B. wrote:
> Hello Internals,
>
> As there have been no further comments the voting for my RFC [1] to
> deprecate PHP's
> short open tags has started and will run for two (2) weeks.
>
Firstly, I apologize for not mentioning this before the vote was opened.
Does the primary (it's probably not fair to call it that, for this RFC)
vote include changing the default (php -n) from On to Off? That's what is
specified in the very concise proposal section, so it seems reasonable to
assume it's the case, but I just want to be sure since the actual vote
question doesn't mention changing the default value.
With the current state of voting, it is looking like we could end up such
that we don't deprecate (and disable by default, maybe) the feature, but
jump straight to removing it. That's not usually how feature removal
works. It would've been better, IMO, to just take the proposal
("Deprecate and disable short_open_tag in PHP 7.4 and remove PHP's short
open tags in PHP 8.0.") and make that a yes/no vote.
Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags
>
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> On 11 Apr 2019, at 04:49, Wes wrote: > > The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. I can’t say I’ve run into the XML issue in a real environment, but IMO the big ‘problem’ is that they can be disabled, so they can’t be relied upon for anything being distributed outside your own direct control. Also for the record, *I* don’t use Twig (The one thing no one can deny is php’s power as a markup templating language.. and then people don’t use it directly? Insanity.) Cheers Stephen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures
On Thu, 11 Apr 2019 at 00:43, Rowan Collins wrote: > > On 10 April 2019 21:56:41 BST, "Björn Larsson" > wrote: > >Could then the \($x) syntax be a good compromise between > >readability & implementation? > This syntax does make sense to me, although only as I've seen it before in Haskell, which does something similar: https://wiki.haskell.org/Anonymous_function I think that people will get used to whatever becomes common. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Always generate fatal error for incompatible method signatures
Am 09.04.2019 um 10:25 schrieb Nikita Popov: A small cleanup RFC for PHP 8: https://wik +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source code leaks after moving application to a different environment. Using Finally!!! everybody will be able to parse my xml files with embedded > php1!1 if I ever wrote one!!! > > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. > > This is just beyond my understanding. > > But sure, let's keep vilifying this kind stuff and pretend they are the > root cause of PHP's bad rep. > > Sorry again for the negativity. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Nullable Casting
OK, I'll try to sum up a bit the recent messages (since Nikita's one):
Mark Randall wrote:
> As is implied from the name, an implicit cast is done because the code
> needs it to, not because it has been told to by the caller. It is
> natural to be more conservative when doing something that has not been
> explicitly specified.
>
> I expect a difference in the behaviour of function arguments vs casts
> for the reason that although they share a type syntax, they do have two
> very different behaviours.
That makes sense!
> I don't think it would go down very well to have non-nullable casts
> throwing TypeErrors for common cases, without an elegant
> could-not-convert fallback that doesn't require a 5 line try-catch block.
I agree (and even for nullable casts). I'm also fine with the current
`(int)null === 0`, `(string)null === ""`, `(array)null === []` etc.
(Now maybe things like `(int)"abc" === 0` *could* emit some Notice
like already the case for `(string)[] === "Array"`, but that's another
discussion...)
Benjamin Morel wrote:
> Of course there could be helper functions with different semantics, that
> would perform a cast-or-null-on-failure, such as `to_int("abc") === null`
There was a "Safe Casting Functions" RFC, which was rejected (but that
was in 2014, before PHP 7 and scalar type declarations, so who knows
how it would go if re-proposed today...)
Mark Randall wrote:
> $nullable_number = $maybe_null ^?? (int)$maybe_null;
That's an... "interesting" idea ^^ (though I would not propose it).
> $nullable_number = (null|int)$input;
This is explicit, but I worry that `null|int` and `int|null` will be
different (since you propose *ordered*) whereas they're the same in
phpDoc as well as in the (rejected) "Union Types" RFC. (I also fear
things like `(null|float|int|string)$x`...)
***
The initial motivation behind the RFC was mainly to have an explicit
equivalent of "nullability-preserving" implicit *valid* conversions
in symmetry with nullable scalar type declarations and weak-typing mode
(e.g. `(?string) $int_or_null` or `(?int) $numeric_string_or_null`)
for use in strict-typing mode.
But there are indeed various combinations of "invalid" conversions
(although one could argue they are programming errors or bugs to fix),
and people seem to expect different things from a new "(?type)" cast
syntax (not to speak of the existing "(type)" cast) as how to handle
those "failures"...
Honestly as a newbie here I'm feeling more tired than I had expected
and I'm not sure if we'll find a syntax+semantics pair that will reach
a consensus... Suggestions and comments very welcome!
--
Guilliam Xavier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
