Re: [PHP-DEV] Final properties

[André Rømcke]

On 14. apr. 2016, at 11.47, Lester Caine  wrote:
> 
>> On 14/04/16 08:52, André Rømcke wrote:
>> * https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
> 
> This actually summarises many of the problems all of these 'extras' are
> creating for very little gain.
> 
> 'Seconds' is a 'Traditional Property' so is untyped and if accessed as a
> value from some OS's will be a floating point number[...]

It wasn't really the example I intended to point to, it does not represent the 
cases me and others refer to. I was linking to it for the possible solution to 
handle type and immutability.

Examples for the latter:
https://en.m.wikipedia.org/wiki/Value_object

> 
> I don't see how the idea of 'optimizing' the compiled code has any
> bearing on handling a 'typed property' when one has to have an object to
> contain even the simple of type information?


What is this regarding?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Types

[Tom Worster]

On 4/15/16 1:58 PM, Dmitry Stogov wrote:

A week ago, I actually wrote my own RFC 
https://wiki.php.net/rfc/nullable_return_types


You proposed the ?Something grammar. With ?: and ?? appearing in recent 
PHP and proposals for ??= if not ?:= and now this, I feel we're heading 
to regex hell :p


Tom


but didn't push it for discussion in favor of Levi's  nullable_type RFC (they 
are almost the same).



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

Re: [PHP-DEV] Trying to fix "use" language inconsistencies

[Lin Yo-An]

I thought there was one already?
https://wiki.php.net/rfc/group_use_declarations

On Sat, Apr 16, 2016 at 9:01 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi internals,
>
>
> It all started with a PR over doctrine/annotations (
> https://github.com/doctrine/annotations/pull/69), where a contributor
> decided to propose supporting group use support.
>
> The issue starts with this, which it is perfectly supported:
>
> use Foo\Bar, Foo\Woo;
>
> While multiple group uses are not:
>
> use Foo\{Bar, Baz}, Qux\{Corge, Grault};
>
> Then I decided to see what is really supported by the newly introduced
> group use. According to the grammar, these are the same lines:
>
> use Foo\Bar, Foo\Baz;
> use Foo\{Bar, Baz};
>
> use function Foo\Bar\baz, Foo\Bar\qux;
> use function Foo\Bar\{baz, qux};
> use Foo\Bar\{function baz, function qux};
>
> However, this feature leads to an inconsistent behavior in the language.
> Mixed group use types are supported:
>
> use Foo\Bar\{Baz, function qux};
>
> While mixing use types are not:
>
> use Foo\Bar\Baz, function Foo\Bar\qux;
>
>
> This brings the question of whether we should continue this madness path of
> inconsistency or we start addressing inconsistencies one by one in the
> language.
> I'd like to propose options that we could fix this:
>
> - Remove mixed group use types support (this would become invalid: use
> Foo\{Bar, function baz};)
> - Add mixed use support, which would contradict the approach took by typed
> properties (this would require this approach: use function Foo\Bar\baz,
> function Foo\Bar\qux;)
>
> One of the approaches needs to be taken in order to support multiple group
> use, otherwise we have a reduce/reduce yacc error that can't be fixed
> (well, my yacc/compiler's knowledge hit a dead end there, without doubling
> all the grammar rules and taking an overly complex route). Ultimately, the
> question comes around if we should consider support of multiple group use.
> If positive, I'd suggest approach two (I already have a patch for that!
> =D).
>
>
> I'd like to gather opinions around this, so I can properly implement and
> propose a patch through an RFC process.
>
>
> Regards,
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>



-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

If we can pre-define the types via something like this:

data Tree a = Branch (Tree a) (Tree a) | Leaf a


And only allow one type for each function parameter in the prototype, then,
I think the performance impact of type checking in the runtime can be
reduced.

In other words, you predefine the union type before you used them, and the
union types can be reused in different functions, you don't write a lot
union type in function prototype.

For example,

   typedef T = array | Traversable

   function foo(T $a) {  }
   function bar(T $b) {  }

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

I pretty much like the Haskell type system, it let you define types via the
syntax below:

data Tree a = Branch (Tree a) (Tree a) | Leaf a


But the type inference in Haskell can be resolved in the compile-time. We
can only verify the variable type for each function call in PHP.

[PHP-DEV] Trying to fix "use" language inconsistencies

[guilhermebla...@gmail.com]

Hi internals,


It all started with a PR over doctrine/annotations (
https://github.com/doctrine/annotations/pull/69), where a contributor
decided to propose supporting group use support.

The issue starts with this, which it is perfectly supported:

use Foo\Bar, Foo\Woo;

While multiple group uses are not:

use Foo\{Bar, Baz}, Qux\{Corge, Grault};

Then I decided to see what is really supported by the newly introduced
group use. According to the grammar, these are the same lines:

use Foo\Bar, Foo\Baz;
use Foo\{Bar, Baz};

use function Foo\Bar\baz, Foo\Bar\qux;
use function Foo\Bar\{baz, qux};
use Foo\Bar\{function baz, function qux};

However, this feature leads to an inconsistent behavior in the language.
Mixed group use types are supported:

use Foo\Bar\{Baz, function qux};

While mixing use types are not:

use Foo\Bar\Baz, function Foo\Bar\qux;


This brings the question of whether we should continue this madness path of
inconsistency or we start addressing inconsistencies one by one in the
language.
I'd like to propose options that we could fix this:

- Remove mixed group use types support (this would become invalid: use
Foo\{Bar, function baz};)
- Add mixed use support, which would contradict the approach took by typed
properties (this would require this approach: use function Foo\Bar\baz,
function Foo\Bar\qux;)

One of the approaches needs to be taken in order to support multiple group
use, otherwise we have a reduce/reduce yacc error that can't be fixed
(well, my yacc/compiler's knowledge hit a dead end there, without doubling
all the grammar rules and taking an overly complex route). Ultimately, the
question comes around if we should consider support of multiple group use.
If positive, I'd suggest approach two (I already have a patch for that! =D).


I'd like to gather opinions around this, so I can properly implement and
propose a patch through an RFC process.


Regards,

-- 
Guilherme Blanco
Lead Architect at E-Block

Re: [PHP-DEV] Re: Improving PHP's type system

[Lin Yo-An]

On Sat, Apr 16, 2016 at 1:28 AM, Christoph Becker  wrote:

> On 15.04.2016 at 17:42, Larry Garfield wrote:
>
> Maybe we should consider to accept an array as Traversable?  Actually, I
> wonder why that's not already the case.
>

+1, I think so too.


-- 
Best Regards,

Yo-An Lin

Re: [PHP-DEV] Typed properties patch

[Lester Caine]

On 15/04/16 22:01, Yasuo Ohgaki wrote:
>> public Node | null $left;
> Value must be able to be NULL.
> SQL has "NOT NULL" constraint. We may have "MAY NULL" and
> this syntax seems reasonable choice.

While the value of a field may be constrained as NOT NULL, it may also
be defined as DEFAULT xxx which will be used if the record being written
HAS a null value for that field. You will only get an error writing the
field if there is not a defined DEFAULT for a NOT NULL field.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Stanislav Malyshev]

Hi!

> All of PHP users _should_ avoid probability based GC
> whenever it is possible. Why we shouldn't have API that kills
> custom of probability based usage?

No, they shouldn't. Just claiming that your favorite use case should fit
everybody does not make it so.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

[Yasuo Ohgaki]

Hi Stas,

On Wed, Apr 13, 2016 at 2:25 AM, Stanislav Malyshev  wrote:
>> Lack of proper API for required task is our problem. Misuse is not ours. 
>> IMHO.
>
> No, it is our problem. We can't just create whatever and throw it over
> the fence. The properly designed API has to make correct use very easy
> and incorrect use very hard. That's the point of designing the API, not
> just giving people means to run random pieces of C code from PHP.
>
> With that in mind, the API should be designed so that misuse -
> especially unintentional misuse - is hard. Not impossible - that we
> can't do - but hard. It *is* our responsibility.

I know there are different point views, but I'm against this POV.

There _must_ be API that achieves well defined tasks. There are many APIs
that do not do this, but I don't think this would be an excuse. There are many
examples in security related APIs.

Examples are
 - Database API that lacks basic escape function. Most DB APIs lack
   "identifier" escape API or even "string literal" escape API.
 - XPath 1.0 lacks "string literal" escape API at all.

I guess the API author's intention is "to avoid misuse of escape API".

This approach is proven to create more issues rather than preventing issues.

IMHO, there must be API for well defined/mandatory/recommended tasks.

>
>> The best way to perform GC would be cron task. Low traffic sites can
>> make sure obsolete session is deleted. High traffic site can avoid
>> occasional slow down by GC. I suppose almost all high traffic sites
>> uses memcached or like that does not require PHP's session GC at all,
>> though.
>
> Please be aware that the use case you are currently considering -
> whatever it is, does not matter - is about 0.001% of all use cases, or
> less. Just because PHP runs on millions of sites with wildly different
> requirements. So we should support big sites, small sites, slow sites,
> fast sites, etc.

My proposal is based on previous point of view.

All of PHP users _should_ avoid probability based GC
whenever it is possible. Why we shouldn't have API that kills
custom of probability based usage?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Typed properties patch

[Yasuo Ohgaki]

Hi all,

On Thu, Apr 7, 2016 at 9:44 PM, Bob Weinand  wrote:
>> 1) While parameters allow null to be accepted as the default value, null is 
>> never a valid value for a typed property.
>>
>> I think we must have a way to make properties explicitly nullable. Otherwise 
>> we won't be able to define even simple binary tree...
>>
>> class Node {
>>
>>   public Node $left = null;
>>   public Node $right = null;
>> }
>
> Eventually that, but I honestly would prefer to be more explicit with a typed 
> union
>
> public Node | null $left;

Value must be able to be NULL.
SQL has "NOT NULL" constraint. We may have "MAY NULL" and
this syntax seems reasonable choice.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

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

Re: [PHP-DEV] Re: Typed properties patch

[Stanislav Malyshev]

Hi!

> In most cases we avoid IS_UNDEF checks, verifying the most probable expected 
> types first.

But that's for something like ADD, not for property fetches, so I'm not
sure I understand how properties fit there yet. Does the optimization
also track the variable after fetching?

In any case, to use this without any UNDEF/NULL checks, you need to be
absolutely sure the value is always initialized to the right type. I.e.
if you have a class like:

class Point {
public int $x;
public int $y;
}

Then you need to request the following:

- Always require the default. Otherwise, even in ctor, you could use $x
in expression before it is initialized and assume it is long where it is
in fact null. For many classes, the default would be completely
arbitrary (e.g. 0 is not always a natural default).

- Somehow handle unserialization in order to ensure what is put into $x
is always int. Moreover, unserialization may involved __wakeup which
sets up some properties, and before those properties are set up, how do
we ensure they have the right types without checking? Unserialize data
can contain anything, we had enough trouble with this unserializing
internal objects.

- Ensure that no extension manually creates objects without properly
initializing the typed variables. Extensions can easily create objects
right now and they can put anything in the object's hashes, can we trust
that every extension does the right thing?

The cost of getting any of these wrong may be high - it's not just
getting weird conversion, if the engine assumes something is LONG or
STRING without checking, it can be memory corruption or even RCE if
we're particularly unlucky.

So I am very skeptical right now about the possibility of making
optimizations based on using property type without checking based on
just declared type in the class.

Additionally, if we *do* allow the possibility of NULL/UNDEF, the
performance loss would be quite minimal - we could still do
specialization based on assumed type, but then just insert something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
  op1 = _as_long;
}

for types that have natural default for longs, or something like:

if (UNEXPECTED(NULL_TYPE(op1)) {
zend_error("Undefined value where object is expected");
}

if we expected object. The cost of one branch that is almost never taken
should be quite minimal, and we avoid a lot of trouble on the way.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Nullable Types

[Lester Caine]

On 15/04/16 18:58, Dmitry Stogov wrote:
> I'm sure, union types bring too many conceptual and implementation questions, 
> and I even don't speak abut intersections.

The one problem I see with all of this is that it is reliant on every
single variable being passed in when in early PHP5 days the preference
was to move to hashes of data passed as arrays to open up flexibility.
None of my record handling currently relies on having every 'parameter'
formally defined, and elements of the record that are not passed in the
hash are most definitely replaced by null valued elements allowing the
DB engine to supply the relevant schema default unless it is replaced by
additional variable in the data array.

The idea of converting every record array into an object with multiple
'typed' variables seems to me to be a total overload to me, but if that
is what people think is essential to make PHP 'safer' then that some of
those variables are inherently 'null' or need to be switched to null if
a change is required back to the schema default. 'Union' does not fit
easily into this model?

Documenting the content of a record hash via the docblock comments fits
perfectly with this method working ...

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Larry Garfield]

On 4/15/16 12:28 PM, Christoph Becker wrote:

On 15.04.2016 at 17:42, Larry Garfield wrote:


I think there's 2 general use cases for union types that would be "good
things", which are different for & and |, and have very little...
intersection.  (*yaaa!*)

The OR case is for cases where the language doesn't support a unified
case at all.  The most obvious example here is array|Traversable.  If I
want "a thing I can foreach()", then PHP right now has no way of saying
that syntactically.  You have to type on array, or Traversable, or not
type at all.  array|Traversable is what you really want,

It is not what I would want, though.


because those
DO have an overlap (foreach-ablility), PHP is just incapable of
representing that otherwise.

Maybe we should consider to accept an array as Traversable?  Actually, I
wonder why that's not already the case.


It's been asked a few dozen times, but never went anywhere.  Mainly, I 
think, Traversable implies object, which implies certain passing 
semantics.  Array is a primitive, so has different passing semantics. 
There's probably other subtle issues like that which have kept the 
engine-gurus from trying to make it work.


My assumption here is "if it were that easy someone would have done it 
already".  (Which may not be an entirely accurate assumption, but seems 
logical given how often it's been asked for.)



A similar example would be callable|SomeInterface.  An interface can
specify a signature for __invoke(), which gives you documentation on the
format that is expected for a callable.  However, you can't strictly
enforce that because then you don't allow for a function or closure that
fits the same method signature.  That means you have to leave it
untyped.  This, I argue, would be better *and* reasonably type safe:

interface MiddlewareInterface {
   function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
   // ...
}

As that self-documents that MiddlewareInterface is the callable
signature we need, but still allows an arbitrary callable to be passed.
It's not perfect (I could pass a string of a function name that doesn't
have that interface and it would still explode), but it is an
improvement over middleware_builder() having no type specification at
all, as is the case today.

In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
  Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.


One of the key language design points I think we should be keeping in 
mind is that, on the whole, single-purpose features are inferior to more 
general capabilities that implicitly grant the same capability.  Thus, 
I'd argue that the Property Accessor RFC is superior to adding a half 
dozen keywords to object properties (because they implicitly grant all 
of those same capabilities with less mental overhead and fewer keywords) 
and Union Types are superior to special casing array|Traversable or 
array|ArrayAccess, etc.  (Making array a for-reals honest to goodness 
object would be good too, but that's a considerably larger issue.)  
Union Types side-step the need for more special cases, as they can be 
handled in user-space code.  It's not a perfect fix, but the perfect fix 
involves very BC-unfriendly changes to PHP (making everything an object, 
Go-style type aliases, etc.) that are not likely to happen any time soon.


Related: What would union types mean for the typed property RFC? Would 
this be a good solution or an evil solution:


class Foo {
  public array|Traversable $arr;
  public Foo $c;
}

--
--Larry Garfield


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

Re: [PHP-DEV] Improving PHP's type system

[Larry Garfield]

On 4/15/16 12:16 PM, Lin Yo-An wrote:

Andrea Faulds  於 2016年4月15日 星期五寫道：


This is something that particularly concerns me about union types, in that
they reduce type safety. If you have a union type of Foo|Bar for some
variable, then the set of methods you can call on that variable is actually
the intersection, not the union, of the set of methods you can call on Foo
and Bar. Which, unless those two classes share some interface, is probably
an empty set. So there's nothing you can actually do safely with it without
doing checks within the body of the function, and if you're doing that,
then why do we have a type declaration? It's only barely more useful than
omitting a type declaration at all; type declarations are supposed to
prevent you needing to check. On the other hand, if the two classes share
some methods, then either there's an interface you can already use here, or
you can create one. Either way, you don't need a union type.

+1 I agree. Language like Golang use interface to intersect the method
calls, I think that's better.


Go's interfaces are implicit rather than explicit. That's what makes 
micro-interfaces like that (which are often single-method) feasible.  
Anthony Ferrara proposed "weak interfaces" a few years ago but it was 
rejected (or didn't make it to a vote; I don't recall which).


Either way, Foo|Bar is not the main use case for union types.  See my 
earlier email.


--
--Larry Garfield


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

Re: [PHP-DEV] [RFC] Nullable Types

[Dmitry Stogov]

A week ago, I actually wrote my own RFC 
https://wiki.php.net/rfc/nullable_return_types
but didn't push it for discussion in favor of Levi's  nullable_type RFC (they 
are almost the same).

I'm sure, union types bring too many conceptual and implementation questions, 
and I even don't speak abut intersections.

Thanks. Dmitry.

From: Tom Worster 
Sent: Friday, April 15, 2016 20:17
To: Dmitry Stogov; internals
Subject: Re: [PHP-DEV] [RFC] Nullable Types

On 4/14/16 3:50 AM, Dmitry Stogov wrote:

> The up to date implementation for return-type-hints may be found at
> https://github.com/php/php-src/pull/1851/files

Splendid!

Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1].

Tom

[1] https://wiki.php.net/rfc/nullable_returns


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Christoph Becker]

On 15.04.2016 at 17:42, Larry Garfield wrote:

> I think there's 2 general use cases for union types that would be "good
> things", which are different for & and |, and have very little...
> intersection.  (*yaaa!*)
> 
> The OR case is for cases where the language doesn't support a unified
> case at all.  The most obvious example here is array|Traversable.  If I
> want "a thing I can foreach()", then PHP right now has no way of saying
> that syntactically.  You have to type on array, or Traversable, or not
> type at all.  array|Traversable is what you really want,

It is not what I would want, though.

> because those
> DO have an overlap (foreach-ablility), PHP is just incapable of
> representing that otherwise.

Maybe we should consider to accept an array as Traversable?  Actually, I
wonder why that's not already the case.

> A similar example would be callable|SomeInterface.  An interface can
> specify a signature for __invoke(), which gives you documentation on the
> format that is expected for a callable.  However, you can't strictly
> enforce that because then you don't allow for a function or closure that
> fits the same method signature.  That means you have to leave it
> untyped.  This, I argue, would be better *and* reasonably type safe:
> 
> interface MiddlewareInterface {
>   function __invoke(RequestInterface $req, ResponseInterface $res);
> }
> 
> function middleware_builder(callable|MiddlewareInterface $m) {
>   // ...
> }
> 
> As that self-documents that MiddlewareInterface is the callable
> signature we need, but still allows an arbitrary callable to be passed. 
> It's not perfect (I could pass a string of a function name that doesn't
> have that interface and it would still explode), but it is an
> improvement over middleware_builder() having no type specification at
> all, as is the case today.

In my opinion, `callable' is to weak a type hint to be really useful,
and it would be better if we would improve that (generics come to mind).
 Then you wouldn't need MiddlewareInterface at all and be not afraid
that somebody passes in an incompatible function.

-- 
Christoph M. Becker


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

Re: [PHP-DEV] [RFC] Nullable Types

[Tom Worster]

On 4/14/16 3:50 AM, Dmitry Stogov wrote:


The up to date implementation for return-type-hints may be found at
https://github.com/php/php-src/pull/1851/files


Splendid!

Thank you, Dmitry. I will refer to it in the nullable_returns RFC[1].

Tom

[1] https://wiki.php.net/rfc/nullable_returns


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

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/15/16 12:22 AM, Levi Morrison wrote:


My point is that `foo(bar(), $val)` won't die because bar may return
null. Bar is expected to return null sometimes.

For example, let's consider an administrator page where they look up
user information based on an identifier. The routine we'll use will
have this signature:

 function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error
(database successfully returned no results). If there is no User data
to display then it makes sense for the UI to present that differently.
Thus it makes sense to pass that User | Null onto the code that will
present it:

 $user_data = get_user($id);
 // ...
 $user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code
bases (I think every single one I've ever looked at).


This is a good example.

My opinion is that *because* get_user() can return null (a red flag) I 
prefer to see explicit handing of the null case before doing anything else.


If I would end up with `render_user_data(get_user($id))` I would 
consider it fair to not hint the param because I didn't earn it. I 
invented the faux docblock tag @sorry for this kind of thing.


Tom


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

Re: [PHP-DEV] Improving PHP's type system

[Lin Yo-An]

Andrea Faulds  於 2016年4月15日 星期五寫道：
>
>
> This is something that particularly concerns me about union types, in that
> they reduce type safety. If you have a union type of Foo|Bar for some
> variable, then the set of methods you can call on that variable is actually
> the intersection, not the union, of the set of methods you can call on Foo
> and Bar. Which, unless those two classes share some interface, is probably
> an empty set. So there's nothing you can actually do safely with it without
> doing checks within the body of the function, and if you're doing that,
> then why do we have a type declaration? It's only barely more useful than
> omitting a type declaration at all; type declarations are supposed to
> prevent you needing to check. On the other hand, if the two classes share
> some methods, then either there's an interface you can already use here, or
> you can create one. Either way, you don't need a union type.

+1 I agree. Language like Golang use interface to intersect the method
calls, I think that's better.



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

-- 
Sent from Gmail Mobile

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Tom Worster]

On 4/14/16 8:48 PM, Larry Garfield wrote:


I am highly, highly sceptical about nullable parameters or returns, and
frankly would rather they were not included in the language.  By nature
they undermine type safety.  At best, they indicate to all callers
"*every* time you call this function, you MUST put is_null() around it
or your program may fail randomly."


Yes.



While that's better to know
explicitly than not (which is the case for any untyped return, aka any
PHP code pre-7.0), it would be better still to, well, not have to worry
about that billion dollar mistake[1] cropping up in my code.


I agree.

To be clear, I do not intend the RFC to encourage nullable return or 
suggest that it's a fine thing to use. But given where we are, it's hard 
to imagine how to extirpate it.


When we started using PHP 7.0 type, initially when authoring new models 
(and using Yii2), it immediately became clear that we lacked two things: 
this and void returns. We're getting the latter in 7.1. It would be very 
nice if we could have both.


I'm a practical PHP user, with a generally conservative attitude to the 
language, often unmoved by proposals add a feature because some other 
more fashionable language has it (I call it language envy, to borrow 
from Freud). And while PHP 7.0 is good, I'd rather have Something|null 
in the return declaration than just in the docblock. That's all.




In a sense, if we really must allow for value-or-null (which I consider
a code smell in the 98% case) I'd prefer if it was ONLY available via
union types: That is, Something|null.  That's longer and clumsier to
type, and harder to read.  Which it should be. (Static casts in C++ have
a fugly syntax, which has been defended by the language designers on the
grounds that static casts are fugly, so the syntax for them should be as
well to remind you to stop doing it. There is a fair amount of validity
to that argument on affordance grounds, at least within C++.)  Using an
easy short hand notation for something that is inherently a code smell
when you're already typing your code only serves to encourage something
we should be training people out of in the first place.


With regard to syntax, I prefer the long form `Something|null`. That 
seems very clear to me. The proposed short-hand ? syntax always makes me 
think of what I hate most about regex.


Tom


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Christoph Becker]

On 14.04.2016 at 21:32, Jordi Boggiano wrote:

> I don't really think it's much more complex to grasp `Foo|Bar $foo` than
> only `Foo $foo`. I mean once you grasp the concept of type hints you
> probably have by then a good understanding of || and hopefully can
> derive understanding from there.
> 
> That said I agree it's rarely useful, and as such I am not expecting
> we'll see this all over the place, it's just nice to have when you need
> it, but I can't think of very many valid cases (nullable types are much
> more common).

There may not be very many cases for union types, but that might not
hinder some programmers to make extensive use of the feature, which
others may encounter in their APIs.

> Just to highlight one use case I can think of, here is one:
> 
> https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/MongoDBHandler.php#L51-L53
> 
> We need some sort of Mongo thing, and there are two available with
> different interfaces, so here both are accepted but as you see in the
> code below they are handled kinda separately. It would just save us
> those 3 lines of check if we could type-hint appropriately.

It occurs to me that this is an instance of parameter overloading:
accept one of two (or more) unrelated types and handle them separately
in a single function.  An alternative would be to have two (or more)
(factory) functions, each accepting one of the alternative types
(perhaps delegating to a common function for the common code, if necessary).

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Tom Worster]

On 4/14/16 3:25 PM, Fleshgrinder wrote:

On 4/14/2016 8:59 PM, Stanislav Malyshev wrote:

>Hi!
>

>>I don't know what is complicated about "string|Stringable" or "Foo|Bar"
>>since it is super self-explanatory. However, I find myself checking the

>
>It may be self-explanatory for you. It's much less self-explanatory for
>somebody just starting to learn. It is also very dangerous - if it's
>either Foo or Bar, can you call Foo::stuff on it or not? If it's string
>or not string, can you call strlen on it? Etc., etc. It adds a lot of
>cognitive load and complicates the whole picture. You may have a
>specific use case where it is useful (which we have yet to see btw) but
>please remember it's a language with literally millions of use cases and
>users.
>

Reduce assertions*, enhance self-documentation, making code more robust,


I disagree here. I think our programs are more robust when programmers 
avoid passing mixed types and write more simple code instead.


Hence I agree with Stas about the danger part. Union type hints are a 
hazard. Adding them to PHP as a new feature is like saying "here's a 
great new tool, pick it up and use it" but the tool is really a footgun.


Tom


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

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Levi Morrison]

> convinced by the rebuttles to change my mind.

s/rebuttles/rebuttals/

I thought about just letting it go like many typos/spelling mistakes
but it seemed too funny to not correct

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

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Levi Morrison]

> I'm not suggesting that we purge NULL from the language.  That's
> impractical/impossible. I'm suggesting we shouldn't soften the type system
> added in 7.0, which discourages its use in most cases, as it should be.

It is a common misconception I've heard several times now that union
types is weakening or softening the type system. I want to reiterate
that it is already possible to use multiple types. It is already done
in the wild. It is done all over our standard library. The union types
RFC just allows you to encode the specific types to be passed or
returned. In other words it is aiming to make using the dynamic types
of PHP safer by allowing you to explicitly write out the options.

The Nullable Return Types RFC is basically arguing that the only
useful union of types is `T | Null` and only for return types. I've
already stated a few of my concerns with that belief and have not been
convinced by the rebuttles to change my mind.

Also, to specifically address a concern Larry had earlier about
nullable types in general:

> I am highly, highly sceptical about nullable parameters or returns, and 
> frankly would rather they were not included in the language.

Just to clarify: we already have nullable parameters because of a
default of null. It's already in the language and people have asked
many times for this functionality to be expanded to include return
types. I should have kept a master list every time someone contacted
me on github, email, twitter, etc about this so I could easily list
them all as references in the relevant RFCs for demand for the
feature.

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

Re: [PHP-DEV] Improving PHP's type system

[Tom Worster]

On 4/13/16 5:06 PM, Stanislav Malyshev wrote:


Types are designed in a way enhancing the languages experience while
avoiding nearly every impact for people who want to ignore them.


This is not true. If it's in language, you have to understand it to be
able to use the language. Nobody writes code in vacuum - there are
libraries, communities, teams, best practices, tutorials, etc. So if
(hypothetically) you want to introduce algebraic types in PHP, then
since that moment you can not really be a PHP programmer if you don't
understand algebraic types. Otherwise you would not be able to
communicate with the rest of the community, understand and use code
written by others, contribute to projects, etc.


I agree. This is an important point. I should include it in my RFC[1] 
that argues pro nullable return but contra nullable params or unions. 
May I copy-paste?


Tom

[1] https://wiki.php.net/rfc/nullable_returns


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

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Larry Garfield]

On 4/15/16 4:55 AM, Lester Caine wrote:

On 15/04/16 05:22, Levi Morrison wrote:

Unless you like having is_null() scattered around your code in a hundred

places...  I don't. :-)

You have lots of code instead in exception handling away fro the normal
program flow?


[1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

--Larry Garfield

My point is that `foo(bar(), $val)` won't die because bar may return
null. Bar is expected to return null sometimes.

For example, let's consider an administrator page where they look up
user information based on an identifier. The routine we'll use will
have this signature:

 function get_user(string $id): User | Null;

It is possible for an identifier to not exist and this is not an error
(database successfully returned no results). If there is no User data
to display then it makes sense for the UI to present that differently.
Thus it makes sense to pass that User | Null onto the code that will
present it:

 $user_data = get_user($id);
 // ...
 $user_html = render_user_data($user_data);

In fact this is a common operation that is encountered in many code
bases (I think every single one I've ever looked at).

That is a possible database type scenario, although on all of my
systems, the 'guest' user will be accessed as a default which gives the
default user data set.

The main thing I see with the 'null is not needed' argument is that it
instead relies on 'exception handling'? If I am scanning a file or
reading a record set, at some point I hit the end, and in ALL my code
base I get a null object rather than result object, be that reading and
processing a file or a database feed. We have already had the complaints
about file handling should give an exception when there is nothing left,
but MY workflow keeps everything in line ... when the last record is
processed we see the 'null' and progress to the next step in the
process. There is nothing here that needs to involve throwing exceptions
which may well be coded out of line with the main program flow and make
debugging more difficult?


That there are a few small cases where PHP's current design makes NULL a 
reasonable sentinel value (custom iterators, fread() as you mention, 
etc.) does not mean that in most cases, returning ValueObject|Null is 
rude and abusive to users of your API.  Yes, end-of-file is not an 
exceptional case so should not throw an exception.  I completely agree 
there.  But "user not found" I'd argue is.  (Or rather, if it's not an 
exceptional case your data model is kinda broken to begin with, because 
why are you asking for a missing user?)  Or you're better off having an 
"empty" value instead, such as an anonymous user object.  That's still 
type safe.


I'm not suggesting that we purge NULL from the language.  That's 
impractical/impossible. I'm suggesting we shouldn't soften the type 
system added in 7.0, which discourages its use in most cases, as it 
should be.


--
--Larry Garfield


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

Re: [PHP-DEV] Re: Improving PHP's type system

[Larry Garfield]

On 4/15/16 10:10 AM, Andrea Faulds wrote:

Hi Stas,

Stanislav Malyshev wrote:

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the


It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture. You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.


This is something that particularly concerns me about union types, in 
that they reduce type safety. If you have a union type of Foo|Bar for 
some variable, then the set of methods you can call on that variable 
is actually the intersection, not the union, of the set of methods you 
can call on Foo and Bar. Which, unless those two classes share some 
interface, is probably an empty set. So there's nothing you can 
actually do safely with it without doing checks within the body of the 
function, and if you're doing that, then why do we have a type 
declaration? It's only barely more useful than omitting a type 
declaration at all; type declarations are supposed to prevent you 
needing to check. On the other hand, if the two classes share some 
methods, then either there's an interface you can already use here, or 
you can create one. Either way, you don't need a union type.


There are some cases where you can't create an interface, but if 
that's the case, I think it is more worthwhile to look at how we can 
fix those cases, rather than add what amounts to a hacky workaround.


Thanks!


I think there's 2 general use cases for union types that would be "good 
things", which are different for & and |, and have very little... 
intersection.  (*yaaa!*)


The OR case is for cases where the language doesn't support a unified 
case at all.  The most obvious example here is array|Traversable.  If I 
want "a thing I can foreach()", then PHP right now has no way of saying 
that syntactically.  You have to type on array, or Traversable, or not 
type at all.  array|Traversable is what you really want, because those 
DO have an overlap (foreach-ablility), PHP is just incapable of 
representing that otherwise.


A similar example would be callable|SomeInterface.  An interface can 
specify a signature for __invoke(), which gives you documentation on the 
format that is expected for a callable.  However, you can't strictly 
enforce that because then you don't allow for a function or closure that 
fits the same method signature.  That means you have to leave it 
untyped.  This, I argue, would be better *and* reasonably type safe:


interface MiddlewareInterface {
  function __invoke(RequestInterface $req, ResponseInterface $res);
}

function middleware_builder(callable|MiddlewareInterface $m) {
  // ...
}

As that self-documents that MiddlewareInterface is the callable 
signature we need, but still allows an arbitrary callable to be passed.  
It's not perfect (I could pass a string of a function name that doesn't 
have that interface and it would still explode), but it is an 
improvement over middleware_builder() having no type specification at 
all, as is the case today.


(Hat tip to Matthew O'Phinney for cueing me into this neat feature of 
interfaces and __invoke().)


On the flipside, the & is mostly useful for where you need multiple 
interfaces for something.  For instance, there's the PSR-7 
ResponseInterface.  Drupal also has a number of interfaces for value 
objects to indicate their cacheability metadata, such as 
CacheableMetadataInterface.  But that applies to more than just 
Responses, of course, so having it extend ResponseInterface is not 
good.  So how can I specify that I need an object that is BOTH 
ResponseInterface AND CacheableMetdataInterface?  That's an entirely 
reasonable thing to do, but currently PHP doesn't allow for it at all.  
Even having a custom interface that extends both of those doesn't help, 
because then my class needs to implement the child interface, not both 
parents.


Being able to type on function foo(ResponseInterface & 
CacheableMetadatInterface $r) seems entirely reasonable to me, and 
definitely more type safe than leaving it untyped and relying on 
documentation.


The danger zone is, as many people have noted, OR-ing interfaces 
together.  That does undermine type safety in most cases, I'd argue.  
However, it's also rather obvious when it does so, because you end up 
with a giant if-statement inside your function.  So while it's a risk, I 
don't think it's a subtle one, especially if well documented.


Actually, there is a use case for ORing interfaces, and that's for BC 
reasons.  Take, for instance, Symfony 2's routing system.  It started 
off with 

Re: [PHP-DEV] Re: Improving PHP's type system

[Levi Morrison]

> This is something that particularly concerns me about union types, in that
> they reduce type safety.

This is incorrect. Anyone using a union type now simply uses PHP's
dynamic type system. Going from no enforced type to restricting it to
N types does not in any circumstance reduce type safety.

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Andrea Faulds]

Hi Stas,

Stanislav Malyshev wrote:

I don't know what is complicated about "string|Stringable" or "Foo|Bar"
since it is super self-explanatory. However, I find myself checking the


It may be self-explanatory for you. It's much less self-explanatory for
somebody just starting to learn. It is also very dangerous - if it's
either Foo or Bar, can you call Foo::stuff on it or not? If it's string
or not string, can you call strlen on it? Etc., etc. It adds a lot of
cognitive load and complicates the whole picture. You may have a
specific use case where it is useful (which we have yet to see btw) but
please remember it's a language with literally millions of use cases and
users.


This is something that particularly concerns me about union types, in 
that they reduce type safety. If you have a union type of Foo|Bar for 
some variable, then the set of methods you can call on that variable is 
actually the intersection, not the union, of the set of methods you can 
call on Foo and Bar. Which, unless those two classes share some 
interface, is probably an empty set. So there's nothing you can actually 
do safely with it without doing checks within the body of the function, 
and if you're doing that, then why do we have a type declaration? It's 
only barely more useful than omitting a type declaration at all; type 
declarations are supposed to prevent you needing to check. On the other 
hand, if the two classes share some methods, then either there's an 
interface you can already use here, or you can create one. Either way, 
you don't need a union type.


There are some cases where you can't create an interface, but if that's 
the case, I think it is more worthwhile to look at how we can fix those 
cases, rather than add what amounts to a hacky workaround.


Thanks!
--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] Interpolation using ${} syntax with spaces inside the braces

[Rowan Collins]

Simon Welsh wrote on 15/04/2016 00:52:

When not inside a string, the inside of the ${...} is always treated as an
expression, by both PHP and HHVM (https://3v4l.org/i2kOP), so that looks like 
the
“correct” handling for inside a string.


The in-quotes behaviour makes sense when you consider the use cases it 
solves, e.g.


$foo = 'percent';
echo "${foo}age";

Arguably, the alternative bracketing style is clearer here, and doesn't 
have the name-expression conflict:


$foo = 'percent';
echo "{$foo}age";

So possibly you're right - in an ideal world ${ ... } should evaluate an 
expression whether inside a string or out, and {$...} can be used inside 
a string for isolating variables.


But given the horrendous BC issues of changing that now, I'm inclined to 
say that surrounding whitespace should be an error, and force the user 
to use less ambiguous syntax.


It occurs to me that this problem is made worse by the "implicit 
constant definition" where an undefined constant becomes a string. 
Removing the definition of the constant from the example, and 
suppressing notices, gives identical output in all versions: 
https://3v4l.org/3i2El Leave the notices on, though, and you'll see 
they're getting to that answer in different ways - PHP is mapping 
expression -> undefined constant -> string -> variable name. So you 
could have code that works one way for years, then define a global 
constant with the same name as the local variable, and suddenly 
everything would go haywire.


I would love to see that implicit definition officially deprecated, but 
that's for another thread...


Regards,
--
Rowan Collins
[IMSoP]

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

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-04-15

[lp_benchmark_robot]

Results for project PHP master, build date 2016-04-15 06:35:50+03:00
commit: 60b1441
previous commit:a186ac0
revision date:  2016-04-07 10:26:32+09:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.13% -0.53%  0.52%  
  7.08%
:-|   Drupal 7.36 cgi -T1  0.19%  0.50% -0.17%  
  4.11%
:-|   MediaWiki 1.23.9 cgi -T5000  0.18%  0.00%  1.53%  
  3.04%
:-|   bench.php cgi -T100  0.02%  0.01% 23.76%  
  2.25%
:-|  micro_bench.php cgi -T10  0.01%  0.01%  5.88%  
  3.66%
:-|  mandelbrot.php cgi -T100  0.07%  0.20% 28.91%  
  9.59%
---
* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2016-04-15/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] [RFC] Nullable Return Type Declaration

[Lester Caine]

On 15/04/16 05:22, Levi Morrison wrote:
>> Unless you like having is_null() scattered around your code in a hundred
>> > places...  I don't. :-)
You have lots of code instead in exception handling away fro the normal
program flow?

>> > [1] https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions
>> >
>> > --Larry Garfield
> My point is that `foo(bar(), $val)` won't die because bar may return
> null. Bar is expected to return null sometimes.
> 
> For example, let's consider an administrator page where they look up
> user information based on an identifier. The routine we'll use will
> have this signature:
> 
> function get_user(string $id): User | Null;
> 
> It is possible for an identifier to not exist and this is not an error
> (database successfully returned no results). If there is no User data
> to display then it makes sense for the UI to present that differently.
> Thus it makes sense to pass that User | Null onto the code that will
> present it:
> 
> $user_data = get_user($id);
> // ...
> $user_html = render_user_data($user_data);
> 
> In fact this is a common operation that is encountered in many code
> bases (I think every single one I've ever looked at).

That is a possible database type scenario, although on all of my
systems, the 'guest' user will be accessed as a default which gives the
default user data set.

The main thing I see with the 'null is not needed' argument is that it
instead relies on 'exception handling'? If I am scanning a file or
reading a record set, at some point I hit the end, and in ALL my code
base I get a null object rather than result object, be that reading and
processing a file or a database feed. We have already had the complaints
about file handling should give an exception when there is nothing left,
but MY workflow keeps everything in line ... when the last record is
processed we see the 'null' and progress to the next step in the
process. There is nothing here that needs to involve throwing exceptions
which may well be coded out of line with the main program flow and make
debugging more difficult?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] Re: Improving PHP's type system

[Marco Pivetta]

Tony, that sounds really like "real programmers use `dd -if -of`". Please
stop with that argument, as it really doesn't reflect reality. I keep
enhancing my software with new (stricter) type checking, when available.
For example, I'm eager to replace current docblocks declaring `void`
methods with the upcoming hint (7.1), and every time I add hints and type
strictness I find new hidden bugs on an already well-tested code (with 100%
coverage and mutation testing). These bugs are legit, they are just waiting
to happen.

Additionally, I would also love to get rid of docblocks for type-systems:
they are unreliable, hard to reflect and enforce nothing, which allows lazy
and sloppy programmers to just circumvent specifications as it best pleases
their mood, rather than the requirements.

Yes, I'm a real programmer too, and no, I don't use cosmic rays to write
code to my computer's hard drive, give it a rest.
On Apr 15, 2016 08:09, "Tony Marston"  wrote:

> "Levi Morrison"  wrote in message
> news:cafmt4nr4gmnbbsofydf5slotaeo1rzzipdgdv8v6y+z-6pv...@mail.gmail.com...
>
>>
>> There are too many people out there who are trying to make the language
>>> more complicated than it need be just to prove how clever they are.
>>>
>>
>> I can assure you I am not proposing these RFCs to show how clever I am.
>>
>
> If millions of programmers have written millions of lines of code to write
> effective programs WITHOUT the use of type hinting/enforcement, then how
> come there are some people out there who keep saying that PHP is a bad
> language because it does not have type checking? Those who cannot write
> effective software without these "clever" additions to the language are
> doing nothing but announcing to the world that they are not clever enough
> to write effective software using their own limited abilities.
>
> --
> Tony Marston
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: optimization for function call without paremters

[Lin Yo-An]

I think this optimization could be done by two approach:

1. Add another FCALL op, which init a function call and call that function
directly for functions without parameters.

2. Let the original INIT_FCALL support "call function when the number of
parameter == 0"

On Fri, Apr 15, 2016 at 5:27 PM, Lin Yo-An  wrote:

> Hi Dmitry,
>
>
> I found that INIT_FCALL doesn't use opline->result.var and DO_ICALL
> doesn't use op1 or op2. The original purpose of separating these two op was
> for sending parameters.
>
> However, if a function doesn't need parameters and it's an internal
> function, I think the operation could be merged into INIT_FCALL.
>
> So I guess we can do this below to reduce one bytecode for each function
> call without parameters:
>
> if (opline->extended_value == 0) {
>  // call the function directly and store the value in the result.
> }
>
> Your thoughts?
>
>
>
>
> Best Regards,
>
> Yo-An Lin
>



-- 
Best Regards,

Yo-An Lin

[PHP-DEV] optimization for function call without paremters

[Lin Yo-An]

Hi Dmitry,


I found that INIT_FCALL doesn't use opline->result.var and DO_ICALL doesn't
use op1 or op2. The original purpose of separating these two op was for
sending parameters.

However, if a function doesn't need parameters and it's an internal
function, I think the operation could be merged into INIT_FCALL.

So I guess we can do this below to reduce one bytecode for each function
call without parameters:

if (opline->extended_value == 0) {
 // call the function directly and store the value in the result.
}

Your thoughts?




Best Regards,

Yo-An Lin

Re: [PHP-DEV] Re: Improving PHP's type system

[Tony Marston]

"Levi Morrison"  wrote in message 
news:cafmt4nr4gmnbbsofydf5slotaeo1rzzipdgdv8v6y+z-6pv...@mail.gmail.com...


There are too many people out there who are trying to make the language 
more complicated than it need be just to prove how clever they are.


I can assure you I am not proposing these RFCs to show how clever I am.


If millions of programmers have written millions of lines of code to write 
effective programs WITHOUT the use of type hinting/enforcement, then how 
come there are some people out there who keep saying that PHP is a bad 
language because it does not have type checking? Those who cannot write 
effective software without these "clever" additions to the language are 
doing nothing but announcing to the world that they are not clever enough to 
write effective software using their own limited abilities.


--
Tony Marston


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