[PHP-DEV] Associated Arrays as function parameters

[Midori Koçak]

Dear Internals,

I would like to as you a question. I know that it is possible to use an
array to function parameters like: function(...array); But this method is
not working when the array is associative.

Would not be fine if an array like ['param1'=>'value', 'param2' => 'value']
would be used in a function like function(param1, param2) regardless of the
order?

I think it would make our lives is easier. I'd be also happy if you know if
there is more effective method to achieve the same result.

Thanks,
Midori

[PHP-DEV] Bad quality of turkish translation

[Midori Koçak]

hello,

due to the very bad quality and majority of missing chapters and of the
neglected turkish translation of php documentation, I would like to acquire
the admin management of the doc...@lists.php.net

Thanks,
Midori Kocak

[PHP-DEV] Here is a talk about the being a newbie in Internals

[Midori Koçak]

Hello,

My talk about proposing Null Coalescing Assignment operator in PHPConf 2019
in Istanbul was published. If you would like to share what is a newbie
experience to people who are interested inn internals you can share it. :)

https://www.youtube.com/watch?v=AdKya1HLDZQ=PLc15X3-Essu7Qc9lBGj-zZoYqhct8IESV=9

Thanks,
Midori

Re: [PHP-DEV] What about a magic __toArray() method?

[Midori Koçak]

Marco, I've read it and your argument is strong. I think my opinion
slightly moves towards Andreas, away from magic.

here is something I wrote some days ago:
https://github.com/midorikocak/arraytools/blob/master/src/ArrayConvertableTrait.php

I guess you were saying something like this would be enough.

Midori

On Tue, 4 Feb 2020 at 11:31, Marco Pivetta  wrote:

> Hey Midori,
>
> This has been discussed in more depth 2 years ago:
> https://externals.io/message/98539#98539
>
> In practice, the `(array)` cast is one of the few operations that don't
> cause observable side-effects in this programming language: let's please
> keep it as such.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Tue, Feb 4, 2020 at 8:15 AM Midori Koçak  wrote:
>
>> As you know we have __toString method that runs whenever an object is
>> typecasted to string or it is directly echoed.
>>
>> >
>> $class = (new class{
>>   public function __toString(){
>> echo "casted\n";
>> return "mahmut\n";
>>   }
>> });
>>
>> echo $class;
>> $casted = (string)$class;
>>
>> /*
>> prints:
>> casted
>> mahmut
>> casted
>> mahmut
>> */
>>
>>
>> As you know toArray() method implemented when an object is converted into
>> and array and most of the time when a plain data object is sent to
>> front-end.
>>
>> Having a magic method like __toString called __toArray would be useful to
>> detect and act on conversion events.
>>
>> Roughly it would be like:
>>
>> >
>> $class = (new class{
>>   public function __toArray(){
>> echo "casted\n";
>> return
>> [
>>   'key'=>'value'
>> ];
>>   }
>> });
>>
>>
>> $casted = (array)$class;
>> print_r($casted);
>>
>> /*
>> prints:
>> Array
>> (
>> [key] => value
>> )
>> mahmut
>> */
>>
>> What would you think? I think it would add value.
>>
>

[PHP-DEV] Re: What about a magic __toArray() method?

[Midori Koçak]

Oh there is even a rfc. https://wiki.php.net/rfc/to-array What is the
status of this?

On Tue, 4 Feb 2020 at 08:18, Midori Koçak  wrote:

> Or we can deprecate __toString() method at all and detect cast events
> instead. Would it make more sense? Something like this __casted().
>
> P.S: I saw the previous conversation but hence now we have types, it would
> make sense.
>
> Midori
>
> On Tue, 4 Feb 2020 at 08:15, Midori Koçak  wrote:
>
>> As you know we have __toString method that runs whenever an object is
>> typecasted to string or it is directly echoed.
>>
>> >
>> $class = (new class{
>>   public function __toString(){
>> echo "casted\n";
>> return "mahmut\n";
>>   }
>> });
>>
>> echo $class;
>> $casted = (string)$class;
>>
>> /*
>> prints:
>> casted
>> mahmut
>> casted
>> mahmut
>> */
>>
>>
>> As you know toArray() method implemented when an object is converted into
>> and array and most of the time when a plain data object is sent to
>> front-end.
>>
>> Having a magic method like __toString called __toArray would be useful to
>> detect and act on conversion events.
>>
>> Roughly it would be like:
>>
>> >
>> $class = (new class{
>>   public function __toArray(){
>> echo "casted\n";
>> return
>> [
>>   'key'=>'value'
>> ];
>>   }
>> });
>>
>>
>> $casted = (array)$class;
>> print_r($casted);
>>
>> /*
>> prints:
>> Array
>> (
>> [key] => value
>> )
>> mahmut
>> */
>>
>> What would you think? I think it would add value.
>>
>

[PHP-DEV] Re: What about a magic __toArray() method?

[Midori Koçak]

Or we can deprecate __toString() method at all and detect cast events
instead. Would it make more sense? Something like this __casted().

P.S: I saw the previous conversation but hence now we have types, it would
make sense.

Midori

On Tue, 4 Feb 2020 at 08:15, Midori Koçak  wrote:

> As you know we have __toString method that runs whenever an object is
> typecasted to string or it is directly echoed.
>
> 
> $class = (new class{
>   public function __toString(){
> echo "casted\n";
> return "mahmut\n";
>   }
> });
>
> echo $class;
> $casted = (string)$class;
>
> /*
> prints:
> casted
> mahmut
> casted
> mahmut
> */
>
>
> As you know toArray() method implemented when an object is converted into
> and array and most of the time when a plain data object is sent to
> front-end.
>
> Having a magic method like __toString called __toArray would be useful to
> detect and act on conversion events.
>
> Roughly it would be like:
>
> 
> $class = (new class{
>   public function __toArray(){
> echo "casted\n";
> return
> [
>   'key'=>'value'
> ];
>   }
> });
>
>
> $casted = (array)$class;
> print_r($casted);
>
> /*
> prints:
> Array
> (
> [key] => value
> )
> mahmut
> */
>
> What would you think? I think it would add value.
>

[PHP-DEV] What about a magic __toArray() method?

[Midori Koçak]

As you know we have __toString method that runs whenever an object is
typecasted to string or it is directly echoed.

'value'
];
  }
});


$casted = (array)$class;
print_r($casted);

/*
prints:
Array
(
[key] => value
)
mahmut
*/

What would you think? I think it would add value.

Re: [PHP-DEV] Typed array properties V2

[Midori Koçak]

Given this orientation, can we also have this debated once more?

https://wiki.php.net/rfc/callable-types

Right now, I am using 7.4.2 in production and in my next book and I cannot
explain how it feels good to have those types but along with the loosely
typed freedom. That's the killer advantage of PHP and IMHO version 8 will
be quite popular due to the 7.4;



On Sat, 25 Jan 2020 at 16:12, Rowan Tommins  wrote:

> On 25/01/2020 00:12, Mike Schinkel wrote:
>
> > So saying "use a static analyzer" is IMO just pointing out an overall
> > weakness that PHP can't automatically do static analysis on its own.
>
> I'd just like to repeat that you and Rasmus are in agreement here. He
> didn't say "PHP doesn't need to change because static analyzers exist",
> he said:
>
>  > it would be amazing to have a static analyzer built into PHP
>  > ... but that is a huge task and goes way beyond just this particular
> check.
>
> Choosing whether that analysis runs automatically during server startup,
> or as a separate command-line script, is just one detail among many. It
> probably wouldn't make much difference to the rest of the analysis code,
> and it might even make sense for it to support both modes. For instance,
> it might be optional for command-line scripts, so you could have options
> for "analyse and run", "run only", and "analyse only".
>
>
>  > One of the main strengths of PHP — and IMO one of the reasons for its
> incredibly marketshare — is the ease with which PHP code can be written,
> tested, and deployed.
>  > And that ease translated to ubiquity.
>  > Adding a recommended build step to that in order to gain correctness
> weakens that value proposition and threatens future ubiquity as other
> language improve.
>
> Yes, the convenience of having something run automatically is definitely
> worth considering, as long as it doesn't introduce new delays and rules
> that get in people's way.
>
> It partly depends what kind of checks were being done, I guess, and
> therefore how much time it would take to run, and how much of a project
> it would need to analyse at once.
>
> Regards,
>
> --
> Rowan Tommins (né Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] turkish documentation

[Midori Koçak]

Hello,

I would like to translate some of the 7.4 documentation into turkish. It
seems like wiki username and password does not work for documentation. I
could not find the list of language mail lists as well. (it says
doc-{LANG}@lists.php.net but where?)

Any ideas?

Thanks,
Midori

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

[Midori Koçak]

Wow.

A RFC that it's motivation is to prevent beginners from asking questions.

That's horrible.

 I rather prefer a CoC. What about this? https://confcodeofconduct.com/


On Thu, 19 Sep 2019 at 19:19, Dan Ackroyd  wrote:

> Hi internals,
>
> Here is an RFC to "Prevent disruptions of conversations"
> https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit
>
> A couple of notes:
>
> * although the RFC would only be applicable to messages sent once it
> might be approved, it would still be nice if people consider how their
> messages affect other people before then.
>
> * any inappropriate messages sent privately to me have a very high
> chance of being replied to on the internals list.
>
> * everyone should bear in mind this RFC might gain more attention from
> people outside the PHP internals community than normal.
>
> * I think this solution isn't going to be a great one, and that it
> would be better if we had a less controversial way to address
> non-productive behaviour. If someone wants to start a discussion on
> replacing this RFC that would be great, but as I said in the RFC in my
> opinion this is a needed short term solution.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] P++: FAQ

[Midori Koçak]

+1

On Sun, 11 Aug 2019, 07:32 Andi Gutmans,  wrote:

> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion. It’s strange given
> how much better it actually runs (really being unbiased here). One reason
> is security perception (which is BS but perception matters) and the second
> is arguably some of the historic baggage which makes some folks feel PHP is
> hard to master without a manual (we have the best manual).
>
> So many times I have thought “is it time to just take an axe and simplify
> it and do a cleanup?”. I actually don’t think we lack many features but
> rather lots of stuff I would dump like references, array(), global
> namespace for functions(?), type juggling in areas where we should be
> stricter, etc... I actually think that having a p++ is risky but it is an
> opportunity. I think it’s mostly be an opportunity if we’d be careful about
> feature bloat and try and be really aggressive about removing things and
> cleaning up. We potentially would get the significant benefits of our
> runtime but with a cleaner language. Will non-PHP appreciate it? maybe,
> maybe not... I actually do think there’s value of a different brand just
> because of the BS perception issues...
>
> Andi
>
> Get Outlook for iOS
>
> 
> From: Zeev Suraski 
> Sent: Friday, August 9, 2019 12:54 PM
> To: Internals
> Subject: [PHP-DEV] P++: FAQ
>
> During the discussion of the P++ proposal (
> https://externals.io/message/106453), it became painfully clear that this
> idea did little, so far, to bring peace to the galaxy.
>
> However, based on a lot of the feedback, both on internals@ and elsewhere
> -
> it seems that a lot of people simply didn't really understand what this
> idea was actually proposing to do. I'll take the blame for that - by not
> making the idea sufficiently clear.
>
> I went on and create an FAQ, that attempts to address many of the questions
> and common misconceptions that repeatedly came up.
>
> It's available here: https://wiki.php.net/pplusplus/faq
>
> Before you read it, I want to stress that this is an attempt to
> provide *everyone
> with a good deal, and nobody with a raw deal. *It doesn't mean it's
> successful at that (although I think it is) - but the motivation is clean
> and positive. If & when you read this FAQ, please try to read it without
> any preconceived notions.
>
> If there are additional questions that you think are missing, please let me
> know - or better yet, if you're up for constructively adding them - go
> ahead and do that.
>
> Thanks,
>
> Zeev
>

Re: [PHP-DEV] P++: FAQ

[Midori Koçak]

I do completely agree with this and would like to be part of it. I am
really frustrated to see old developers shrug every time I talk about php.
I am enthusiastic about our language, the language I started coding with
and the language that evolved in years while I was learning it.

2 years ago, while I was preparing for facebook whiteboard interview for 6
months (I was not hired, I don't know what was the reason is.) I was
shocked to see while learning built in array and string functions naming
and parameter order. While we are advocating using coding standards,
forcing people to use PHP-FIG with different versions and advices, our
language does not have the same consistency, I know that was a must for
backwards compatibility with C, but makes me feel bad about the things I am
advocating for years.

Also, it is almost impossible for a newcomer to get into the internals. I
know that PHP source code is robust, evolved in many years to a position
that powers almost all of the internet but adding a new feature (which I
attempted once) requires a great C skill and familiarity with codebase
because of not having comments or source code documentation other than
internals book. (I also cannot say my attempts were welcomed with
happiness, which resulted me to lose my motivation, thankfully NCAO was
implemented by nikita popov)

I would really would be happy to see P++ to be built with some modern
compiled language like Rust and have nice guidelines and techniques to add
new features including new programming concepts. P++ should be the real
programming language of the future, should welcome newcomers, be easy to
use without bureaucracy of Java, nor encouraging spaghetti like code in
Python. I think PHP's secret is this, highly versatile, similar to a swiss
army knife, while other languages rant about their modernity and
superiority, it allows us to survive in the middle of the winter in a
forest under the storms. Even it is slow sometimes nor it is not perfect,
it's like me, it learns, it evolves, not perfect but it's the most used
language of the internet at the end.

>From a humanitarian perspective, we have a huge potential here to create
most diverse, most inclusive, most welcoming language and programming
culture in the times that women and minorities leave the industry because
of the unneeded ego atmosphere.

>From a technical perspective, P++ can be the language of the future and
bring peace to the galaxy.

Cheers,
Midori




On Fri, 9 Aug 2019 at 22:54, Zeev Suraski  wrote:

> During the discussion of the P++ proposal (
> https://externals.io/message/106453), it became painfully clear that this
> idea did little, so far, to bring peace to the galaxy.
>
> However, based on a lot of the feedback, both on internals@ and elsewhere
> -
> it seems that a lot of people simply didn't really understand what this
> idea was actually proposing to do.  I'll take the blame for that - by not
> making the idea sufficiently clear.
>
> I went on and create an FAQ, that attempts to address many of the questions
> and common misconceptions that repeatedly came up.
>
> It's available here:  https://wiki.php.net/pplusplus/faq
>
> Before you read it, I want to stress that this is an attempt to
> provide *everyone
> with a good deal, and nobody with a raw deal.  *It doesn't mean it's
> successful at that (although I think it is) - but the motivation is clean
> and positive.  If & when you read this FAQ, please try to read it without
> any preconceived notions.
>
> If there are additional questions that you think are missing, please let me
> know - or better yet, if you're up for constructively adding them - go
> ahead and do that.
>
> Thanks,
>
> Zeev
>

Re: [PHP-DEV] New website for the PHP project

[Midori Koçak]

I can do some design, I designed the UI of CakePHP framework generators in 
2015. You can see the whole process here: 
https://github.com/cakephp/cakephp/issues/6679

We should not rely on any css, js or html framework in my opinion. But it's up 
to you.

For layout, CSS Grid and Flexbox is more than enough and would be future proof, 
but should be tested and polyfilled.

A lot of cross browser testing will be needed.

Cheers,
Midori

On 04/02/2019, 02:03, "Levi Morrison"  wrote:

On Sun, Feb 3, 2019 at 5:15 PM azjezz  wrote:
>
> Hello Internals !
>
> As @official_php suggested [1], I'm here to propose a new website for the 
PHP Project.
>
> In my opinion, current design looks old, outdated and bland. This sadly 
may reflect "badly" on the language
>
> reputation nowadays.
>
> New comers find it hard to go around the website, to write "comments", 
report issues or write RFCs.
>
> Even signing up for the internals mailing list wasn't an easy task [2].
>
> Since the development of PHP 8.0 has started, I think its a good idea to 
start working on a new website.
>
> # Global proposal
>
> The proposal here is to do a major rewrite of the PHP sites. This rewrite 
would includes php.net, windows.php.net,
>
> bug.php.net, wiki.php.net, qa.php.net and other official php websites.
>
> It would be done with this in mind:
>
> * No PHP framework (to avoid favoriting one)
>
> * Keep it simple: little to no changes to the database structures
>
> * This site should look modern, simple and feel welcoming.
>
> * A new home page, not a "news" page, but a page simply showing the PHP 
Logo, a code example maybe and
>
> the download link [3].
>
> * A new community website [4], it can be a place for people to ask 
questions and discuss php in general - no one uses IRC anymore.
>
> * Single account: Users should be able to use the same community account 
to file bugs, create a new RFC (depending on karma) and leave notes on the 
documentation.
>
> * Ideally all *.php.net websites would be "merged" into a single brand 
new website, but I'm not sure about the hosting
>
> specificities (eg, what server does what).
>
> # FrontEnd Framework
>
> We don't need that too, but we can use one ! there's some light-weight 
options out there.
>
> but i'm pretty sure some people in the php community have experience with 
front-end development and will happily contribute.
>
> see :
>
> - https://mustard-ui.com/
>
> - https://getuikit.com/
>
> - https://bulma.io/
>
> - https://picturepan2.github.io/spectre/index.html
>
> # Next steps
>
> I would really like to hear opinions about this proposal.
>
> [1] https://twitter.com/official_php/status/1091903415377108994
>
> [2] https://twitter.com/SaraMG/status/1092185205572542466
>
> [3] 
https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
>
> [4] https://php.net/community
>
> ---
>
> Saif Eddin Gmati 

I appreciate the enthusiasm. If you think the current PHP website is
old, out-dated, and bland, you must have not experienced the previous
one:

  
https://i2.wp.com/www.geekgumbo.com/wp-content/uploads/2012/01/phpsite45.png

In any case, I hope you realize this is an ambitious project. It will
take a very long time to build a cohesive UI, and then also a very
long time to update the bugs, windows, docs, wiki, etc, websites to
use it. If you are seriously committed to this, then the next step is
to create mock-ups for every type of page across PHP.net that you can
find, and to share them on the PHP Webmasters mailing list (which I've
cc'd). Then, we'll probably give you a few more pages that needs
mocks, after which you will then have to attempt to build the mock-ups
in a few different codebases.

I did the last redesign, and I took a less rigorous approach. If I
were to do it again, I would be much more rigorous in gathering
requirements and building mock-ups. There were a lot of pages which
needed re-worked because of my design, which took even more time.
While it's okay for some pages to be re-worked content-wise to fit the
new design, you want to minimize it.

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Midori Koçak]

Totally agree with this. The new and old can exist both. We should be open
to change.

On Thu, 31 Jan 2019, 11:53 Benjamin Morel  Please forgive my stubborness, too. I fail to see how WordPress supporting
> PHP versions that have been EOL for YEARS can be of any help to the
> community? These versions may have unpatched security holes, and
> encouraging users to keep using them is a disfavour to the community IMO,
> which can only delay adoption of newer versions, and lead to an even more
> painful upgrade path when you have to upgrade N versions at once. My stance
> on this is that projects written in PHP have to evolve together with the
> language, and I'm personally not surprised to have to rewrite a few things
> whenever a major PHP version is released (and I do maintain quite a number
> of projects). Let me rephrase this: actually, I would be HAPPY to rewrite
> my projects towards a more consistent PHP language.
>
> That being said, I know this opinion is a minority on this list, so let's
> put it aside for a moment.
>
> Now what prevents PHP from adding consistent function names / APIs, and
> deprecating the older ones? We can keep the old ones for 10 more years if
> you wish, but at least new PHP code can start using the "correct" ones, and
> progressively the share of PHP code out there using the old ones should
> progressively get lower over the years, up to the point where we could
> eventually decide that it's not worth keeping them. The thing is, if you
> never start, the situation will never improve.
>
> You know the proverb: The best time to plant a tree was 20 years ago. The
> second best time is now.
>
> Ben
>
> On Thu, 31 Jan 2019 at 11:30, Rowan Collins 
> wrote:
>
> > On Thu, 31 Jan 2019 at 07:34, Peter Kokot  wrote:
> >
> > > Sorry, I didn't put my words correctly here. Not inconsistency.
> > > Inconsistency is a fact, yes. I've meant the incapability of doing
> > > something to fix this inconsistency. And it is becoming some sort of
> > > stubborn belief and less and less people want to fix it.
> > >
> > > The RFC: Consistent function names [1] shows the magnitude of this. I
> > > don't think every function listed there needs a change so it can be
> > > greatly reduced. But still this can be done in several years to 10
> > > years or so (measuring over the thumb).
> > >
> >
> >
> > Hi,
> >
> > I'm sorry if I sound stubborn, but I have yet to see a reasonable answer
> to
> > the fundamental problem: the effort needed is not on the part of a few
> > volunteers changing the language, it is effort by *every single user of
> the
> > language*, rewriting *every single PHP program ever written*.
> >
> > WordPress officially supports both PHP 5.2, released 13 years ago, and
> PHP
> > 7.3, released a couple of months ago; one of their biggest challenges in
> > raising that bar is that they, too, have to persuade a community (the
> theme
> > and plugin authors) to change their code to match. That should give you
> > some idea of how long old and new names would have to exist side by side,
> > while we waited for everyone to rewrite all their code, and meanwhile,
> the
> > language would be *even more inconsistent*, because there would be extra
> > ways of writing the same thing.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
>

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Midori Koçak]

Can we also add strange function names without any naming conventions to
this list? Without undersore: strcspn, With underscore:  str_repeat, chain
of abrevs: strnatcasecmp. Similar namings do exist for array functions
either.

Cheers,
Midori

On Tue, 22 Jan 2019 at 22:22, Girgias  wrote:

> On Tue, 22 Jan 2019 at 21:48, Stephen Reay 
> wrote:
>
> >
> > > On 23 Jan 2019, at 03:34, Girgias  wrote:
> > > Classes/Objects functions:
> > >
> > >   - is_a (use instanceof operator)
> > >   - is_subclass_of (not exactly what it's purpose is but the instanceof
> > >   operator SHOULD be a valid equivalence with another condition if the
> > same
> > >   class must not be used)
> >
> > is_subclass_of allows checking string class names, instanceof (AFAIK)
> does
> > not.
> >
>
> Good catch, just checked and it's indead the case that instanceof can't
> check string class names:
> https://3v4l.org/DkMC4
>
> George P. Banyard
>

Re: [PHP-DEV] Re: Mailing list moderation

[Midori Koçak]

+1

This kind of language shouldn't be allowed here.

On 4 April 2018 at 20:42, Derick Rethans  wrote:

> Hi,
>
> "rhsoft" continues their aggressive behaviour on the bug tracker still
> too. One recent illustration is
> https://bugs.php.net/bug.php?id=76184=1
>
> Do we have any methods to ban people from there too?
>
> cheers,
> Derick
>
> On Wed, 3 Jan 2018, Rasmus Lerdorf wrote:
>
> > Ok, both have been added to the ezmlm deny list for internals
> >
> > On Tue, Jan 2, 2018 at 2:49 AM, Nikita Popov 
> wrote:
> >
> > > Hi,
> > >
> > > This mail is going to both the systems group and internals mailing
> list.
> > >
> > > I would like to request a mailing list suspension for the users
> > > tonymars...@hotmail.com and li...@rhsoft.net, who have recently been
> > > aggressively derailing the "Scalar Pseudo-type" thread, despite
> requests to
> > > moderate their participation both in that thread, and on a number of
> > > previous instances -- this is certainly not the first time these two
> users
> > > have converted an RFC discussion into a dick measuring contest.
> > >
> > > If these users cannot be suspended, I would like to request specific
> > > instructions under what circumstances users can be suspended from the
> > > internals list, and what procedures need to be followed to achieve
> this.
> > >
> > > Regards,
> > > Nikita
> > >
> >
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV][RFC][DISCUSSION] Deprecate the backtick operator

[Midori Koçak]

Sounded reasonable to me. At least for security.

On 11 February 2018 at 21:24, Stanislav Malyshev 
wrote:

> Hi!
>
> > It's absolutely impossible to treat notices as errors in PHP, so I
> > assume everybody thinks the same. If someone converts notices to
> > ErrorExceptions or something, it's their fault.
> > A notice in tests is exactly what a deprecation is supposed to do, force
> > people to update their code.
>
> If you force people to do something, by definition it is not "Backwards
> Incompatible Changes: None". If it were none, people would not be forced
> to do anything.
>
> > Regarding the notice level, it's a bit confusing picking one.
> > E_DEPRECATED, E_STRICT, E_NOTICE... I'm not sure what it should be.
>
> You should write all the details in the RFC. If you are not sure what to
> choose, write "I am not sure which one to choose here, options are X, Y
> and Z".
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] null coalesce addition assignment operator ??+=

[Midori Koçak]

What is going on here? I think I missed the original post.

On 19 January 2018 at 16:12, Sara Golemon  wrote:

> On Thu, Jan 18, 2018 at 7:13 PM, Christoph M. Becker 
> wrote:
> > On 18.01.2018 at 23:58, Stanislav Malyshev wrote:
> >
> >>> I propose even more such operators:
> >>> null coalesce addition assignment ??+= (for strings and numbers)
> >>> null coalesce subtraction assignment ??-=
> >>> null coalesce increment ??++
> >>> null coalesce decrement ??--
> >>> null coalesce multiplication assingment ??*=
> >>
> >> I think this is taking it too far. If you want language like that, you
> >> always have APL :)
> >
> > Why do we discuss extensions to an operator which has still (after
> > nearly two years) not be implemented due to implementation difficulties?
> >
> Am I the only one who looked at the original post and assumed he was
> taking the piss?
> Similar to the jokes about spaceship assignment <=>= and
> equality/identicality assignment === (not to be confused with
> identical non-assign, which is ===) and .
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Happy World Elephant Day

[Midori Koçak]

Hi Internals,

Happy world elephant day for all of internals community. Did you know there
are 400.000 elephants left all around the world and every year 40.000 of
them are dying  for the ivory trade.

Happy world elephant day again,
Midori Kocak

Re: [PHP-DEV] php.net website

[Midori Koçak]

I can help.

> On 19 Jul 2017, at 19:07, Mathias Grimm  wrote:
> 
> Hi,
> 
> I would like to know who is/are "in charge" of the website (
> https://github.com/php/web-php).
> I think I would like to help improving it a bit.
> 
> I can possibly understand the reasons why it is still like it is, code
> wise, but I think there is a lot of room from improvement. Also, from the
> reference point of view, I don't think it's a good example/image for the
> php community.
> 
> I would like to understand also a little bit about how it is
> hosted/deployed/build etc.
> 
> I was briefly asking Sara about it and as she pointed out it is likely a
> big project but I think we can do something about it.
> 
> Cheers,
> Mathias Grimm



smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] [7.2] Timetable

[Midori Koçak]

In my opinion, we can implement it for primitives and arrays, but it's a
bit more political problem than a technical one.

On 29 May 2017 at 19:24, Sara Golemon  wrote:

> On Mon, May 29, 2017 at 6:41 AM, Björn Larsson
>  wrote:
> > I wonder if the accompanying RFC will move forward?
> > - https://wiki.php.net/rfc/short_ternary_equal_operator
> >
> > Also a bit curious if you managed to fix the buggy implementation?
> >
> Well, those are really the same question.  If we can make the
> implementation work correctly, then it'll move forward.  At the
> moment, we can't guarantee that the vars stay live correcty, so it's
> looking like "not for 7.2, at least".
>
> -Sara
>

Re: [PHP-DEV] [7.2] Timetable

[Midori Koçak]

I suggest to implement ??= for primitive types. Please discuss.

Thanks.

> On 21 May 2017, at 02:08, Sara Golemon  wrote:
> 
> On Thu, Apr 20, 2017 at 11:43 AM, Sara Golemon  wrote:
>> My how time flies!  Feature Freeze for PHP-7.2 is coming up in exactly
>> THREE MONTHS on July 20th.  Get your RFCs discussed, voted on, and
>> implemented unless you want to wait for PHP-7.3
>> 
>> -Sara
>> 
>> Ref: https://wiki.php.net/todo/php72#timetable
>> 
> Snooze Alarm: PHP-7.2 feature freeze is now TWO MONTHS away.
> 
> -Sara
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



smime.p7s
Description: S/MIME cryptographic signature

[PHP-DEV] [RFC] Structured Object Notation

[Midori Koçak]

https://wiki.php.net/rfc/structured_object_notation

Object Oriented Programming is a key feature to write structured programs
in PHP. However, even though we have classes included in our program, the
only way to create an object from a class, is to instantiate it in
unstructured code. Consider this piece of code:

get('/hello/{name}', function (Request $request, Response $response) {
$name = $request->getAttribute('name');
$response->getBody()->write("Hello, $name");

return $response;
});
$app->run();
This causes loss of readability and benefits of oop in most of the
programs. Most of the programs we write, end up to have some piece of
spaghetti code somewhere. To prevent this, one should write a god object
and run once but classes are not and should not be code blocks wrapped
around “class” keyword. Here in this RFC, I propose a structured way to
instantiate objects in a PHP script in a structured way.

Proposal

According to most definitions an object is defined as: “Real-world objects
share two characteristics: They all have state and behavior.” Currently to
interact with an object, one should instantiate the object and send
messages manually within an unstructured code blocks.

According to PHP manual a class is defined like this:

foo();

A::foo();
$b = new B();
$b->bar();

B::bar();
?>
The part after class definitions is an unstructured program block where we
lose readability, reusability, mantainability and all the other benefits of
oop. Most of cli apps we use are showing what are avaliable commands and
subcommands recursively:

$ composer
...
Avaliable Commands:
about - ...
archive - ...
browse - ...

$ composer browse -h
Arguments:
packages - ...
Inspired by this, an object we create should also orient us where to go
after each command. I will explain this later.

Let's have one class called B, similar to above example.

class B{

// No way to define order of methods
public function __construct($world = "world"){
echo "Hello ". $world."\n";
echo "You can foo and you can bar\n";
}

public function foo($x, $y){
echo "\nYou did foo: x is ".$x." and y is ".$y."\n";
echo "Now you can bar\n";
}

public function bar($z, $t){
echo "\nYou did bar: z is ".$z." and t is ".$t."\n";
echo "You can bar again or end the program\n";
}

public function __destruct(){
echo "\nGood bye\n";
}
}

// Here comes the spaghetti
$app = new B("midori");
$app->foo(1,2);
$app->bar(3,4);
Instead of instantiating objects on the fly, here I propose a structured
definition of an object using this syntax:

object $app instanceof B{
$world = "midori";
// allowed methods comes after method definition
// in the beginning state allowed methods are foo and bar
public function __construct($world){
// if method body is implemented,
// parent class method run automatically
// object method runs after.
// This block runs $app = new B($world);
$this->foo(1,2);
}(foo, bar);

// The only allowed method is bar in this state
public function foo(1,2)(bar);

// if allowed methods are empty or not defined
// object is destructed
public function bar(3,4){
};
}
An object can be instance of a class, if it's not defined, is instance of
an anonymous class.

-- 

Midori Koçak
Computer Scientist & Engineer
http://www.mynameismidori.com <http://www.mtkocak.com/>
“*The most beautiful thing we can experience is the mysterious. It is the
source of all true art and science.*” Albert Einstein

[PHP-DEV] Re: [RFC Proposal] Null Coalesce Equal Operator

[Midori Koçak]

what is sugar?

On Monday, 11 April 2016, S.A.N  wrote:

> Maybe even more sugar? :)
>
> 
> class SugarCache
> {
>  // Methode getValueFromDB() called, if its value null
>  public $value ??= $this->getValueFromDB();
>
>  // Methode getValueFromDB() called, if $value not transmitted or null
> value
>  public function __construct($value ??= $this->getValueFromDB())
>  {
>   //...
>  }
>
>  public function getFromCache()
>  {
>   // Methode getValueFromDB() called, once upon init static $value
>   static $value ??= $this->getValueFromDB();
>
>   return $value;
>  }
> }
>