Re: [PHP-DEV] New RFC : empty() function

[Hamza Ahmad]

Hi there, it's a legacy function, and I don't think we can afford or
we should consider this bc break. Though I don't use this function
myself and also prefer other methods of input validation, still there
are a lot of people that use it. Renaming this to is_empty will bring
a bc break. However, the improvements to this function are worth
considering.
Ahmad

On 10/30/23, Alessandro Rosa  wrote:
> Thanks everybody for joining this discussion.
> I appreciated a lot  the points you raised, as they are helping me to
> update and improve my rfc,
> whose meaning, as I hope, would look clearer than the earlier version.
>
> Improvements must be achieved, whatever they would cost.
> Ambiguities shall be resolved. I think this is the first principle in
> computer science: 0 or 1 ! :-D
> In any case, they are not assumed to be resort into cut-off transitions:
> they may be achieved within 3, 4 or 5 versions.
> Don't be scared.
> I have implemented my version in my own library and it works like a charm:
> you'll have exactly what you read.
>
> Alessandro Rosa
>
> Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife  ha
> scritto:
>
>> >
>> > This is exactly where the problem lies. Is a string with just
>> > whitespace
>> > empty? Why would an ArrayObject with count 0 not be considered to be
>> empty
>> > while an array with count 0 is? "empty" is subjective and therefore not
>> > a
>> > reliable function to use. Especially in legacy code I find that people
>> use
>> > `empty` where they should've been using `count() === 0` and have
>> > resulted
>> > in bugs that weren't discovered until months or years later. The
>> variations
>> > of `$a === ''`, `count($a) === 0`, `! isset($a)`, and `$a === null`
>> already
>> > check all the scenarios you need, without risking funky bugs due to how
>> the
>> > internal check for "falsy" values works.
>> >
>>
>> trust me, Ive worked on some terrible code bases that do
>> exactly that and have variables redefined or dynamically assigned
>> and you have to really check if it has been assigned a value or
>> not and what value.
>>
>> It might be forgotten by everyone because of how far PHP has come
>> but there is still extensive use of the @ suppressor and the
>> alternative to empty would be
>>
>> if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
>>
>>
>> empty() is 1 of 3 functions i believe that does not throw an undefined
>> variable warning if you don't @ suppress the variable you are passing in.
>>
>> So if you want to get rid of empty, can we reignite the talks to finally
>> get rid of @
>>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Two Issues regarding Named Parameters; want to understand the technicality

[Hamza Ahmad]

Hi Kamil,

Thank you for your response. I shall sure create an issue and will
update in this threat.

On 3/9/23, Kamil Tekiela  wrote:
> Hi Hamza,
>
> If you encounter a bug, please create a GitHub issue with reproducible
> steps. Your description of a program crashing is not actionable, as we
> cannot reproduce this error.
>
> Regarding your second point, how do you want this to work? $names is just a
> collection of string parameters. It's not a single parameter so you cannot
> refer to it by name. When you use named parameters with variadic
> parameters, then the names you specified will be used as array keys. So no
> error there, and no warning should be raised. But I don't know what you had
> in mind of how this is supposed to work.
>
> Regards,
> Kamil
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Two Issues regarding Named Parameters; want to understand the technicality

[Hamza Ahmad]

Hello Internals,

I am writing to discuss an issue that I have encountered while using
named parameters in two of my projects. Although named parameters have
made it easier
to call functions without passing extra parameters, I have found that
relying solely on them can cause problems.

In my first project, I have been using named parameters while calling
com methods of Office VBA, as advised by Microsoft Docs. However, when
I try to use
named parameters in PHP, my program crashes, and I have to manually
close any open applications.

I would like to request a fix for this issue. If it is impossible to
obtain the list of parameter names in COM, could we receive a warning
instead? If
the list of parameter names is obtainable, it would be great if this
could be fixed in version 8.3 or earlier.

In my second project, I did not receive a warning when I passed the
wrong parameters. To give you an example, I have two constructors:
1.   ` public function __construct(int $date, int$month, int $year) `
2.   ` public function __construct(string ...$names) `
When I initialized the latter object with the former object's
signature i.e., `new LatterObject(date: 1, month: 1, year: 1970);
`, I did not receive a warning of passing the wrong parameters.

I would appreciate it if you could look into these issues and provide
me with any suggestions for solutions. Thank you for your prompt
attention to this
matter.

Best regards,

[Hamza Ahmad]

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP build for the wasm32-wasi target

[Hamza Ahmad]

HI Rafael,

I am happy to here that you guys are working on this. I once thought
of writing such a solution myself for PHP when I learnt it compiled c.
However, I could not manage time. I am positive it will be useful.

NVM< I don't know why Google has marked your email as spam. Likely,
that's why, you have not been responded as yet.

Best


On 12/22/22, Rafael Fernández López  wrote:
> Hello community,
>
> I am reaching out on behalf of the WasmLabs team at the Office of the CTO at
> VMware.
>
> We have been working on building PHP for WebAssembly, specifically for the
> wasm32-wasi target. WASI [1] is a system interface that allows WebAssembly
> to run on the server side by safely being able to access operating
> system-like features, including files and filesystems, Berkeley sockets,
> clocks and random numbers [2].
>
> WebAssembly in the server side is experiencing a big growth both in interest
> and users. There are other programming language interpreters that can be
> compiled to wasm32-wasi as of today; for example: Python [3] and Ruby [4].
>
> We have patches for PHP 7.3.33 and 7.4.32 at the time of writing. Porting
> PHP 8.2.0 is work in progress at this time.
>
> In the interest of getting feedback from the PHP community I am providing
> links to the patches at GitHub. Please, let us know what would be the next
> step to contribute and continue to maintain this work upstream. We look
> forward to work with the PHP community.
>
> If you want to try it out, you can download the binaries we are producing in
> the CI/CD pipeline for 7.3.33 [5] and 7.4.32 [6]. You can use a WASI-enabled
> WebAssembly runtime such as Wasmtime [7] to run PHP compiled to
> wasm32-wasi.
>
> Patches: 7.3.33 [8], 7.4.32 [9][10].
>
> Example execution:
>
> ```
> $ wasmtime -- --dir ~/php-example php-cgi-7.4.32.wasm
> ~/php-example/hello/index.php
> X-Powered-By: PHP/7.4.32
> Content-type: text/html; charset=UTF-8
>
> Hello, world!
> ```
>
> We have already presented some of this work at OSS conferences and events
> like Kubecon and Docker Community days, and have written a few articles
> providing the background to the port, its limitations and what can currently
> be accomplished (including running WordPress!). Please find below some links
> to the talks and articles:
>
> - Porting PHP to WebAssembly using WASI  [11]
> - Running WordPress with WebAssembly using mod_wasm and Apache  [12]
> - WebAssembly: Docker without containers! [13]
> - mod_wasm: Bringing WebAssembly to Apache [14]: this talk builds on top of
> PHP 7.3.33 and shows WordPress running with sqlite on top of Apache, thanks
> to an Apache module (mod_wasm) that is able to execute WebAssembly modules.
> - Docker and WebAssembly, better together [15]: this presentation features
> PHP 7.4.32 and explains a bit of the context of this work.
>
>
> Thank you,
> Rafael Fernández López.
>
> [1] https://wasi.dev/
> [2]
> https://github.com/bytecodealliance/wasmtime/blob/03463458e426d4bd0601ebd82e95b668fc982443/docs/WASI-intro.md
> [3] https://docs.python.org/3/whatsnew/3.11.html
> [4] https://www.ruby-lang.org/en/news/2022/12/06/ruby-3-2-0-rc1-released/
> [5]
> https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.3.33%2B20221124-2159d1c
> [6]
> https://github.com/vmware-labs/webassembly-language-runtimes/releases/tag/php%2F7.4.32%2B20221124-2159d1c
> [7] https://wasmtime.dev/
> [8]
> https://github.com/vmware-labs/webassembly-language-runtimes/tree/main/php/php-7.3.33/patches
> [9]
> https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0001-Initial-port-of-7.3.33-patch-to-7.4.32.patch
> [10]
> https://github.com/vmware-labs/webassembly-language-runtimes/blob/main/php/php-7.4.32/patches/0002-Fix-mmap-issues.-Add-readme.patch
> [11] https://wasmlabs.dev/articles/php-wasm32-wasi-port/
> [12] https://wasmlabs.dev/articles/running-wordpress-with-mod-wasm/
> [13] https://wasmlabs.dev/articles/docker-without-containers/
> [14] https://www.youtube.com/watch?v=jXe8kulUscQ
> [15] https://youtu.be/yo30oF1Gflo?t=7361
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Please allow an out of readonly properties

[Hamza Ahmad]

Hello,

If we keep the idea of using reflection aside, I still have a reason
to consider readonly flag for private properties. There are two main
uses I consider of readonly properties: prevention of property
modification from the public scope and the securing the property from
losing an important handle. What if the properties are set readonly
with the private scope, so they are secured from getting modified,
even within a class. IF it is a protected and read only property, it
can also be further secured in sub classes.

Internals, I want to appreciate Andreas for choosing a considerate
tone for communicating the opinion that is different from the opinion
shared above. What if we all at least try and adjust the tone like
Andreas has done?

Regards

Hamza


On 12/4/22, Andreas Heigl  wrote:
> Hey there
>
> On 03.12.22 23:55, Karoly Negyesi wrote:
>> They refuse to compromise even on documentation issues. I am totally
>> helpless. Not sure what could be done?
>
> When people design their systems and use final, private or readonly,
> they have a reason for that. They have a plan on how their library
> should be used and also how their library should not be used.That is the
> API that is exposed via public methods that is described in the
> documentation.
>
> When *your* code can only make use of a library by tweaking these
> constraints, you are using the library in a way that is not intended by
> the authors.
>
> There can be two reasons to that: Either you know exactly what you are
> doing and you are willing to risk that the way you are using said
> library might break with every patch version as the internal workings
> might change.
>
> HERE BE DRAGONS: I sometimes actually need to do that (even with a
> library I wrote myself) but instead of using reflection I then tend to
> use monkey-patching in that case and actually rewrite the code of the
> lib on installation. That way the execution is faster as I do not rely
> on reflection but can access a public property directly.
>
> Or - and that is most of the time the case - you are using the library
> wrong or even using the wrong library.
>
> And as you already contacted the authors and they declined your request
> to change their API, the chances are high, that you are using their
> Library in an unintended way.
>
> In that case you should reconsider what you are doing. Am I using the
> right library? Why could I be using the library wrongly? How can I
> change my code to use the provided API of the library?
>
>
> In the end it always boils down to: Check whether your usecase is what
> the library is intended to solve. And if there is no way around
> rewriting upstream code: You are on your own! You can not rely upon
> anything. Not even language features. You are not using upstream code,
> you are abusing it.
>
> My 0.02 €
>
> Cheers
>
> Andreas
>
>>
>> On Sat, Dec 3, 2022 at 2:48 PM Marco Pivetta  wrote:
>>
>>> Talk to the designers then: bringing your own political issues up to the
>>> programming language/tooling only makes it worse long-term, for everyone
>>> 
>>>
>>> On Sat, 3 Dec 2022, 23:45 Karoly Negyesi,  wrote:
>>>
 I do not have the luxury of designing my own system. I am forced to use
 upstream. I can't help it and given the history of private usage and
 the
 refusal on relaxing them I do not see this improving with the readonly.
 At
 all.

 On Sat, Dec 3, 2022 at 2:42 PM Marco Pivetta 
 wrote:

> Terrible idea: reflection is mostly introspection tooling, and doesn't
> really bend the rules of the type system, other than crossing scope
> (it
> "sees" more).
>
> Please consider designing your system to consider the constraints of
> `readonly` properties, or design the constraints to fit your system
> instead.
>
> Marco Pivetta
>
> https://twitter.com/Ocramius
>
> https://ocramius.github.io/
>
>
> On Sat, 3 Dec 2022 at 23:39, Karoly Negyesi 
> wrote:
>
>> Hello,
>>
>> If push comes to shove, private properties can be changed with
>> reflection.
>>
>> Readonly properties can't.
>>
>> Please add a readonly toggle to reflection.
>>
>> Thanks
>>
>> Karoly Negyesi
>>
>
>>
>
> --
>,,,
>   (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org   |
> +-+
> | https://hei.gl/appointmentwithandreas   |
> +-+
> | GPG-Key: https://hei.gl/keyandreasheiglorg  

Re: [PHP-DEV] Re: Alias for `int|float`

[Hamza Ahmad]

After reading through all of the suggestions above, I have come to
this conclusion that all suggestion can be incorporated in the
following ways:
Types can exist in name spaces, Either in the global namespace or in
the user defined name spaces. If one wants to import a type from a
name space, it can easily use "use" statement per file. Alternatively,
it can include a namespace and it does all that handy job for the dev.
I agree with the idea of creating an RFC and document all use cases,
possible ways to implement and also the features that can be added
currently or will be left for the future scope.

Regards
 Ahmad

On 9/30/22, Olle Härstedt  wrote:
> 2022-09-30 17:16 GMT+02:00, Larry Garfield :
>> On Fri, Sep 30, 2022, at 4:04 AM, Olle Härstedt wrote:
>>> 2022-09-29 5:08 GMT+02:00, Hamza Ahmad :
>>>> Hi Olle,
>>>>
>>>> I appreciate your idea of introducing a similar concept of typedef.
>>>> What if you write an RFC explaining that concept. I can join you
>>>> however in co-authoring this request.
>>>>
>>>> Seriously, I have had issues with writing such type again and again.
>>>> If you look at mixed type, it is indeed an alias of some union types.
>>>> Adding such an option to userland would lead to introduction of
>>>> various type hints. Plus, it will help devs write short hand aliases
>>>> for their intersection types.
>>>
>>> Note that my suggestion here is NOT about a project-global type alias,
>>> but an extension of the existing file-only alias, the use-statement.
>>> This can also explain the lack of reaction. :) Internal devs might
>>> already have consensus on the right way to proceed here, even if
>>> there's no RFC yet.
>>
>> Background:
>>
>> Type aliases have been discussed several times.
>
> Ya ok, not what I could find in externals.io ^^
>
>> There's definitely
>> interest, but like many things it runs into the problems of time and
>> figuring out the details.
>>
>> In particular, I don't get the sense that there's much appetite for
>> file-local aliases.  While that would have some benefit, it could lead to
>> all kinds of confusion when then using code from another file.  Consider:
>>
>> A.php:
>>
>> use int|float as number;
>>
>> interface A
>> {
>>   public function a(number $a) {}
>> }
>>
>> B.php:
>>
>> // Yeah, aliasing this is very helpful.
>> use (Request)|(ServerRequest)|array|null as input;
>>
>> interface B
>> {
>>   public function b(input $b) {}
>> }
>>
>> C.php:
>>
>> class C implements A, B
>> {
>>   // Which of these to use?
>>   public function a(int|float $a) {}
>>   public function a(number $a) {}
>>   // Or do I need to repeat the definition of "number" in every file?
>
> Yes, you would. That's the limit of my current suggestion. Same
> semantics as use-statements.
>
>>   // WTF do I do here? Do I have to repeat the entire definition either
>>   // inline or in this file's "use" block?  Both suck.
>>   public function b(...)
>
> Neither suck. :) Just "normal" inheritance boilerplate in the absence
> of project-global type aliasing.
>
> Do you have similar counter-examples for non-OOP code?
>
>> }
>>
>>
>> This becomes even more of an issue when you start talking about function
>> types, which is often mentioned as the primary use case.
>>
>> type fn(int $a, string $b): Request as mycallback
>>
>> function do(mycallback $callback) {}
>>
>> So I have to duplicate the type def in every file now?  This is not an
>> improvement.
>
> It's an improvement for readability, especially when repeated in one
> file. But my suggestion does not include function-types, because
> there's no such thing already in the system. Just to let use-statement
> include more of already existing types. If function-types were added
> later, they should be supported too, yes.
>
>>
>> So we have to go with app-global aliases, but then... how do you handle
>> resolution?  Autoloading?  Namespacing?  Conflict resolution?  I dunno,
>> that's all hard, and that's where the conversation usually peters out.
>
> Yeah, always better to have a clear limitation, is it not? :D
>
>> The degenerate case you mention of simple type renaming has its own
>> interesting implications, which are also a factor for the broader case.
>> Specifically, does that create a new type unto itself
>
> No. Keep the same semantics of the curr

Re: [PHP-DEV] Re: Alias for `int|float`

[Hamza Ahmad]

Sadly, I am disappointed with the way this suggestion has been looked down on.

On 9/29/22, Olle Härstedt  wrote:
> 2022-09-29 12:33 GMT+02:00, Ryan Jentzsch :
>> `number` type But frankly this seems a bit silly and reminds me too much
>> of
>> JavaScript.
>
> That's just an example. You can also consider `use array|ArrayAccess
> as arraylike`, or such.
>
> Olle
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Alias for `int|float`

[Hamza Ahmad]

Hi Olle,

I appreciate your idea of introducing a similar concept of typedef.
What if you write an RFC explaining that concept. I can join you
however in co-authoring this request.

Seriously, I have had issues with writing such type again and again.
If you look at mixed type, it is indeed an alias of some union types.
Adding such an option to userland would lead to introduction of
various type hints. Plus, it will help devs write short hand aliases
for their intersection types.

Regards

Ahmad


On 9/27/22, Olle Härstedt  wrote:
>>Hello, internals!
>>
>>What do you think about creating shorthand `number` for `int|float`?
>
> This is also related to allow all types of type-hints in the use-statement,
> like
>
> use int|float as numeric;
>
> Anyone interested in creating an RFC for this?
>
> Olle
>
> PS. Original thread here: https://externals.io/message/112209#112209
> (dunno how to respond to an old thread when I don't have the original
> message)
>
> --
> 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

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

[Hamza Ahmad]

> We spend a lot of time to increase limits for uploads file in PHP.
For a lot of time, I assume you are using a web host that does not
allow modification to INI file directly or using INI functions, and
you have to contact your host provider for that change. Otherwise, it
is not that difficult to apply that change. Plus, this question would
have been answered in a php forum, like phpearth.
> I'm not against increasing the sizes, but 50MB might be too much.
It is possible on userland as well as configuration level. I don't
feel like it is worth doing. It will  break some websites. Most of the
projects go with default options of upload; thus, doing so will make
issues for such projects.
> By the Way... This needs an RFC right?
This change should be made with an rfc. Because it will impact a
majority of projects, and usually devs doant have to have that huge
limit. Plus, there are razed further concerns that

On 9/10/22, Yasuo Ohgaki  wrote:
> 2022年9月10日(土) 23:23 David Gebler :
>
>> On Sat, Sep 10, 2022 at 3:05 PM juan carlos morales <
>> dev.juan.mora...@gmail.com> wrote:
>>
>>> I also agree that increasing the size to something bigger than 8M
>>> might not be a good idea; I can imagine that a value bigger than 8M
>>> (like 50M) will cause an impact in hosting platforms specially, which
>>> will be forced to always change the php's default values to a lower
>>> one, because of potential DoS Attacks.
>>>
>>> Default settings should have a reasonable level of security in mind.
>>>
>>
>> Do these settings actually have any impact in respect of DoS attacks? As
>> far as I'm aware, neither post_max_size nor upload_max_filesize do
>> anything
>> to prevent or terminate processes where the client sends data exceeding
>> these limits, that's something you should handle in your webserver.
>>
>
> For example, password hash DoS attack was made possible  because PHP allows
> 8MB post data.
>
> https://www.acunetix.com/vulnerabilities/web/long-password-denial-of-service/
>
> IIRC, Drupal has a security release for this.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Hamza Ahmad]

A yes from my side.

On 3/4/22, Joe Watkins  wrote:
> Morning internals,
>
> Today, some friends of the project, people we consider leaders even, are
> waking up in a war zone.
>
> They are living an unimaginable horror, and as I sit here and type, I fight
> back tears for them ... I am afraid for them, their families, their lives.
>
> The feeling of helplessness is overwhelming.
>
> However, here is where we develop PHP: This space is free of everything
> that is nothing to do with the development of PHP.
>
> Obviously, we are not bad people for not wanting to make this space about
> non-php things.
>
> I would kindly ask that this conversation, which is not about PHP
> development, is moved to more appropriate channels:
>
> Please remember that when you email the list you are communicating not only
> with the person you are replying to, but with everyone that ever subscribed
> to the list.
>
> When you conduct protracted conversations that are nothing to do with PHP,
> it is tantamount to spamming those people.
>
> Cheers
> Joe
>
> On Fri, 4 Mar 2022 at 09:25, Lynn  wrote:
>
>> On Fri, Mar 4, 2022 at 9:17 AM Kalle Sommer Nielsen 
>> wrote:
>>
>> > Den fre. 4. mar. 2022 kl. 01.18 skrev Lynn :
>> > > Not making a statement is also making a statement.
>> >
>> > I disagree, assuming a stance without understanding the context is
>> insanity
>> >
>> >
>> What context are we not understanding?
>>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Hamza Ahmad]

HI Nikita,

What if you consider this instead? Rather allowing STD class as an
exception to dynamic properties, why not introduce STDAbstract?
```php
interface STDClassInterface
{
public function __get(string $name) : mixed;
public function __set(string $name, mixed $value = null) : mixed;
/* * other magic methods */
};
abstract class STDClassAbstract implements STDClassInterface {/* *
interface methods */}
Class STDClass extends SDTClassAbstract{}
``

Best
Hamza

On 8/25/21, Rowan Tommins  wrote:
> On 25/08/2021 11:02, Nikita Popov wrote:
>> I'd like to propose the deprecation of "dynamic properties", that is
>> properties that have not been declared in the class (stdClass and
>> __get/__set excluded, of course):
>>
>> https://wiki.php.net/rfc/deprecate_dynamic_properties
>
>
> This is a bold move, and in principle seems sensible, although I'm
> slightly scared how many places will need fixing in legacy code bases.
>
> I have a couple of concerns with using stdClass as the opt-in mechanism:
>
> * The name of that class already leads to a lot of confusion about its
> purpose - it's not actually "standard" in any way, and new users seeing
> it as a base class are even more likely to mistake it as some kind of
> "universal ancestor". Would it be feasible to introduce an alias like
> "DynamicObject" which more clearly defines its role?
>
> * Adding a parent to an existing class isn't always possible, if it
> already inherits from something else. Perhaps the behaviour could also
> be available as a trait, which defined stub __get and __set methods,
> allowing for the replacement of the internal implementation as you've
> described?
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> 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

Re: [PHP-DEV] Request for karma to vote on RFCs

[Hamza Ahmad]

I am not going to critique the RFC; rather, I say that this RFC needs
a fresh rewrite because I find more like it a set of instructions. The
proposal needs to be a detailed one. It seams as if it is written
hastily.

As Tobias has mentioned that he has been reading the RFCs for years,
there is a large number of people that do the same. After this
discussion has been started, people are closely observing the dialog
and waiting for their chance to become a voter.

Thus, there needs a clear framework that will lay a foundation for the
future of PHP. There are a lot of voters out there, but you will
hardly see 60 or 70 voters participating in the process. There needs
to be a system that provides others obtain the right to vote and
contribute to the language. Here, Tobias is not a single instance. I
honor him and also respect the other community members that want to
vote for the features. Many feature requests were declined just
because 25 to 30 people had disliked them.

Meanwhile, nobody wants a rush. Thus, the policy should be flexible
enough that it incorporates the great talent. It should not be that
strict that nobody ever tries to partake in the process, nor that
flexible that somebody establishes its feed and one day hack the
source. We have seen how hackers tried to use Nikita's name for their
own purpose. Why cannot a hackers group try to join the team?

To avoid such incidents. One should not get merging rights after
getting voting rites. Rather, it should be a separate process. Also,
it should be cleared, so the language development is successfully
passed on to the next gen. I have another idea that can initially
allow Tobias and other community members participate in the process.
What about 80 20 system? 80 percent vote will come from the current
voters and 20 percent from the community.

Best

Hamza

On 7/20/21, Aleksander Machniak  wrote:
> On 20.07.2021 08:22, Andreas Heigl wrote:
>
>> the requester has contributed to the PHP sourcecode ecosystem. That
> can be (but is not limited to):
>>Contributions to the PHP-Sources
>>Contributions to the Documentation or the Translation
>>Triage, solve or otherwise interact with bugs
>
> Voter would need an easy way to verify that information. Otherwise we'll
> be facing "-1, because I can't verify or have no time to do it" votes.
>
>>Help in the maintenance of the PHP Infrastructure
>
> This has nothing to do with PHP language, and it cannot be verified by
> anyone. I suggest to remove this point.
>
> I think the voting would need to be in a form we're using for RFCs,
> counting votes on mailing list will be error-prone and time-consuming
> (you don't know who's a voter).
>
> --
> Aleksander Machniak
> Kolab Groupware Developer[https://kolab.org]
> Roundcube Webmail Developer  [https://roundcube.net]
> 
> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
>
> --
> 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

Re: [PHP-DEV] Request for karma to vote on RFCs

[Hamza Ahmad]

> Sounds like we need an RFC to make it clearer how voting karma for the
> RFC process will be granted in the future.

Yes, I agree. I would love to join that team, which is going to
prepare this RFC. Plus, I have shared some of the ideas in the
previous message.

Best

Hamza

On 7/19/21, Andreas Heigl  wrote:
> Hey All
>
> Am 19.07.21 um 16:34 schrieb Levi Morrison via internals:
>> On Mon, Jul 19, 2021 at 2:38 AM Nikita Popov 
>> wrote:
>>>
>>> On Sun, Jul 18, 2021 at 8:48 PM Tobias Nyholm 
>>> wrote:
>>>
 Hey.
 I would like to get karma to be able to vote on RFCs. I understand that
 voting karma isn’t usually given out to people who write their first
 mailing list entry.

 But I do believe I qualify as “Lead developers of PHP based projects
 (frameworks, cms, tools, etc.)”
>>>
>>> Hey Tobias,
>>>
>>> My response here is basically the same as the last time the topic came
>>> up:
>>> https://externals.io/message/110936#110937 Voting is just the very last
>>> step of the RFC process, at which point the proposal can no longer be
>>> influenced. If you have feedback about a proposal based on your
>>> extensive
>>> experience in PHP's open source ecosystem, then the discussion phase is
>>> the
>>> time to provide it, while it can still influence the proposal, as well
>>> as
>>> other people's view of the proposal.
>>
>> I second this.
>>
>>> At least in my personal opinion, I think it's important that people
>>> granted
>>> voting rights as community representatives have at least some historical
>>> involvement in RFC discussions.
>>
>> I agree with this, but have no specific objection to granting Tobias
>> voting karma, as this is underspecified; how long should they
>> participate? What kinds of involvement are appropriate? Being
>> underspecified is not really their fault, and I don't feel like it
>> would be an abuse to grant them voting karma, but do think it would be
>> an abuse to deny them voting karma indefinitely because "we" don't get
>> around to specifying it. It should be less of a decision on a
>> case-by-case basis and more of a checklist.
>>
>
> Sounds like we need an RFC to make it clearer how voting karma for the
> RFC process will be granted in the future.
>
> Looking forward to your inputs.
>
> Cheers
>
> Andreas
> --
>   ,,,
>  (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org   |
> +-+
> | https://hei.gl/appointmentwithandreas   |
> +-+
>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Request for karma to vote on RFCs

[Hamza Ahmad]

Hello all,

Tobias wants to obtain a right that lets him represent the community
in the RFCs' approval. Tobias, as for the feature requests, you can
discuss and propose your own ideas. You can also obtain RFC karma to
propose your ideas and contribute to the language.

As for the people that are going to give the final vote, PHP
maintainers need to make a proper policy for this process. I am going
to give a basic idea. They can better brainstorm.

The person that wants to have the voting rights may qualify for the following:
1. The person may have RFC karma already.
2. After obtaining an RFC karma, it may have been active on the
mailing list for a specific time period.
3. It may have n number of bugs solved and merged.
4. It may have worked with senior developers of php at least on the n
number of RFCs.
5. Optionally, it may have some of his own RFCs approved or rejected
with minimum percentage.
6. Every person that gets voting rights may have fulfilled the conditions above.

When it qualifies for the above conditions, it can apply for the
voting karma. The people with the voting rights can recognize its
efforts and contributions for the language and finally allow a voting
karma. The karma will be rewarded with a simple majority after a vote.
The conditions that I have suggested above assess following:
1. The person is well aware of PHP and its built system.
2. The person is able to resolve bugs, add new features and improve
existing ones.
3. The person well understands PHP's nature and is able to form the
ideas accordingly.

Tobias's scale of qualification will motivate a large number of people
to ask for the voting rights, and they have the equal right to get the
right to vote. It doesn't matter a core developer maintains n number
of libraries. The thing that matters is the understandability of the
core. If one is able to contribute to the language and its efforts are
visible to the core developers and the community, it may have a voting
right. Yes, having developed numerous libraries can be an edge. Nobody
will object because one receives a karma according to a set policy.

Additionally, when there emerges a policy, it will motivate people to
partake in the discussions, practice their hands on the PHP core and
leverage the company of senior developers. Power to you all.

Best


On 7/19/21, Kalle Sommer Nielsen  wrote:
> Den man. 19. jul. 2021 kl. 13.14 skrev Lynn :
>> Currently there are people with voting permissions that do vote, yet do
>> not interact with RFCs or the mailing list. Regardless of the reasons one
>> may have for wanting to vote, the requirements given should be applied
>> equally if this is the argument.
>
> If this is a problem, then why has the voting RFC not been amended to
> require such commentary? That seems like a productive first step in
> solving the issue instead of complaining about it not happening
> automatically
>
>> Yes, and I love it when I see new users interact with the mailing list,
>> even when in the end the questions or arguments changed nothing to the
>> RFC. It shows that people are probably invested. How do you measure
>> investment behind the scenes though? How often has someone decided to not
>> post anything on the mailing list because after testing a bunch of changes
>> proposed, it worked and required no comment?
>
> How can I take that into consideration if no one lets me know about
> that? This argument sounds more to me like an illusion, I cannot read
> minds nor am I into experimentation on the matter, I cannot consider
> what I do not know (similarly to the problem you pointed out above).
>
>> Would every user that one day would want to have voting rights post a "yes
>> I agree" message in every thread in order to show they contribute in
>> discussions?
>
> That is not what I was implying and I am certain you know that. I
> specifically mean the discussions, not the voting itself. Taking
> Tobias here as an example, why is there no feedback from him on the
> RFCs like[1][2][3] (which was recent as in 8.1, this is just a list
> from a quick glance which may or not be accurate), they seem to me
> like an good way he could have given feedback based on the work he put
> forward that he had been involved with.
>
> Why is it that political power should just be given without actually
> taking part of the project and problems here at the PHP project? To me
> that comes off as laziness. "I just want to vote, but take no
> responsibility of maintaining the PHP project"
>
> [1] https://wiki.php.net/rfc/curl_user_agent
> [2] https://wiki.php.net/rfc/fsync_function
> [3] https://wiki.php.net/rfc/fibers
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> 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

Re: [PHP-DEV] [Vote] Partial Function Application

[Hamza Ahmad]

Hi all,

While I was reading through the discussion, I found a question related
to the conflict of constant names and functions names. In other words,
`strlen` can be both a constant name and a function name. Thus, in
pipe RFC, it can go confusing whether it is a constant or a function
name when called this way:
```
'abc'
|> strtoupper
|> md5(?, true)
|> bin2hex
|> base64_encode;
```

In Javascript alert and confirm are by default names. In reality, they
are methods of window object. When they are assigned to a new value,
they don't give a reference to the methods of window object.

When a function or a method name is referred without parenthesis,
JavaScript returns the function object. It is Useful because it does
not require quoting. For example, `window.setTimeout(alert, 1000);`.
A more popular example is `if (window.XMLHttpRequest)`.

Even I tested this, and it worked. I hated this behavior.
```
function ok(){};
console.log(typeof ok);
ok = 123;
console.log(typeof ok);
```

In PHP, all in-namespace symbols are first searched in the namespace.
If not found, they are looked in the global namespace. If still not
found, the error is thrown.

In the light of these two examples, I have these suggestions:
1. declare all function/method names respectively constants and
variables by default and make them modifiable. This functionality is
present in OOP; it is possible to redeclare constants and methods that
are non-final.
2. As you have removed the ability to declare a case-insensitive
constant, stop invocation of function names case-insensitively. Of
course, it requires an RFC.
3. Disallow declaration of constants and using the names of functions
static methods. Same applies to variables and non static methods of a
class. As a result, no one can declare `strlen` as a constant. If one
tries to make a method with a name of a property, it will also get an
error.

I don't know how many bc breaks these applications will bring. If they
are approved, I am sure it will not only solve the problem that gave
birth to this idea, but also it will prevent bad practices. For
example,
```
 wrote:
> 2021-06-30 19:10 GMT+02:00, Larry Garfield :
>> On Wed, Jun 30, 2021, at 8:59 AM, Olle Härstedt wrote:
>>
>>>  > I've been pondering if a completely different approach with a prefix
>>>  > symbol would be able to be less complex, and the simple answer is I
>>>  > have absolutely no idea.  But we are running low on symbols...
>>>
>>>  Ah, I found the technical details that Joe gave me (right after I hit
>>> send, of course).  Quoting Joe:
>>>
>>>  "the engine expects certain things to happen, and is designed and then
>>> optimized around those assumptions ... for example, a stream of INIT,
>>> SEND, DO_FCALL is not meant to be interrupted, the first fundamental
>>> change you have to make is making the engine aware that stream of INIT,
>>> SEND, + are not always followed by DO_FCALL "
>>>
>>>  So yes, it sounds like hooking into the function call process is where
>>> the complexity comes from.  Which suggests that an approach that works
>>> using a different syntax that desugars to a closure would avoid that
>>> issue, but then we need a syntax that wouldn't be ambiguous, and that's
>>> getting harder and harder to find.  (Nikita's first-class-callables RFC
>>> notes some of the issues with available symbols, and they're
>>> essentially the same for partials either way.)  And I've been told that
>>> creating closures in the AST compiler is Hard(tm)...
>>>
>>>  --Larry Garfield
>>>
>>>
>>> Wrapping stuff in lambdas is otherwise the obvious solution, no? Make
>>> `strlen(?)` evaluate to `fn ($x) => strlen($x)`. Does it depend on the
>>> level of look-ahead in the compiler why it's so hard? Didn't work much
>>> with scripting language internals.
>>>
>>> Olle
>>
>> The tricky part is that conversion has to happen entirely at runtime,
>> because we need the type information from the function being partialed,
>> and
>> at that point creating an actual closure is, apparently, rather hard.  It
>> cannot be done up at the AST level where it would be conceptually much
>> easier.
>>
>> We've been discussing this for the past several days in chat, and the
>> basic
>> conclusion is that the PHP engine does not offer any easy way to do this.
>> It's one hard-and-messy approach or another hard-and-messy approach.  So
>> far
>> no one has figured out a not hard-and-messy way to make it work,
>> regardless
>> of performance.
>>
>> --Larry Garfield
>
> Alright, alright. Guess I have to learn a bit more about the different
> passes inside the compiler. :) Thanks.
>
> Olle
>
> --
> 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

Re: [PHP-DEV] [VOTE] Readonly properties

[Hamza Ahmad]

Hi Nikita,

It is going to be the second contribution from you regarding OOP.
However, this proposal, as you have mentioned, has some issues with
cloning. What if you would have opened voting after fixing this?

Or, your mood is to get it passed and then fix it before final release of 8.1?

Thank you

Hamza Ahmad


On 7/1/21, Nikita Popov  wrote:
> Hi internals,
>
> I have opened voting on https://wiki.php.net/rfc/readonly_properties_v2.
> The vote closes 2021-07-15.
>
> See https://externals.io/message/114729 for the discussion thread on this
> proposal. I think a decent tl;dr is that readonly properties as proposed do
> not play well with clone-based withers, so some people believe we should
> either improve cloning first, or introduce asymmetric property visibility
> instead, which does not suffer from this issue.
>
> Regards,
> Nikita
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.

[Hamza Ahmad]

Being positive is good but relying on others is not. If you really
believe that your idea is worth considering, I suggest revisiting it.
You can ask your self the following questions:
  - How is it useful?
  - what special thing does it provide with that the current
implementation does not?
  - What could be the better syntax?
  - Does any other language have the similar feature?
  - If yes, what is the benefit?
  - Will your idea cause any BC break?
  - Do your proposed syntax make any confusion?
  - How can you make it further clear?

If you have answers to all of these questions, you can come and
convince the people here. Still, I don't find your proposal till now
that compelling.

Rather considering the opinions shared here as an offence, take them
positively and redesign your thought.

Best

Hamza

On 6/30/21, Manuel Canga  wrote:
>
>   En mié, 30 jun 2021 14:29:40 +0200 G. P. B. 
> escribió 
>  > Ignoring the fact that this proposal is way past the cutoff date to be
> able to make it into PHP 8.1 due to how the RFC process works,it seems that
> this feature just came into your mind and you decided to send it onto the
> list without considering its ramifications.Userland contribution and
> opinions on new features (or other internal discussion) is valuable but
> oughts to consider all the ramifications, good and bad, and how it affects
> the language as a whole. I say this because I didn't do this when I started
> contributing on this list and it made for less than stellar discussions.
>
> Hi, George,
>
> I am not an expert in developing programming languages. However, I don't
> agree with that.
>
> When Dennis Ritchie and Brian Kernighan developed C. They didn't think in
> avoid pointers because of they thought what they could be dangerous.
> Surely when someone invented air planes, he didn't think of risks but
> opportunities
>
> It was my fault. I thought that someone here would propose an idea and if
> this was useful, then everyone would find the best way to put it into code.
>
> With last Rowan email, I understood that this purpose is useless. However,
> if it had been useful, I had expected answers like:
> "hey, Manuel, ``` is dangerous, why don't use other syntax like ...  ?
> or
> "Manuel,  why don't use this for heredoc ?
>
> In one word: Synergy.
>
> Why should this be done?. Because someone can read my purpose and can modify
> to something better, maybe a great change to the language.
>
> I think so.
>
> Regards,
> Manuel Canga
>
> --
> 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

Re: [PHP-DEV] [RFC] Alternative syntax for Nowdoc.

[Hamza Ahmad]

Hi Manuel,

If I am not wrong, is not your proposal similar to python's
triple-quoted? It is confusing; don't do this. Instead, current syntax
are sufficient. Second, (`) have special meaning in PHP. It is used to
execute commands on a machine. Why do we have confusing syntax?

Best

Hamza Ahmad


On 6/30/21, Manuel Canga  wrote:
>   En mié, 30 jun 2021 11:03:32 +0200 Guilliam Xavier
>  escribió 
>  > Hi,
>
> Hi Guilliam
>
>  > Maybe other syntax could be used, but I don't know which. In javascript
>  > > only a backtick is used:
>  > > https://developers.google.com/web/updates/2015/01/ES6-Template-Strings
> .
>  > > But in PHP this is used as eval.
>  > >
>  >
>  > Just a precision, because you keep referring to it as "eval", which
> makes
>  > me "tick" (haha): `$cmd` (i.e. $cmd wrapped in a pair of backticks) is
> the
>  > same as shell_exec($cmd), not eval($cmd).
>
> Yes, you're right.
>
>  > (BTW, one of JS "template strings" main selling points is string
>  > substitution / variable interpolation, which is explicitly *not* wanted
>  > with nowdoc [VS heredoc].)
>
> Yes, I mean that in JS is used some similar (although as you say with
> variables).
> I would prefer to use this "feature" with nowdoc. Normally, strings with
> variables are moved to views, while large literals (like queries) are added
> inline.
>
>  > As for the proposal, overall I agree with Rowan -- well, that would not
> be
>  > exactly like single quotes (regarding [not] escaping them), but still
> "yet
>  > another way" to write a nowdoc string literal.
>
> I see this purpose as a simplification of Nowdocs. Just like `[]` with
> `array()`.
>
>  > PS: "amusingly", the code samples are hard to understand after rendered
> on
>  > https://externals.io/message/115213
>
> ups!, I'm sorry...but, look at:
> https://externals.io/message/115213#115222
> Markdown is not broken here due to ``` of code.
>
> Regards,
> Manuel Canga
>
> --
> 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] Requesting RFC Karma

[Hamza Ahmad]

HI Internals,

After having a hot discussion on my STR_left-right functions' thread, I want
to bring an RFC. After reaching on a better proposal and a better agreement,
I will head for the voting process. I request for granting me an RFC karma.
My username would be hamza.

PS: when I attempted to register on the wiki, I received this message "That
wasn't the answer we were expecting". Please also tell me what it was and
the way how I can resolve this.

Best Regards

Hamza ahmad

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

> #justsaying

Mike, most of the developers in PHP have their background from web
development, and they need easier solutions to their problems. As for
your suggestion of including all suggested names in the RFC, I shall
do this, too!

Like others, I do have a dream for PHP that it may become an advanced
language. Still, I feel like that we count everyone that uses this
language. Well, I am going for an RFC.

Best.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

To George

> substring of the original string. And by that logic left and right are
> actually linguistically incorrect due to languages being read Right to Left
> or Top to Bottom.

Thanks George for pointing out an important aspect regarding the
choice of names. Will you consider a vote if there is a better name? I
do admire your idea of respecting other languages. In 21st centuary,
people are considering these facts. Recent developments, such as
GitHub’s decision to rename master to main, is a famous example of
these. Even Coq developers want to rename it just because itwas
supposedly associated with mail anatomy . Refference:
https://developer-tech.com/news/2021/jun/15/programming-language-coq-change-name-obvious-reasons/

> only a very restricted number of programming
> languages, which are some of the earliest languages ever, implement those
> functions should tell you something about programming language design
> as a whole,

Another member on the list, namely Mike, has added to the discussion
and I second his opinion.

> Yes this requires an RFC, just by this thread alone you should realize
> this is controversial, and I'll personally vote against it because there is
> no advantage to have this in core at all.

Sure, I would love to come up with an RFC. This thread has provided me
with enough content to build my argument. I am thankful to you for
razing many great points, such as descriptive naming. As for voting
rights, it is yours, sir,, and no one is stealing this from you.
Though you are against this proposal, what if you reconsider and
revisit your idea? Just because Sara and You and also my friends at
php.earth are against it, it does not mean that people are not
supporting it. I am following it on externals, some people down-voted
this thread and some up-voted it. Currently, it is in positive number.
I have referred to it just because people do follow our discussions
and have mixed opinions regarding this.

Best

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

> I can also imagine bikeshed...

This is what can be discussed apart from whether these function come
to PHP. I am waiting for the other voices; there is surely someone
that can come up with a more creative name, a name that is short yet
descriptive.

> str_left_part/str_right_part is just what came to mind,

I thank you, Andreas, for suggesting new names. You are right that
substr can give surprising results. Str_starts_with and ends_with
return bool, not strings. So, we do have need of these functions.

Best

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

HI Kamil,

Thanks for the opinions. I have two questions:
1. Though it's true that naming choice is something to discuss about,
is it really a big issue that can prevent from these functions to be
introduced? We can ask both developers and user community about the
name choice.
2. Since my basic goal is to have the functionality rather names, I
would love to see more descriptive and concise names. What name do you
suggest instead of these two?

Because left and right are used in both MySQL and VB, a large number
of people is already familiar with these names. However, I don't
prefer this scheme because it can go against PHP's naming schemes. I
know some of the string functions don't follow str_* and s* naming
scheme. We can let democracy decide the right name. If PHP later has a
string object, dev(s) can make left and right as its methods
respectively.

Best
Hamza Ahmad


On 6/24/21, Kamil Tekiela  wrote:
> I am against adding these functions, but for different reasons than Sara
> and George.
> If we add str_left and str_right then there should be a corresponding
> variant in mbstring. The byte-string functions are rarely useful. Adding
> these functions to mbstring unnecessarily complicates the extension for
> little to no gain.
> Another point is that if we decide to add them, then we will bikeshed
> forever in an unresolvable manner about the name. Should it be called
> str_left or strleft? Current functions don't have a naming convention, so
> using either variant will be wrong.
> Personally, I find substr to be more clear about the intent. I know that I
> am asking for a part of the string. Whereas str_left doesn't convey an
> action immediately. Without knowing its purpose I wouldn't know if it will
> pad the string from the left, strip characters from left, or take the
> leftmost part of the string.
> Don't take it the wrong way, but I think it's a waste of time to implement
> a function that doesn't even need a polyfill in the userland.
>
> Regards,
> Kamil
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

To George, et al,

HI George,

> I really don't see the point of these functions.

These functions provide a clearer semantics for their usage. Substr,
as Sara has mentioned, can be an alternative to these functions. Does
it make clear that substr returns the either ends of a string? No,
substr returns a part of a string, not ends. Although both mean
similar, and substr can be used in absence of these functions, saying
so is not linguisticly true!

If these functions are added, one can make sense of what these
functions actually do, without involving extra thought process.
Furthermore, it will help code readers decode their purpose at the
cognitive level, and that will provide with a faster understanding of
the code. Therefore, Microsoft is using AI to design a clearer
language to aid human minds understand quickly. I don't know how your
mind functions, but allow me to explain my thought process. When I see
substr, my mind says it is going to be a part of string from x offset
to y offset. Then, I look at the offsets, I learn that it is either
going to be a left end or a right end. If these functions are added to
PHP, programmers will have a clear idea of what is going on there
using a single thought. You are free to accuse me of mixing both
psychology and computer science.

HI Sara,

> you didn't explain what they're meant to actually do.

I thank you for pointing this out and also providing with the userland
examples of these functions. As for the second function, I myself some
time ago learnt that negative indexes are supported in substr. When I
wrote this function for the first time, I used some other technique.
As I have explained above that these functions are too common and
useful, I don't find any big issue if these functions are added to
core. IN VB, both mid and left/right functions exist.

Hi Guilliam,

> I think that's more about "semantics" ("conveying intent to readers") than 
> typing...

True, this is the main objective and motivation. Please, see the
second paragraph that I dedicated to George.

Hello Mike,

> str_right() would provide an obvious solution that would be easy to find in 
> IDE autocomplete or...

I thank you for adding to the discussion. When I first time felt the
need of str_right, I wrote this in a following way.
```
function right($str, $num) {
return substr($str, strlen($str) - $num);
};
``
Your opinion has strengthened my argument in three respects. First,
these functions are often searched for and wanted in the community.
Second, these functions will make the semantics clear. Third, these
functions are too clear in their signatures and purpose, and one would
hardly need to modify them. Nor, we need to add extra parameters and
introduce new behaviors, like JSON indentation RFC. As for multibyte
string functions, this is another domain. IF one wants to add mb_
these functions, it can also think of.

Hi Christoph,

> substr()  is about bytes, not characters.

Yes. Because PHP has MB string functions separately, implementation of
these functions will be once for all. There will hardly be a need of
touching these functions again.

Hi Rowan,

I thank you for providing with an other opinion. Here, I am only
talking about the basic string functions. As for the MB functions, I
am sure if these functions are added to core, they will also acquire
their place in mb_* functions list.

Because the time is approaching, what do you all suggest whether this
request requires an RFC?

I thank you all for providing me with your opinions. I wish this
thread leads a positive consensus.

Best
Hamza Ahmad


On 6/24/21, Sara Golemon  wrote:
> On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel  wrote:
>
>> I have frequently heard the justification of maintenance burden mentioned
>> as an objection to adding specific features.  And in many cases, it is
>> easy
>> to see why future maintenance burden would be a concern.
>>
>> However, it *seems* in this case that these functions are so trivial to
>> implement that once written and documented they would likely never need
>> to
>> be touched again. But as I do not yet know the internals of PHP I
>> obviously
>> do not know that to be a fact.
>>
>> Honest question: Would you mind explaining the type of maintenance
>> required for simple functions like this?  What is likely to change in the
>> future that would require maintenance?  And would you mind giving a few
>> or
>> at least one example of a trivial function that did need to be maintained
>> after it was written?
>>
>>
> Honest answer. I won't personally feel any pain from adding these
> functions. No more than I felt when str_contains() was added over my
> objections.  Nobody maintaining PHP will feel significant burden from
> them.  They'll sit in ext/standard/string.c doing their trivial work,
> opaque to the jit, an

[PHP-DEV] Introduce str_left/right In 8.1

[Hamza Ahmad]

Hello Internals,

Since feature freeze for 8.1 is approaching, I want to request two useful
string functions that exist in various languages-especially those that run
on web servers and used in databases. These are respectively `left();` and
`right();`

Whether it is VBScript or MySQL, these two functions are available there.
When I learnt PHP more than half a decade ago, I wondered why PHP had no
functions that provide the same functionality as these two languages
provide.

Although both of these functions can be created in the userland, I request
to build them in core for the following reasons:
1. They are standard functions in various languages. This article
<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(string_f
unctions)#left>, available on Wikipedia, compares various languages in
regard to string functions and recognizes left and right functions as a
general term to make sense of the attitude of these functions.
2. To achieve the effect of these functions, one needs to use `substr();`.
If these functions are introduced, it will be clear on the readers' level
the actual purpose of the use of that string function.
3. There may be libraries that provide with the similar functionality; why
not add this popular function to the core and make it available for everyone
to use? IT will not require people to include such heavy libraries to their
projects for such little and useful functions.
4. In the recent versions, PHP did include "str_contains", "str_ends_with",
"str_starts_with", "array_key_first", and "array_key_last" functions. All of
these functions are buildable in the userland, yet they have managed to make
place to the core because of their popularity. Why not these two functions?

If one has issues with the name choice, this is something that can be
discussed.

This request also takes inspiration from Kim Hallberg's proposal for
`clamp();` function. His email encouraged me to put my word on the table.

I am positive that senior developers would provide me with the feedback on
my suggestion. I am also positive that my request will be added to 8.1. I
thank you all for reading through my message and dropping a word.

Best Regards

Hamza Ahmad

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [PROPOSAL] Bare name array literals (again)

[Hamza Ahmad]

Hi Tyson,

Regardless of what others are saying, I personally like your RFC. The
reasons are following:
1. Because named keys are valid PHP names, they are resolved at the
parsing level. Thus, they will not be validated again and again.
Later, no constants are looked for.
2. At the runtime level, no variable location is done.
3. Since all keys are to be passed as PHP names, both single quoted
and double quoted strings are not dealt with. Similarly, concatenation
operations are not also performed.
4. Because all named keys are strings by default, type checking is not enforced.
5. `key=>value` costs 2 characters without spaces. If a keyboard user,
like me, wants to make its code easier to navigate, it adds two spaces
to either sides of `=>` operator. Then, single quoted and double
quoted strings have two extra characters, too! Quotes + spaces +
assignment =:
2 + 2 + 2 = 6. If your suggested feature is added, 6 will be reduced
to two — a colon follows a name, and a space follows the colon. Yay,
we have formulated a solution that simplifies keyboard navigation.

Yes, the idea of making anonymous classes/objects easier seams also
compelling. Since this is a discussion, I propose to use braces `{}`
instead of brackets `[]` and follow the pattern that Tyson is
suggesting. I know that it is similar to JavaScript, but it will be
different in one regard that it disallows the use of strings
(regardless of whether they are literals).

Because it requires extra effort to perform array-related operations
on objects, I prefer these two syntaxes:
1. `array(a: 1, b: 2, c: 3);`
2. `[a: 1, b: 2, c: 3];`

Best Regard
Hamza Ahmad


On 6/22/21, tyson andre  wrote:
> Hi Mel Dafert,
>
>> >I would prefer an improved syntax for creation of anonymous objects. This
>> >is something which I have been annoyed with, myself.I'd like to see a
>> >simple way of creating anonymous objects with typed properties.
>>
>> Another advantage arrays currently have over anonymous objects is
>> destructuring -
>> if this was (somehow?) also made possible with objects, this would be the
>> best of both worlds.
>> (Returning multiple named values from a function is also mentioned in the
>> use-cases of the RFC.)
>> I know this works:
>>
>> ```
>> [ "foo" => $foo, "baz" => $baz ] = (array) $object;
>> ```
>>
>> (Alternatively also using get_object_vars() instead of casting.)
>> But we both have to convert to an intermediate array again, and lose the
>> type information of the object (eg. for static analysis), so this could
>> also be
>> made more ergonomic if we want to go down the anonymous object route.
>
> Ideas for syntax:
>
> There's `object(foo: $foo, 'hyphenated-key' => $key) = $object;`,
> but that would require making `object` a reserved keyword, and it currently
> isn't one.
>
> - I had suggested using `$x = object(foo: $foo);` as a shorthand for `$x =
> (object)['foo' => $foo];`
>   at some point. Feedback was negative for largely unrelated reasons
> (stdClass in general). https://externals.io/message/112082
>
> `object{foo: $foo}` seems similarly unambiguous by requiring at least one
> property but would also require a new reserved word
>
> Or `({ foo: $foo }) = $object;` - On second thought, I'm against that - that
> is very likely to conflict with possible future proposals to parse block
> expressions.
> (e.g. getting parsed as a label for a goto followed by returning the
> variable $foo.)
>
> `list{ foo: $foo } = $object` is unambiguous, I guess
>
> `(object)['foo' => $foo] = $object;` was another idea but that wouldn't even
> work.
> It's already valid syntax that is parsed as casting an assignment to an
> object.
>
> `->{'foo' => $foo} = $object;` may be parseable but doesn't make much sense.
>
> Thanks,
> Tyson
>
> --
> 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

Re: [PHP-DEV] [Vote] Partial Function Application

[Hamza Ahmad]

HI Larry Garfield,

Do you have a plan to further extend this rfc? I mean, what if one
could typecast place holders? Broadly speaking, what if one could
perform some operations, such as arithmetic, bitwise, and type cast as
said above?

`$foo = bar((type) ?);`
`$foo = bar(? & 0xFF);`

Best
Hamza Ahmad

On 6/19/21, Patrick ALLAERT  wrote:
> Le sam. 19 juin 2021 à 01:41, Benjamin Eberlei  a
> écrit :
>
>> On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield 
>> wrote:
>>
>> > Hi folks.  The vote for the Partial Function Application RFC is now
>> > open,
>> > and will run until 30 June.
>> >
>> > https://wiki.php.net/rfc/partial_function_application
>> >
>> > Of particular note, a few people had asked about using ...? instead of
>> ...
>> > for the variadic placeholder.  In the end we decided not to explore
>> > that,
>> > as Nikita explained off-list it was actually more confusing, not less,
>> > as
>> > it would suggest "placeholder for a variadic" rather than "a
>> > placeholder
>> > that is variadic."  Otherwise, it's just more typing.  The syntax
>> > choices
>> > section of the RFC has been updated accordingly.
>> >
>>
>> I wanted to explain my no vote on this one.
>>
>> The examples section shows how every use-case of partials can be done
>> using
>> short functions and while this is often a lot more to type (especially if
>> you mirror the typehints), these extra symbols feel necessary from my POV
>> to make the code clear that creates a partial.
>>
>> Especially the ... as "additional" arguments and its various interactions
>> with ? produce so many different ways of calling something, it feels
>> unnecessary to me to introduce this complexity to newbies that might come
>> across use of this functionality. Plus the additional edge cases of
>> delayed
>> execution, non-support for named parameters. Its a lot to know to fully
>> understand this feature.
>>
>> Given that the functional paradigm isn't widely spread in use across PHP
>> developers, i am not convinced that we should add more features in this
>> direction that increase the complexity of understanding the language by
>> that much. While one could argue that functional paradigm isn't
>> wide-spread, because these features are missing, it is my believe that
>> the
>> majority of PHP developers would still rather prefer imperative coding.
>>
>> As a thought experiment I tried to think of code in our codebase that we
>> could convert to PFA once we migrated to 8.1 and there just isn't that
>> much. This is very different to short functions, nullabilty operator and
>> other "glue" / sugar proposals that were added to the language lately,
>> which a lot of existing code benefits from and existing code could be
>> converted automatically to them using phpcs/phpcbf rules.
>>
>> I also am wary of the future after this RFC, as it states it is the
>> launching pad to another attempt at the Pipe Operator, which also
>> proposes
>> to do a thing (calling functions) in a completly new way that will be
>> hard
>> for beginners. I hope we don't add both these features to keep the
>> language
>> smaller in this aspect of how functions are called.
>>
>
> I second Benjamin's opinion, hence my choice of voting "no" as well.
>
> Every new feature we add adds an extra layer of complexity in an
> exponential way, next new features/syntax have to deal with existing ones.
> The problem being solved with PFA, including how frequent it could be
> useful in PHP's ecosystem, does not, IMHO, counterbalance with the
> increased code complexity.
>
> -Patrick
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Hamza Ahmad]

> should array object be passed by value or by reference?
> If we are to have array object, will it be exceptional?

By value. Because array is a data type, we are talking about making it
behave like object. In JavaScript, Arrays, Strings, and Numbers are
objects; they have their respective properties and methods. Still,
when they are passed to a function or a method call, they are passed
by value, not by reference.

We should pass arrays by value because it will let a function or a
method modify it without changing the original array. If we make it a
regular object, it will be a bc break. So, whenever a callable
modifies an array, it will modify a variable out of its scope.

I am talking about attaching some methods and properties to array (or
largely, the string, int and float) type. In your manner, an
exceptional array object that is passed by value, Which will have
"key_first", "key_last", "keys", "values", "length", "type" (if PHP
later introduces typed arrays), and "is_list" as properties, and
"reverse", "flip", "map", "filter", "walk" and so on as methods. Such
methods will be performed on a value, not a variable. In other words:
`[1,2,3,4,5,6,7,8,9,0]->print();` will work. This way, it does not
matter whether one modifies a variable or a value.

According to the implementation of Nikita's extension, there will be
functions attached to each method of a type. To remove this
limitation, what if array is an internal array object?

To make my previous statement regarding making array_* functions as
method aliases for array->* methods, I give the example of mysqli. It
has both ways of interaction, object-oriented and procedural. So, why
not this with arrays?

Regards

On 5/26/21, Mike Schinkel  wrote:
>
>
>> On May 25, 2021, at 6:28 PM, Iván Arias  wrote:
>>
>> Hi all,
>>
>> It sounds like scalar objects by Nikita:
>> https://github.com/nikic/scalar_objects
>
> Yes, but Nikita wrote this note about technical limitations at the bottom of
> the repo README:
>
> Due to technical limitations, it is not possible to create mutable APIs for
> primitive types. Modifying $self within the methods is not possible (or
> rather, will have no effect, as you'd just be changing a copy).
>
> Does that mean that the scope of Nikita's proof-of-concept could not modify
> $self, or that it is simply not possible to modify $self given limitations
> inherent in PHP?
>
> Further, does that only apply to scalars, or might possible arrays could be
> different?
>
> -Mike

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] A little syntactic sugar on array_* function calls?

[Hamza Ahmad]

Hello,
I read about this extension times ago but didn't know whether it had
been public. If Nikita is reading this, I request him to think of
proposing a modified version of this extension bundled with PHP.
In simple words, he can hide the function that registers a class that
serves as a prototype of a built-in type. And, also provide with
scalar methods for string, int, float and arrays. To get handler
registering functionality added to core, there should be a separate
RFC.
While I read this thread for the first time, I had following suggestions:
1. All array functions should be moved to its scaler object, and the
word "array_" should also be removed.
2. To maintain backward compatibility, all array_* functions will
become method aliases of scaler array.
3. ArrayObject will also exist for the compatibility purpose, and its
methods will also be added to the scaler array.
Thus, array() or [] will return scaler array object, and following
syntax would become valid:
`[1,2,3,4,5,6,7,8,9] -> reverse();`
`array(1 => 'a', 2 => 'b') -> flip();`
If it happens, users will automatically be stopped from passing
non-array values to array functions, and the error will be caught
earlier.
Regards

On 5/26/21, Iván Arias  wrote:
> Hi all,
>
> It sounds like scalar objects by Nikita:
> https://github.com/nikic/scalar_objects
>
> Regards,
> Iván Arias.
>
> Get Outlook for Android
>
> 
> From: Hendra Gunawan 
> Sent: Tuesday, May 25, 2021 10:58:46 PM
> To: someniatko 
> Cc: Karoly Negyesi ; Marco Pivetta ;
> Lynn ; internals@lists.php.net 
> Subject: Re: [PHP-DEV] A little syntactic sugar on array_* function calls?
>
> Hello.
>
>>
>> ```php
>> $array|>map($fn1, ?)|>filter(?, $fn2);
>> $array->map($fn1)->filter($fn2);
>> ```
>>
>
> Whitespace removal is not a solution for code length problems.
> You might have a new problem if you do it. "|" is very similar
> to the lowercase "L" and uppercase "i".
>
> It's just an extra 3 characters (", ?" or "?, "). For most people,
> this is not a problem at all. people tend to write "one statement per line"
> rather than "multi statement line". I myself usually write no more than
> 3 statements per line if they are less than 120 characters.
>
> The real problem is there is no consistency for "haystack vs needle"
> position. There are RFCs to fix this (along with the naming convention
> problem), but none of them are successful.
>
>> The pipe operator feels like a poor solution while "->" would do
>> exactly what people want.
>
> Not so poor if we
> * use "~>" as pipe operator rather than "|>"
> * redesign the api under their proper namespace and strictly place
>   the "haystack" as the first function argument.
>
> Regards,
> Hendra Gunawan.
>
> --
> 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 am I unable to use 'readline_on_new_line()' on my windows machine?

[Hamza Ahmad]

Hello Internals,
I am unable to call readline_on_new_line() function.
I am posting this to internals to confirm whether it is a bug or an issue
with docs.
The manual suggests that this function is available on php 8.
https://php.net/manual/en/function.readline-on-new-line.php
However, when I invoke this in my script, it informs of calling an unknown
function. Other readline functions, such as readline(),
readline_read_history(), readline_write_history(), do work.
I wrote to shell `var_dump(function_exists('readline_on_new_line'));`. It
responded with `bool(false)`. I wrote,
`var_dump(extension_loaded('readline'))`. It said, `bool(true)`.
Note: my PHP version (PHP_VERSION) is 8.0.5.
Any type of help will be appreciated.
Kind regards
Hamza Ahmad

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Empower Callables with Function Signature Hints

[Hamza Ahmad]

Hello,
I thanks Saif for adding to my argument and providing with the list of
other languages/tools that support such a functionality.
As Saif has mentioned about "typesafe callables" RFC that is now
inactive, I want to also point out toward another rfc that was
declined.
It was Callable Prototype RFC that had sought for the similar
functionality. https://wiki.php.net/rfc/callable-types
Python also provides with a library ever since 3.5:
https://docs.python.org/3/library/typing.html
After looking at the prior RFCs, I feel like that it requires a fresh
discussion. Because there are several syntax to choose from, a
separate vote will only be held for this.
Best
Hamza Ahmad

On 4/7/21, Saif Eddin Gmati  wrote:
> Hello Hamza,
>
> I think this is something that has been discussed here before.
>
> function types already exist in HackLang:
> https://docs.hhvm.com/hack/functions/introduction#function-types,
>
> And, if we would follow the same syntax `(function(T, T): T)` or
> `(callable(T, T): T)`, PHP needs to first support parentheses in
> type declaration ( grouping ), which currently it doesn't ( i.e: `function
> baz((string|bar) $foo): void {}` becomes valid ).
>
> And just to note, function types are also supported by static analysis tools
> such as Psalm (
> https://psalm.dev/docs/annotating_code/type_syntax/callable_types/ ) and
> PHPStan ( https://phpstan.org/writing-php-code/phpdoc-types#callables ), so
> i suppose if PHP is to support typed callables, it should take inspiration
> from these tools.
>
> There's also an alternative syntax that was proposed back in 2016 for PHP
> 7.1, but it seems like the RFC was abandoned:
> https://wiki.php.net/rfc/typesafe-callable
>
> Cheers,
>
> Saif.
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, April 7, 2021 11:58 AM, Hamza Ahmad
>  wrote:
>
>> Hello Internals,
>> I want to request making possible to catch functions with wrong signature
>> when passed as callable. In other words, when a function or a method is
>> passed as callable value, PHP will first confirm whether the function is
>> of
>> the write callable type that the function being executed requires. It
>> will
>> help catch silent errors.
>> Currently, PHP does following:
>>
>
>> 1.  Confirms whether a callable is valid.
>> 2.  Passes the callable value to a function, and the execution starts.
>> 3.  If the passed function receives values which's type is different than
>> function signature, PHP throws an error.
>>
>
>> 4.  If passed function returns nothing, the variable that wanted a value
>> from
>> the passed function receives null.
>>
>
>> 5.  As a result, the unexpected results emerge.
>> To resolve this issue, I propose to introduce a mechanism that allows
>> to
>> hint callable signatures. To understand the spirit of this request,
>> look at
>> the similar functionality that Angel Script Project provides with.
>>
>
>> 6.  One defines a function definition.
>> 7.  Use its name to hint the same signature.
>> 8.  The compiler alerts about the incorrect signature before passing this
>> to
>> a function.
>> If I could do this in PHP, I would write like following:
>> `funcdef preg_replace_callback_hint(array $matches) : string;`
>> If I accidently pass a callable which's signature is different than
>> desired
>> function call, the error is caught earlier.
>> This message does not suggests syntax; it only points to a problem
>> and
>> suggests a solution. Any volunteers that would love to come up with
>> syntax
>> and implement this?
>> I am curious to see the feedback.
>> Regards
>> Hamza Ahmad
>>
>
>> --
>> 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] Empower Callables with Function Signature Hints

[Hamza Ahmad]

Hello Internals,
I want to request making possible to catch functions with wrong signature
when passed as callable. In other words, when a function or a method is
passed as callable value, PHP will first confirm whether the function is of
the write callable type that the function being executed requires. It will
help catch silent errors.
Currently, PHP does following:
1. Confirms whether a callable is valid.
2. Passes the callable value to a function, and the execution starts.
3. If the passed function receives values which's type is different than
function signature, PHP throws an error.
4. If passed function returns nothing, the variable that wanted a value from
the passed function receives null.
5. As a result, the unexpected results emerge.
To resolve this issue, I propose to introduce a mechanism that allows to
hint callable signatures. To understand the spirit of this request, look at
the similar functionality that Angel Script Project provides with.
1. One defines a function definition.
2. Use its name to hint the same signature.
3. The compiler alerts about the incorrect signature before passing this to
a function.
If I could do this in PHP, I would write like following:
`funcdef preg_replace_callback_hint(array $matches) : string;`
If I accidently pass a callable which's signature is different than desired
function call, the error is caught earlier.
This message does not suggests syntax; it only points to a problem and
suggests a solution. Any volunteers that would love to come up with syntax
and implement this?
I am curious to see the feedback.
Regards
Hamza Ahmad

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC: Add `println(string $data = ''): int`

[Hamza Ahmad]

Hi,
I have two questions regarding the RFC.
1. Why not provide an another optional attribute that allows to
specify the end of line eliminator?
2. Why don't you configure Unix end of line in INI file?

These additional steps will help users choose their favorite end of
line for their projects. The INI settings should be INI_ALL, so
libraries for various contexts can alter the attitude. For example,
those who learn PHP in web browsers can use . Those who use it on
shell will pick \r|\r\n|\n or simply \R. So, web server environments,
such as XAMPP, can set  end of line eliminator in the INI file
that they provide.

Example:


Besides, Let me give a strange circumstance that gives inappropriate
result if Unix end of line is used on old windows machine.

Observe the following lines written to shell.

php test.php>test.txt

The contents of test.php file:
 $char):
printf("$index=$char\n");
endforeach;
?>

Test.txt file will open in windows notepad. Here comes a bug that did
not display Unix end of lines properly in old 7 machines and 8.1
machines. It was fixed in the recent tweaks to Notepad. Will PHP
developers support only windows 10 and ignore the privious OSs?

I also suggest creating end of line constants as integer's, so nobody
could mistakenly write following:
println('Hae, this is my test message.', '');

As for naming constants, I suggest using the following scheme:
EOL_DEFAULT, EOL_PHP, EOL_CR, EOL_LF, EOL_CRLF, and EOL_HTML. Because
there appeared an RFC that requested to Rename T_PAAMAYIM_NEKUDOTAYIM
to T_DOUBLE_COLON. Why not fix this issue before it emerges?
Additionally, multiple constants can be provided, too. EOL_UNIX and
EOL_LF may have same value. The similar case applies to EOL_MAC and
EOL_WINDOWS.
Regards

On 3/14/21, Rowan Tommins  wrote:
> On 14/03/2021 15:52, tyson andre wrote:
>
>> There's also the alias fputs
>> ofhttps://www.php.net/manual/en/function.fwrite.php
>> which also returns the byte count.
>
>
> Notably, like printf(), that is borrowed directly from C, and probably
> dates from a time when most PHP programmers were also C programmers.
> That time is long past.
>
>
>> Annoyingly, any decision I make would be inconsistent with something
>
>
> I'm not sure why you're casting your net so wide. The name and use cases
> for this function put it squarely next to "print" and "echo" in my mind,
> and it would never occur to me to ask if it was consistent with most of
> the functions you've mentioned.
>
>
>> It definitely would be longer to use `println((string)$foo)`,
>> but there may be cases where that would be done,
>> e.g. if you are writing a script that would be reviewed/modified/used by
>> programmers that are more familiar with languages that aren't PHP.
>> (It'd be more readable using 1 output method than 3)
>
>
> Sorry, I'm not sure what you mean here. What 3 output methods are you
> talking about, and how does println((string)$foo) make a difference to
> them?
>
>
>> There's also `println("$foo");`
>
>
> Which is still marginally longer than the existing print "$foo\n";
>
>
>> Static analyzers for PHP such as Phan warn about the unused result of
>> multiplication
>> to catch cases like this, and other analyzers can easily add this check if
>> they don't already check for it.
>> https://github.com/phan/phan/wiki/Issue-Types-Caught-by-Phan#phannoopbinaryoperator
>
>
> That doesn't stop it being a nasty surprise. People will want to use
> "print" and "println" interchangeably, and making that difficult because
> they have different syntax is going to end up on lists of "things I hate
> about PHP", no matter how easily tools can spot it.
>
>
>>> if ( something() && println($foo) && somethingElse() )  // does what it
>>> looks like, if println is a normal function
>>> if ( something() && print($foo) && somethingElse() )  // does not print
>>> $foo, because the expression passed is actually ($foo)&()
>> The fact that `print` doesn't require parenthesis is something that
>> surprised me initially,
>
>
> Just to be clear, it is not that print doesn't *require* parentheses,
> it's that print does not have parentheses, ever.
>
>
>> though changing it to force it to use function syntax would be a much
>> larger bc break
>> more suitable for a major version, that I don't expect to pass.
>
>
> It hadn't even occurred to me to suggest that. I was suggesting the
> opposite: if we add something called "println", it should have identical
> syntax and behaviour to "print". The only difference should be the extra
> newline character in the output.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> 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

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Thank you for providing me with the feedback, experts! Initially, I wanted 
empty returns in void functions. When I prepared the request, I included the 
other solutions that I felt important and worth adding. Is it not possible to 
go with empty returns in void functions? I agree that the code can be adjusted 
to fit the current environment; still, people avoid writing lengthy blocks of 
code. An empty return with defaults will help them with the code that is easier 
to maintain.
I clarified my stance on first email in a response to a respectable member of 
the list. I do not know why that email is not appearing on externals. I will 
make sure that next time I post an external URL that contains the changelog and 
do not clutter the mailing list.
I am again thankful to you all!
Best
Hamza Ahmad

-Original Message-
From: Mike Schinkel  
Sent: Thursday, March 11, 2021 10:05 PM
To: office.hamzaah...@gmail.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

> On Mar 10, 2021, at 10:37 PM, office.hamzaah...@gmail.com wrote:
> 
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also 
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has 
> created another problem for those that use 'return' to end the 
> execution of a function or method call.

Welcome.

> There are mainly two usages of 'return'. First ends the execution of 
> the remaining statements. Second returns a value. The return type 
> hints aids with the second usage and ignores the former facility. In 
> other words, if one wants to avoid large code blocks i.e. the 
> conditional blocks, it can write like following.
> 
>  function foo()
> {
>   If (true /*condition1*/)
>   return;
> 
>   if (!false /*condition2*/)
>   return;
> 
>   /*the remaining part of a function*/
> };
> ?>

However, I agree with Larry.  This feels either like a code smell and/or could 
be handled with a variable.

This pattern can be very frustrating in other people's code when I either need 
to debug it or might want to debug it to learn the code because it requires 
setting IDE breakpoints in many places to be sure that catch an exit. And 
invariably I miss breakpointing a return when debugging and am left wondering 
what happened.  See https://youtrack.jetbrains.com/issue/WI-40862

As an alternate I developed a technique using `do{...} while(...)` in a novel 
way that I wish PHP supported more cleanly, but it nonetheless works great. 

The technique uses `do {...} while(false)` to create a block that break can 
exit early on guard clauses, for example (btw, I would return `null` instead of 
`'unknown'` and enclose the breaks in braces for the `if(...)` statement, but I 
wanted my example to be equivalent to yours):

 The above function returns null if conditions are met. Otherwise, it 
> returns no value. It was okay when there was no concept of return type 
> hints. When return types have been introduced, the behaviour needs to be 
> evolved, too.
> What if the return type was set 'int|float' in the above example? The 
> compiler would give following error:
> Fatal error: A function with return type must return a value 
> Similarly, a function with ': void' signature produceed that a 
> function may not return a value.
> To resolve such a problem, I request to honour the function signature 
> when you evaluate return statements. Instead of looking for no 'return'
> statements in ': void' functions, verify whether a function specifies 
> a return value. If the function returns a type other than the types 
> declared in the signature, it may produce wrong type error. If a 
> function with void returns a value i.e. contains a non-empty return 
> (return;) statement, the compiler may throw an error stating that a 
> function with void signature must not return a value.
> Likewise, 'return' may return an empty array if the return type was 
> set to array; the similar case applies to string, int, float, object 
> etcetera. In the case of ': void' signature, 'return' only ends the 
> execution and returns no value.
> PHP also allows to specify only returning 'false' from a function 
> call. What if you extend this functionality and allow specifying 
> literals including null? If nulls are also allowed, the backword 
> behaviour could be impleamented. For example:
> public function foo() : string| null;
> 
> Consider the following example for literals.
>  function get_nationality_string(int $country_code) : string | "unknown"
> {
>   return;
> };
> ?>
> 
> I am positive that you will consider my request and provide me with 
> the feedback i

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Hi Victor,

It does not contradict because it does not cover two different aspects. First, 
return types specify the types of to be returned values. Second, this request 
proposes a shorthand technique to avoid writing a single line code multiple 
times. Third, it is similar to default argument values that are also typed.

Cheers!

 

From: Victor Bolshov  
Sent: Thursday, March 11, 2021 3:00 PM
To: Hamza Ahmad 
Cc: Rowan Tommins ; internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

 

IMO this feature would contradict with the Single Responsibility Principle. 
Type hints are for type hinting, not for value hinting. Cheers.

 

Sent from Mailspring 
<https://link.getmailspring.com/link/4d67851f-de69-45d9-9db1-54b16845e...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F=b2ZmaWNlLmhhbXphYWhtYWRAZ21haWwuY29t>
 , the best free email app for work

On Mar 11 2021, at 10:51 am, Hamza Ahmad  wrote:

Hi Rowan,

Thanks for the response. Luckily, you razed the question that I thought about 
after posting the first request.

My idea develops on respecting both return type hints and union types. The 
current implementation of empty return does not respect the function signature. 
As I have mentioned in the first message that empty return returns null 
regardless of the return type set, I propose that an empty return may return 
the defaults of types i.e. an empty string if the type is string, an empty 
array if the type is array, zero if the type is int etcetera. I have also noted 
that in a void typed function, an empty return may return nothing and just end 
the execution.

The current implementation of empty return is only favourable for mixed type. 
In other words, when the return type is mixed, an empty return may return null. 
Otherwise, it should respect the declared return type.

After the release of union types, there emerges a question regarding the 
selection of default return value. To solve this problem, the type on the very 
right side will be used.

Now, I come to your question, Rowan. As of today, only false and null literals 
are supported. If both assist in error handling, why does empty return always 
returns null?

I tested this code on shell.

var_dump($a=(function():string|false{return;})());

It produced:

Fatal error: A function with return type must return a value in php shell code 
on line 1.

Here comes the inconsistency. To resolve the problem, I suggest to respect the 
literals first. If literals are not found, respect the first type on the right 
side.

Moreover, only two standalone literals, false and null, will be supported. 
Otherwise, the literal should be one of the types specified. If multiple 
literals are specified, it will throw an error of multiple literals. The 
literal can be a simple literal, such as, "unknown" 0, and a constant 
expression, like self :: MSG_UNKNOWN. It will help maintain the multi-language 
scripts.

I hope I have been able to make my stance clear.

Best

Hamza Ahmad

 

-Original Message-

From: Rowan Tommins 

Sent: Thursday, March 11, 2021 1:45 PM

To: internals@lists.php.net

Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

 

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:

>function get_nationality_string(int $country_code) : string | "unknown"

>{

> return;

>};

 

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

 

My main concerns are with the syntax:

 

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.

- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

 

Perhaps the default return value would need to be specified separately from the 
return type somehow?

 

Regards,

Hi Hamza,

 

Welcome to the list, and thanks for sharing this idea.

 

--

Rowan Tommins

[IMSoP]

 

--

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

RE: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Hamza Ahmad]

Hi Rowan,
Thanks for the response. Luckily, you razed the question that I thought about 
after posting the first request.
My idea develops on respecting both return type hints and union types. The 
current implementation of empty return does not respect the function signature. 
As I have mentioned in the first message that empty return returns null 
regardless of the return type set, I propose that an empty return may return 
the defaults of types i.e. an empty string if the type is string, an empty 
array if the type is array, zero if the type is int etcetera. I have also noted 
that in a void typed function, an empty return may return nothing and just end 
the execution.
The current implementation of empty return is only favourable for mixed type. 
In other words, when the return type is mixed, an empty return may return null. 
Otherwise, it should respect the declared return type.
After the release of union types, there emerges a question regarding the 
selection of default return value. To solve this problem, the type on the very 
right side will be used.
Now, I come to your question, Rowan. As of today, only false and null literals 
are supported. If both assist in error handling, why does empty return always 
returns null?
I tested this code on shell.
var_dump($a=(function():string|false{return;})());
It produced:
Fatal error: A function with return type must return a value in php shell code 
on line 1.
Here comes the inconsistency. To resolve the problem, I suggest to respect the 
literals first. If literals are not found, respect the first type on the right 
side.
Moreover, only two standalone literals, false and null,  will be supported. 
Otherwise, the literal should be one of the types specified. If multiple 
literals are specified, it will throw an error of multiple literals. The 
literal can be a simple literal, such as, "unknown" 0, and a constant 
expression, like self :: MSG_UNKNOWN. It will help maintain the multi-language 
scripts.
I hope I have been able to make my stance clear.
Best
Hamza Ahmad

-Original Message-
From: Rowan Tommins  
Sent: Thursday, March 11, 2021 1:45 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement According 
to the Function Signature

On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
>function get_nationality_string(int $country_code) : string | "unknown"
>{
>   return;
>};

If I understand you correctly, your idea is that the "return;" here would be 
treated automatically as "return 'unknown';" I think that's an interesting 
idea, although I can't immediately think of a situation where I'd use it.

My main concerns are with the syntax:

- Firstly, specific literals aren't currently allowed in return types, and 
allowing them would have other implications. Three exception is "false", which 
is allowed because of its common use as an error code, including in many 
internal functions.
- Secondly, it could be ambiguous which is intended to be the default value, if 
the return type was something like int|"yes"|"no"

Perhaps the default return value would need to be specified separately from the 
return type somehow?

Regards,
Hi Hamza,

Welcome to the list, and thanks for sharing this idea.

--
Rowan Tommins
[IMSoP]

--
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