Hi,
On 22.01.19 21:34, Girgias wrote:
- phpversion (use PHP_VERSION constant)
The function takes an optional argument `string $extension`, what is the
replacement for that?
- intval (for arbitrary base change there exists the math function
base_convert)
I've seen and myself u
> - settype
AFAICS, there is no easy replacement for settype(). If the second argument is a
string literal, you can use type coercion + assignment at the price of
duplicating the occurrence of the first argument. If the second argument is not
known at compile time, you have to resort to a
Hi,
The arguments why to deprecate didn't seem much more than, this maybe could be
deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?
But some comments that I didn't notice in others.
>- php_uname (use PHP_OS constant)
PHP_OS
ср, 23 янв. 2019 г. в 12:04, Jani Ollikainen :
> Hi,
>
> The arguments why to deprecate didn't seem much more than, this maybe
> could be deprecated. I think there should usually be some
> benefits of deprecating, otherwise why not just leave it as it is?
>
> But some comments that I didn't notice
Full description
https://wiki.php.net/rfc/code_free_constructor
Draft realisation
https://github.com/php/php-src/compare/master...rjhdby:constructor
"Code free" constructor is constructor with only purpose to directly set
object properties from received parameters and, optionally, call parent
co
On 23.01.19 13:32, Andrey O Gromov wrote:
Full description
https://wiki.php.net/rfc/code_free_constructor
Draft realisation
https://github.com/php/php-src/compare/master...rjhdby:constructor
"Code free" constructor is constructor with only purpose to directly set
object properties from received
On Wed, 23 Jan 2019 at 09:02, Markus Fischer wrote:
> Hi,
>
> On 22.01.19 21:34, Girgias wrote:
> > - phpversion (use PHP_VERSION constant)
>
> The function takes an optional argument `string $extension`, what is the
> replacement for that?
>
Didn 't realise not all of the extensions have a
>> Full description https://wiki.php.net/rfc/code_free_constructor
>> Draft realisation
https://github.com/php/php-src/compare/master...rjhdby:constructor
>>
>> "Code free" constructor is constructor with only purpose to directly
set
>> object properties from received parameters and, optionally,
On Wed, Jan 23, 2019 at 2:32 PM Andrey O Gromov wrote:
> Proposed syntax
> class A($prop) extends B("BlaBla", $prop) {
> }
Would this work with anonymous classes? If so, how would the syntax look like?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
>> Proposed syntax
>> class A($prop) extends B("BlaBla", $prop) {
>> }
>Would this work with anonymous classes? If so, how would the syntax look
like?
Currently this syntax can't be used with anonymous classes because those
classes instantiated
at once they declared and same syntax is used for
> Le 23 janv. 2019 à 14:19, Girgias a écrit :
>
>
>
> On Wed, 23 Jan 2019 at 09:19, Claude Pache wrote:
>
>>
>>> - settype
>>
>> AFAICS, there is no easy replacement for settype(). If the second argument
>> is a string literal, you can use type coercion + assignment at the price of
>> d
On Wed, 23 Jan 2019 at 15:43, Claude Pache wrote:
> So, since you didn’t see, here are some practical usages of settype():
>
> function foo($bar) {
> // $bar is supposed to be either a string, or a list of strings
> settype($bar, 'array');
> // ...
> }
>
> function qux($id) {
>
On Tue, 22 Jan 2019 at 20:34, Girgias wrote:
>
> a list of functions which seem reasonable to deprecate
> Classes/Objects functions:
>
>- is_a (use instanceof operator)
This is a fundamentally bad idea.
Functions can be passed around as functions, operators cannot be,
which makes it easie
On Wed, 23 Jan 2019 at 12:32, Andrey O Gromov wrote:
>
> Full description
> https://wiki.php.net/rfc/code_free_constructor
> Draft realisation
> https://github.com/php/php-src/compare/master...rjhdby:constructor
>
If this RFC solves a big problem for you, I would strongly recommend
looking at sol
On Wed, Jan 23, 2019 at 6:57 AM Bruce Weirdan wrote:
>
> On Wed, Jan 23, 2019 at 2:32 PM Andrey O Gromov wrote:
>
> > Proposed syntax
> > class A($prop) extends B("BlaBla", $prop) {
> > }
>
> Would this work with anonymous classes? If so, how would the syntax look like?
I have the same question.
On Tue, Jan 22, 2019 at 1:35 PM Girgias wrote:
>
> Greetings PHP internals,
> After skimming through the PHP documentation, I came up with a list of
> functions which seem
> reasonable to deprecate as of PHP 8 and I would like to gather some
> opinions from Internals.
> If this seems like it's too
On 1/22/2019 1:34 PM, Girgias wrote:
Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in
> 2.78 million vs. 5.1 million* code references.
> 1.54 million results.
> 10 million results. Broad, active usage.
> ...
I would not in any way base deprecation decisions on current usage
statistics. If there are several ways to do something, and one is clearly
better than the others (naming con
On Wed, 23 Jan 2019 at 16:37, Benjamin Morel
wrote:
> > 2.78 million vs. 5.1 million* code references.
> > 1.54 million results.
> > 10 million results. Broad, active usage.
> > ...
>
> I would not in any way base deprecation decisions on current usage
> statistics. If there are several ways to
On Wed, 23 Jan 2019 at 16:23, Dan Ackroyd wrote:
> On Tue, 22 Jan 2019 at 20:34, Girgias wrote:
> >
> > a list of functions which seem reasonable to deprecate
>
> > Classes/Objects functions:
> >
> >- is_a (use instanceof operator)
>
> This is a fundamentally bad idea.
>
> Functions can b
On Wed, 23 Jan 2019 at 17:25, Girgias wrote:
> I understand the rationale for functional programming, may I ask
> in your opinion should PHP have built-in functions for arithmetic
> operations so that it can be used in such a way without needing userland
> implementations?
>
There was a proposa
On Wed, Jan 23, 2019 at 8:43 AM Levi Morrison wrote:
>
> On Wed, Jan 23, 2019 at 6:57 AM Bruce Weirdan wrote:
> >
> > On Wed, Jan 23, 2019 at 2:32 PM Andrey O Gromov wrote:
> >
> > > Proposed syntax
> > > class A($prop) extends B("BlaBla", $prop) {
> > > }
> >
> > Would this work with anonymous
On Wed, 23 Jan 2019 at 18:30, Rowan Collins wrote:
> On Wed, 23 Jan 2019 at 17:25, Girgias wrote:
>
> > I understand the rationale for functional programming, may I ask
> > in your opinion should PHP have built-in functions for arithmetic
> > operations so that it can be used in such a way witho
On 23.01.2019 at 18:30, Rowan Collins wrote:
> On Wed, 23 Jan 2019 at 17:25, Girgias wrote:
>
>> I understand the rationale for functional programming, may I ask
>> in your opinion should PHP have built-in functions for arithmetic
>> operations so that it can be used in such a way without needin
Hi internals,
Linux namespaces have been around for a long time and in recent years their
usage has increased dramatically with the popularization of containers.
Modern browsers also make use of them to sandbox certain processes and so
on. To quote an introduction to the subject:
The purpose of e
On 23/01/2019 21:15, Pedro Magalhães wrote:
I think it can be useful for a language to expose this functionality to the
users for that kind of purpose (ie. run a security sensitive task in
isolation, simulate certain conditions like no network access, etc..). For
that end, I've put forward https:
Hi George,
Iiuc, the problem you're trying to solve is that PHP offers too many
ways to do the same thing and if there were fewer then PHP code would be
easier to write, read and maintain.
Differences in code that make no difference to the compiler are
differences in style.
The conventiona
On Wed, 23 Jan 2019 at 17:25, Girgias wrote:
> I understand the rationale for functional programming, may I ask
> in your opinion should PHP have built-in functions for arithmetic
> operations so that it can be used in such a way without needing userland
> implementations?
No, but only I'd much
Hi!
> Proposed syntax
> class A($prop) extends B("BlaBla", $prop) {
> }
This looks like unobvious magic. PHP approach has traditionally been to
avoid unobvious magic, and be explicit about what is happening. This
functionality does not seem no be enabling anything different, and seems
to be prett
29 matches
Mail list logo
