On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans wrote:
> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this.
> Good for you! Come take a stab at my legacy project. It's horrendous. We have
> some files where using PhpStorm's automatic formatting actually caused
> stuff to break. So, you can see why I might be a little reticent to depend on
> an automated tool to change my php tags. I'll let you start
> Le 14 août 2019 à 19:01, Olumide Samson a écrit :
>
> This was exactly my reason for participating in this discussion, if such
> simple BC break encounters fierce and lengthy-weighted resistance, I'm not
> sure there will ever be a BC break, only additions without a necessary
> cleanup.
>
>
I would say, PHP needs a direction(where're we headed?) than having a split
language.
Seriously, the core team have *tons of kudos* from the outside world(even
outside of PHP) and i think something called for those serious
implementation and i believe everyone(or simply put, the majority) one day
On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk wrote:
> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people do
On Wed, Aug 14, 2019 at 12:22 PM Robert Korulczyk
wrote:
> > While possibly a bit hyperbolic, most of the arguments basically come
> off that way to me as well. I've definitely viewed most of what you've said
> in
> > that manner.
>
> I guess we're in some kind of limbo where half of the people
> While possibly a bit hyperbolic, most of the arguments basically come off
> that way to me as well. I've definitely viewed most of what you've said in
> that manner.
I guess we're in some kind of limbo where half of the people do not consider
problems which short open tags create as serious,
> On Aug 14, 2019, at 11:14, Derick Rethans wrote:
>
> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this.
On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon wrote:
> On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans wrote:
>
> > https://wiki.php.net/rfc/p-plus-plus
> >
> > To follow up my no vote; What I'm against is splitting the language on
> hard boundaries that never disappear, only widen. I'm also a
Hi!
my 2c:
As I understood, Zeev said about two camps: ones want to make PHP more strict,
others – not.
Maybe, is more productive to discuss the general direction of PHP (it will be a
strict road or not) instead of 4 months disputes about short open tags, or
sisters language or other
On Wed, Aug 14, 2019 at 10:49 AM Robert Korulczyk
wrote:
> > This discussion has gone out of sanity levels the moment people started
> to state that short tags is one (of the many)
> > things PHP has why new programmers and companies don't pick the language
> or why colleagues laugh at you and
On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans wrote:
> https://wiki.php.net/rfc/p-plus-plus
>
> To follow up my no vote; What I'm against is splitting the language on
hard boundaries that never disappear, only widen. I'm also a 'No' on
Editions, but slightly less of a 'No', and possibly a
Hi,
In the last week(s) there has been a lot of chat about Zeev's P++ idea.
Before we end up spending this project's time and energy to explore this
idea further, I thought it'd be wise to see if there is enough animo for
this. Hence, I've created a document in the wiki as a poll:
> This discussion has gone out of sanity levels the moment people started to
> state that short tags is one (of the many)
> things PHP has why new programmers and companies don't pick the language or
> why colleagues laugh at you and is a
> blocker of new bright future etc. and now in this
> Please, let's keep this discussion at some level of sanity... You basically
> need
> stick to static HTML if you're considering possibility of such exec() usage
> as a
> security issue.
This discussion has gone out of sanity levels the moment people started to
state that short tags is one
On Wed, Aug 14, 2019 at 7:03 AM Olumide Samson
wrote:
> On Wed, Aug 14, 2019, 11:24 AM Peter Kokot wrote:
>
> > On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, wrote:
> >
> > > > It is surprising how thing that is considered by one to be a security
> > > risk, is treated
> > > > as nothing relevant
W dniu 14.08.2019 o 14:14, Reinis Rozitis pisze:
> Depends on how you look at if exec($_GET['param']) is a language
> responsibility or programmers?
Please, let's keep this discussion at some level of sanity... You basically
need stick to static HTML if you're considering possibility of such
> Honestly, I don't see how allowing exec/passthru/proc_open is a security risk.
> These are just tools. We're talking about programming language - if you're
> running PHP script as user X you should expect that it could do anything that
> user
> X can do. If you don't trust this script, just
> Sure those are important - I was just pointing out that the "security card"
> is questionable since the language has more dangerous features
> which ask for the user to be careful and responsible about them rather than
> making everything foolproof and accident-free.
Honestly, I don't see how
On Wed, Aug 14, 2019, 11:24 AM Peter Kokot wrote:
> On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, wrote:
>
> > > It is surprising how thing that is considered by one to be a security
> > risk, is treated
> > > as nothing relevant by others. This dichotomy is quite disturbing - in
> > what case
> >
> This is about accidental usage of *language* feature, which *by design* can
> lead to code leaks (so application bug, not misconfigured environment).
> Clearly not a language problem that it has dedicated feature to shoot
> yourself in the foot...
>
> These methods have their purpose (pretty
W dniu 14.08.2019 o 12:09, Reinis Rozitis pisze:
> It's questionable that a misconfigured environment is a "security" risk
> caused by language rather than ignorance of the administrator.
This is not about misconfigured environment. This is about accidental usage of
*language* feature, which
śr., 14 sie 2019 o 12:17 Michał Brzuchalski
napisał(a):
>
>
> śr., 14 sie 2019 o 12:11 Rowan Collins
> napisał(a):
>
>> On 14/08/2019 11:07, Michał Brzuchalski wrote:
>> > Exactly so how would it know from string name either it should load
>> class
>> > from src/Foo.php or src/__nsmeta.php if
On 14/08/2019 11:17, Michał Brzuchalski wrote:
Following that would introduce unneeded additional directory hierarchy
level in a usual library
which uses PSR-4 which is the most used one, right?
/composer.json
/src/Foo.php
/src/Foo/ <- all package classes should go here?
That would be one
On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, wrote:
> > It is surprising how thing that is considered by one to be a security
> risk, is treated
> > as nothing relevant by others. This dichotomy is quite disturbing - in
> what case
> > removing security risk is "no real gain"?
>
> It's
śr., 14 sie 2019 o 12:11 Rowan Collins napisał(a):
> On 14/08/2019 11:07, Michał Brzuchalski wrote:
> > Exactly so how would it know from string name either it should load class
> > from src/Foo.php or src/__nsmeta.php if there is no information?
>
>
> It wouldn't. It would include src/Foo.php,
On 14/08/2019 11:07, Michał Brzuchalski wrote:
Exactly so how would it know from string name either it should load class
from src/Foo.php or src/__nsmeta.php if there is no information?
It wouldn't. It would include src/Foo.php, and that would have the
definition of something with the name
> It is surprising how thing that is considered by one to be a security risk,
> is treated
> as nothing relevant by others. This dichotomy is quite disturbing - in what
> case
> removing security risk is "no real gain"?
It's questionable that a misconfigured environment is a "security" risk
śr., 14 sie 2019 o 11:49 Rowan Collins napisał(a):
> > You suggest that it would trigger autoload to load "MyVendor\MyPackage"
> > but current autoload machinery is able to load only classes,
> > not even functions or consts! cause it gets the only class name now.
> > It would need to be changed
W dniu 14.08.2019 o 11:09, Christian Schneider pisze:
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
>>> The best counterargument I can give against "cleaning up" is that it takes
>>> energy away from actual new features, even if it's just the mental energy
>>> of monitoring and responding to
On 14/08/2019 10:27, Michał Brzuchalski wrote:
But that's conflicting with you above idea for package definition like
that:
That's not what I'm suggesting; perhaps my example could have been
clearer. I envisage two new keywords:
- To put some code in a package, you would write "package
śr., 14 sie 2019 o 11:01 Rowan Collins napisał(a):
> I don't see this as a problem. Right now, PHP doesn't care how many
> files you put your code in. As far as I know, you could concatenate the
> entirety of Laravel into one PHP file, and applications would not be
> able to tell the difference.
On Wed, 14 Aug 2019 at 11:09, Christian Schneider wrote:
>
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
> >> The best counterargument I can give against "cleaning up" is that it takes
> >> energy away from actual new features, even if it's just the mental energy
> >> of monitoring and
Am 14.08.2019 um 10:39 schrieb Peter Kokot :
>> The best counterargument I can give against "cleaning up" is that it takes
>> energy away from actual new features, even if it's just the mental energy of
>> monitoring and responding to long threads like this one.
>
> Code is like a garden. If
On 14/08/2019 09:39, Peter Kokot wrote:
Code is like a garden. If there are unwanted weeds and nobody cleans
them up, the flowers don't shine and grow as they should. Cleaning of
the weeds is just as important as new features. A bit less but
important.
It's a pretty analogy, but I don't
On 14/08/2019 07:45, Michał Brzuchalski wrote:
It doesn't have to be a new syntax if we agree to put package definiction
in sort of separate configuration file.
With the exception of INI files, all your examples are new syntax, as
far as the internal mechanisms in PHP are concerned. They
On Wed, 14 Aug 2019 at 10:11, Rowan Collins wrote:
>
> On 13 August 2019 19:19:42 BST, Olumide Samson wrote:
> >Not sure what the counter argument is really driving at.
> >So, because some people are using a function or an unworthy directive,
> >then
> >there can't be a major change in that
On 13/08/2019 23:28, Mark Randall wrote:
On 13/08/2019 21:26, Rowan Collins wrote:
Ah, that makes sense. Does that necessarily mean we need a dummy
class, though? The autoloading logic in the engine knows that it
called the autoload callback expecting a package definition, so can
count as
On 13 August 2019 19:19:42 BST, Olumide Samson wrote:
>Not sure what the counter argument is really driving at.
>So, because some people are using a function or an unworthy directive,
>then
>there can't be a major change in that aspect?
That's not what anyone is saying. What people are saying
Hi Rowan,
wt., 13 sie 2019 o 22:26 Rowan Collins napisał(a):
> On 13/08/2019 18:45, Mark Randall wrote:
> > I thought about this as my first consideration, however it effectively
> > requires that the PHP code within the package class is fully parsed
> > and executed in order for it to retrieve
40 matches
Mail list logo
