Re: [PHP-DEV] [RFC] Warn on conversions from resource to string
Hi, ssh2 maintainer here. Low maintenance is indeed somewhat accurate. I review and merge PR's, have done some minor work on it, and do releases sometimes. Some others on this list have done minor work on it too. On Tue, Sep 24, 2024, at 19:53, Christoph M. Becker wrote: > >>> Let me know what you think about it: > >>> https://wiki.php.net/rfc/warn-resource-to-string > >> > >> The ssh2 wrappers[1] used to use this "feature". I'm not sure whether > >> there is another way to accomplish the same now. If not, that should > >> probably be done prior to emitting a warning for the resource to string > >> conversion. > >> > >> [1] https://www.php.net/manual/en/wrappers.ssh2.php Indeed, the ssh2 extension uses this. I'm not sure what warnings on conversion to string would bring for PHP developers though. The places where resource values are still used are all in very technical functions. Most developers will use some wrapper class, or of not very likely know what they are doing. Personally I've never accidentally echo'ed a resource and wished it would have registered in my monitoring systems. Secondly, I don't think it happens very often. (not nearly as much as array to string conversion has hit me) As a third argument against this RFC: We're moving away from the resource type. Processes, sockets, curl and possibly others that have escaped my attention have already been changed to objects. I've already concluded that ssh2 should follow and use an object, at least before resource will be removed in core. I've noticed stream also still uses resource. Greetings, Casper
Re: [PHP-DEV] [Initial Feedback] Typed Arrays
On Wed, Jun 26, 2024, at 21:59, Richard Miles wrote:
> I think we should have typed arrays in PHP.
Yes! I cannot stand sitting through conference talks on 'generics' that only
talk about 'collections'. This could be solved if we had typed arrays. If
anything we would get better talks on Generics. :-)
Arrays of a type is one of the last cases where I need docblocks to tell my
editor about the types.
In my opinion, even if we would have some implementation of generics, having
typed arrays with a simple syntax would be awesome.
A syntax suggestion:
$array = stdClass[];
class A {
public stdClass[] $array;
}
Adding an invalid array member should throw TypeError.
I know there are way more edge-case situations to think of (for example: if
class B extends A, $b is of type B[], but holds only A's, can $b be assigned as
value of public A[] $a ?)
> Generics or bust.
I do not understand the reasoning behind that. Is it because we really want
generics, but when the 95% use-case is solved we fear that there would not be
enough momentum to get that? I'd love to have generics too, but a very simple
array syntax would in my opinion still add a lot of value, even if we already
had generics.
Re: [PHP-DEV] [RFC] [Vote] Type Guards for Classes
On Thu, May 16, 2024, at 22:31, Patrik Václavek wrote: > This feature aims to simplify and standardize the process of verifying that a > variable is an instance of a specific class, enhancing code readability and > reducing boilerplate code. > > Currently, in PHP, to ensure that a variable is an instance of a specific > class, developers need to use the `instanceof` operator and manually throw an > exception if the check fails. This results in repetitive boilerplate code > scattered throughout the codebase. A new syntax, `(ClassName) $variable`, is > proposed to streamline this process by performing an instanceof check and > throwing a `TypeError` if the variable is not an instance of the specified > class. I view variables changing types to be an anti-pattern. Instead if adding type guards, I would rather see this problem solved by having typed local variables. This ensures that a variable always holds a specific type, avoiding the need of repetitive scattered type guards. Working with variables would then be the same as working with class properties. They could be typed or untyped. Also, I see the need for type guards as a symptom of bad composition. Mostly methods that are too large would benefit. If a method is decomposed into smaller methods the use of parameter and return type checks it's unlikely there is need for additional type guards.
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
> So... if you want to help make people more aware of the grapheme_* > functions, one place to start would be editing the documentation for the > various string, mbstring, and grapheme functions to use consistent > terminology, and sign-post each other more clearly. > http://doc.php.net/tutorial/ Yes I agree, Also I've edited documentation before in the svn days. I already planned to read up on how this is working nowadays. Also I'm planning an outline for a conference talk on the subject. I've educated people on unicode related subjects before, and think I have a few very good stories that can give insight into this for unsuspecting developers. I love the analogy that most Europeans understand. For the city of Cologne, there are two equally valid ways to write it's German name. Köln and Koeln. (Used when hindered by technical limitations, or maybe in informal conversation) Every German can extra_e_decode() and extra_e_encode(). Same for Straße and Strasse. Ligatures in fonts make it harder though, sometimes they intentionally obfuscate what's happening in the unicode layer. You might know this from special programming fonts with glyphs for ===, <> and such. Some Dutch fonts do a special ligature that combines ij, which was in the Dutch alphabet when I was a kid, 'y' was not. Unicode U+0132 and U+0133 describe this symbol, but I've never seen them used. Fonts combining ij to one visual entity is more common. I imagine most languages and cultures have these kind of edge-cases.
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
On Tue, Mar 26, 2024, at 18:15, Derick Rethans wrote: > Many of these already exist, such as grapheme_substr. We can't simply change > the behaviour of the already existing functions due to BC reasons. Wow. I feel very stupid. I feel I should have known about grapheme_*, but I didn't. Oh my, the manual says since PHP 5.3 no less. From what I've seen around being used, I'm far from the only one though. In an attempt to justify my own stupidity I searched its use and it's bad. Searching on github with language:PHP: `mb_strlen` 84k files, `grapheme_strlen` 680 Then a big number of first 100 of these files are stubs/polyfills/phpstan metadata. I've seen no framework except Symphony (but they might be further in the searchresults) > The grapheme_str_split function, as well as other intl extension functions is > what should replace mbstring really. YES! I'm sorry to have wasted your time. If you need someone to help for the grapheme_ marketing team, let me know.
Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function
I'd like to address an issue I have with this RFC.
I'm not sure is solves a problem by itself. If I understand all of this
correctly this only does what already can be accomplished with
preg_match_all('/\X/u', ...). The result of this method in my opinion is not
very usefull by itself. I've done some searching on various code platforms
where I mostly find the use-case for counting the number of grapheme's. I've
used it to implement strrev() that correctly works multibyte.
I'm very sad that mbstring works on codepoints instead of grapheme's and I
would very much like to see something happening in that area, but I think
expanding a simple string to an array of as many elements to give developers a
tool to do this in PHP-space is not good enough. Especially since it can
already be achieved with a regexp that already works.
In my opinion: This adds nothing, and tells the PHP developer that is ok to do
count(grapheme_str_split()) for a more accurate mb_strlen().
I would like to see a family of functions that can do multibyte str_split(),
strrev(), substr(). Ideally as bugfix in mb_* functions, because the edge-case
of wanting to know the length in codepoints of a string is a weird edge-case.
No developer wants to know that. mb_strlen() should have returned the number of
graphemes from the start.
On Tue, Mar 26, 2024, at 01:44, youkidearitai wrote:
> 2024年3月26日(火) 5:43 David CARLIER :
> >
> > I second this, I think it is a good addition which makes a lot of sense.
> >
> > Cheers.
> >
> > On Mon, 25 Mar 2024 at 20:36, Ayesh Karunaratne wrote:
> >>
> >> >
> >> > 2024年3月9日(土) 15:26 youkidearitai :
> >> > >
> >> > > Hello, Internals
> >> > >
> >> > > I created an wiki for `grapheme_str_split` function.
> >> > > Please see:
> >> > > https://wiki.php.net/rfc/grapheme_str_split
> >> > >
> >> > > I would like to "Under Discussion" section.
> >> > >
> >> > > Best Regards
> >> > > Yuya
> >> > >
> >> > > --
> >> > > ---
> >> > > Yuya Hamada (tekimen)
> >> > > - https://tekitoh-memdhoi.info
> >> > > - https://github.com/youkidearitai
> >> > > -
> >> >
> >> > Hello, Internals
> >> >
> >> > I want to go to "Voting" phase if nothing any comment.
> >> > I will start at tomorrow(26th) to "Voting" phase.
> >> >
> >> > Thank you
> >> > Yuya
> >> >
> >> > --
> >> > ---
> >> > Yuya Hamada (tekimen)
> >> > - https://tekitoh-memdhoi.info
> >> > - https://github.com/youkidearitai
> >> > -
> >>
> >> I think it makes sense to add this function, and the PR worked well
> >> too; It correctly split individual graphemes for all comlex Emojis,
> >> ZWJs, and those Cthulu texts, and everything else I threw at it.
> >>
> >> Good luck for the RFC vote today, hope it passes 🤞.
>
>
> Hi, Internals
>
> grapheme_str_split going to "Voting" phase.
> Vote end is 10th April 00:00 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -
>
Re: [PHP-DEV] Why are serialized strings wrapped in double quotes? (s::"")
On Tue, Feb 6, 2024, at 21:19, 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? > Instead we need to be aware of the leading and trailing " in our state > machine but I'm not sure what the advantage is. Dunno why, but is has made my life much easier. I've seen many situation where serialized data was converted from CP1252 to UTF8. Then the string length changes and unserialization leads to an error condition. Without the quotes possibly many cases would go undetected. > Was this just to make strings look more 'stringy', even though the > format isn't meant to be human-readable? In my mind the format is a nice pragmatic middle between reasonably efficient, reasonably robust, too feature-complete (too many allowed_classes) and somewhat human readable. At least enough for incidental debugging or manual tinkering.
Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions
On Thu, Jun 1, 2023, at 18:02, Janusz Szczypka wrote: > array_find(): This function would allow developers to find the first element > in > an array that satisfies a specific condition. The condition would be defined > by a callback function. This would actually be an alternative to a simple foreach() with an if() and a break. As your example implementation makes clear. array_find() and array_find_key() would still do the same internally, but add a function call adding the overhead of pushing parameters to stack, switching the scope, passing return value back switch scope and pop from the callstack again. If parameters or return value are typed this adds even more overhead. I don't think there is any optimisation possible when this is done in C. To the proposer it probably feels that this is an array function currently missing, but instead it's probably better not to have array_find() because people might actually use it for larger datasets. Although I acknowledge that it will reduce the number of lines of PHP code it doesn't actually reduce the mental capacity to read and maintain code. I find the simple elemental building blocks of loops, conditionals and expressions easier and more expressive. In my experience this is especially so for less experienced developers. Then there is a problem of naming. array_search() and array_find(). To a new developer, how would they know which is which? Also there is the missing array_find_value_and_key() method. Because why should we be limited to either matching the key OR the value? Greetings, Casper
Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`
On Thu, Jun 1, 2023, at 11:56, Boro Sitnikovski wrote: > Thank you for the suggestion, I like this approach and it's definitely much > "safer" than going with an RFC for core directly. > > What are your thoughts on creating a PECL extension called `array_utils` > (selling point would be high performance array utils or something), which in > the future might contain more than `array_group*`, and the approach would be > to cherry-pick those functions that have frequent usage in codebases into > core? Or would it be better to stick to a particular/more concrete extension? I don't know. Also, I have no way of knowing if this would work. Although I mail using my php.net email address, and that could convey some authority, I really do not have that. My contribution to PHP is limited to maintaining the PECL ssh2 extension. Most of what I do is merging stuff other people write, keep an eye on bugs, Toss out GitHub issues when they are not relevant or lack real information, and update documentation. Sometimes chances to extension code are required by changes in the PHP interface. Mostly it's all minor stuff, and not much work. If you end up at the stage where you start writing C code, let me know if you think I can be of value to you. I really value other people's contributions in open source projects and enjoy contributing to create a better working development community. I think there can be value in every step that can be taken in developing software. But you should be very realistic in your expectations of code ending up in PHP core. If you can enjoy the process, see the value in the steps in between, if you are prepared to learn stuff that everyone around here already seems to know but somehow is not written down anywhere except in the code of php or other extensions, it is really fun and will bring you insights that are invaluable in working with PHP. Greetings, Casper
Re: [PHP-DEV] [RFC] [Discussion] Add new function `array_group`
On Thu, Jun 1, 2023, at 01:19, Boro Sitnikovski wrote: > Thank you for the information and encouragement! I was a bit scared of this > one being rejected too, but still decided to give it a shot :) As an alternative approach this is what I would do in your situation: I would start with a PHP implementation, gather some opinions on what this method would do, how it should work. Finalising the functional specification to a point where you find broad acceptance. This would also allow others to help performance optimise your implementation. Then start a PECL extension implementing the exact same thing in C code. This could start as a niche for people that really need the extra performance the extension would bring, possibly grow out to something that is defacto standaard. PECL extensions are documented in the PHP manual, so the manual could have your array_group() function described, possibly with a reference to the original PHP implementation/ polyfill. This approach minimises dependence on internals giving a green light and maximises the possibility to work with others as a team on this. It would give you a chance to prove that the solution you provide is actually wanted by users. If that really is the case, if it came to vote to merging the extension into PHP itself the vote could be different than the vote on the former RFC. Greetings, Casper
Re: [PHP-DEV] Windows PECL build machine died
Nothing seems to happen on this front, and our Windows users like to move to PHP 8.2 too. The windows.php.net site states: "This is because the Windows PECL build machine died, and the team is still working on the long term plan of building DLLs for PECL extensions with a new CI process." We are 1 year since the machine died. 6 month since the statement on the website. From the point of view of our users nothing has changed, and are questioning if the windows project is still alive. I'd like to ask: Is re-inventing the building process really a smart thing to do if it means we'll be out-of-service for more than a year? "We're doing our best to finish that as soon as possible, and keep you up to date." I'm not questioning intentions, but I hate to think this is 'our best'. We should at least have and share a more concrete plan, possibly share a rough timeframe and share if we hit a blocking problem. If help is needed, we should ask. Greetings, Casper
Re: [PHP-DEV] [RFC] Asymmetric visibility
On Mon, Aug 8, 2022, at 10:23, Andreas Heigl wrote: > Your use case might not need them (though actually you are needing them, > you just don't use them as language feature but via the static-analysis > annotation) > > But when discussing language features we should always keep ALL users of > the language in mind. And if a feature helps in providing ways to build > more stable code on the language level then we should think about that > from a point of view of *all* users. I'm saying this reasoning (and the reasoning for the choice of syntax, as Rowan raised) should be part of the RFC. If this is the way the language is developing, it should be documented rather than being argued in a mailing list archive somewhere.
Re: [PHP-DEV] [RFC] Asymmetric visibility
Hi all, In the discussion I sometimes see the terminology 'readonly' and 'writable' being used. This is confusing because when the property is an object that itself is mutable, there is nothing read-only about it. The terminology in the RFC seems right to me, and overall it seems solid. However, I'm not convinced this RFC is solving a real issue. I could not find any reasoning in the RFC, except that Swift has a very similar language feature. Grtz, Casper
Re: [PHP-DEV] Changes to Git commit workflow
On 01-04-2021 06:54, Bishop Bettini wrote:
I've documented why we need signing, and how to set it up:
https://wiki.php.net/vcs/commit-signing
Feedback welcomed!
In "Step 5 of 7: Configure git to use that key ID" you set
`git config --global --replace user.signingkey "${GPG_KEYID}"`
I found that git falls back to sign with a key matching the `user.email`
when `commit.gpgsign` is true. So because I have set user.email for my
php related git repo to langemei...@php.net setting the
`user.signingkey` seems to be unnecessary, and it will pick the right key.
This won't work when user.email is different from the identity in
user.signingkey, but that situation should be avoided.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Bug 61272
On 11/26/2012 10:19 AM, Michael Wallner wrote: I'm sorry that the new output control layer causes you such headaches. IIRC, 6 years back, when I implemented the new output control functionality, I kindly asked the list, whether to rather implement what's documented, or what the old code did, but I have yet been unable to find according mails. And now this code hits production for the first time I assume, if this is the only issue I think you have done a fab job! It pretty well may have been the case that the old code passed the output buffer contents through the handler prior discarding, but as it had not been documented (and I obviously failed to figure out a use case) I apparently implemented the more efficient way it currently is. Hmm.. I suppose It's up to me to make a strong (if possible watertight) plea for the old way. I will try: 1. I don't think my patch impacts the efficiency of php_output_clean(). It adds a single if with a binary compare. True: this causes output to get piped through the output handler, but the output handler callback function could be smart enough to back off when the PHP_OUTPUT_HANDLER_CLEAN bit is set in the second parameter of the callback. 2. Current behaviour is *not* according the documentation. ob_start() documentation states: " An optional output_callback function may be specified. This function takes a string as a parameter and should return a string. The function will be called when the output buffer is flushed (sent) or **cleaned** (with ob_flush(), ob_clean() or similar function) or when the output buffer is flushed to the browser at the end of the request. When output_callback is called, it will receive the contents of the output buffer as its parameter and is expected to return a new output buffer as a result, which will be sent to the browser." (*-emphasis mine) Current behaviour differs: On calling ob_end_clean() or ob_clean(), output_callback is called, but *without* the contents of the output buffer as its parameter. 3. Implementing my patch will never break anything. The output will be passed to the callback, but anything returned by it *will* be discarded. 4. If you are not going to pass the contents of the output buffer on ob_end_clean() or ob_clean() to the callback function, Why would you call the callback anyway? You may think this is a weird feature, this is how we use it: In output_callback we assign the output we catch with output buffering to a string variable, and we use that later on in the request to build our output. Greetings, Casper
[PHP-DEV] Bug 61272
Hi all, Somewhere in May this year I discovered that our software would not run on PHP 5.4 because of changed behaviour of ob_start(). I discovered a bugreport that was marked 'Not a bug', but valuable info was already added to it. I contacted Michael Wallner (mike) directly because he marked the bug 'not a bug'. No response. I decided that this bug was worth my time and invested a few hours into it. I have found that the test that tested it was broken too. I wrote a patch for the bug and the test and added this onto the bug report on June 8th. June 18th I re-opened the bugreport. I just got my php.net account. I thought re-opening the bug would mean it would get noticed by someone. Since then the bugreport gathered some me-too's and one thanks-for-the-patch. (At least my work has made one other person happy so far.) Two weeks ago I emailed Michael Wallner again. No response. I noticed Xinchen Hui (laruence) assigned the bug to mike two days ago. Based on my experiences so far, I don't think he will look into this issue though. Mike, please note that I do not blame you. I understand that free time is very sparse and valuable and for most of us doing any work on an open source project is done in free time. Can someone please look into this? I've written all I know in https://bugs.php.net/bug.php?id=61272 but I'm available to discuss the patch by email or in #php.pecl Greetings, Casper
