Re: [PHP-DEV] return values of socket_recvmsg

[Kalle Sommer Nielsen]

Hi Sam

2018-01-25 23:11 GMT+01:00 Sam Ding :
>
> The test case  ext/sockets/tests/socket_recvmsg.php  has following output
> on x86_64:
>
> ===
> ...
> 1 Array
> 2 (
> 3[name] => Array
> 4(
> 5[family] => 10
> 6[addr] => ::1
> 7[port] => 7001
> 8[flowinfo] => 0
> 9[scope_id] => 0
> 10)
> 11
> 12[control] => Array
> 13   (
> 14[0] => Array
> 15   (
> 16[level] => 41
> 17[type] => 50
> 18[data] => Array
> 19   (
> 20[addr] => ::1
> 21[ifindex] => 1
> 22)
> 23)
> 24)
> ...
> ===
> This is output  by c
> function:"socket_recvmsg"(/home/work/php/php/ext/sockets/sendrecvmsg.c:214),

You can find the implementation of socket_recvmsg() in the ext/sockets
directory here:
http://git.php.net/?p=php-src.git;a=blob;f=ext/sockets/sendrecvmsg.c;h=7b9c4e8ad357b73b514dc5feb8dc8d9ca215126b;hb=HEAD#l210



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Niklas Keller]

Michael Morris  schrieb am Fr., 26. Jan. 2018, 02:06:

> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller  wrote:
>
> >
> >>
> >> $a instanceof array
> >>
> >
> > That might work, but array should only return true if it's an
> > array, not for anything that implements ArrayAccess.
> >
> >
>
> Related:
>
> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
>
> >
> >
> > I see no value to this operator being applied to non-array
> > traversables.
>
>
> If an array access object can't masquerade as an array it loses some of its
> value, but Niklas is right - it is important to distinguish such objects
> from native arrays.  One solution would be to promote "iterable" to keyword
> status.  The flexibility to take any iterable will be needed I think.
>
> $a instanceof iterable
>
> Would return true for anything iterable (which we can already test with
> is_iterable() ) where all values where strings.
>
> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
> >
> > Our iterators cannot always be reliably rewound, such as
> > when using generators. Checking that the generator returns only
> > strings would consume all the input and would therefore be useless.
>
>
> True - I hadn't thought of those. But as of PHP 7 generators can type
> declare their return value.


They can only define generator as return type, which is what they return
when you call a generator function.

Even if you could declare the return type of the generator, you'd still
have the same problem with the yielded values.

So, given `$a instanceof iterable`, if
> $a is a reference to a generator, then the engine could check the return
> type declaration and only give true on a match without attempting to use
> the generator.
>
> We can follow this pattern farther - The return of an
> ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
> instanceof rather than actually pulling data from these methods.
>
> We are having the return rely on the promise of the code, but in each case
> TypeError would be raised anyway if it breaks it's promise to instanceof so
> errors aren't being avoided.
>
>
>
> > Returns true if $a is an array (or implements array access) and that all
> >> it's members are strings.
> >>
> >> $b instanceof SomeClass
> >>
> >> Returns true if SomeClass can be iterated and contains only strings.
> >>
> >
> > This would block generics with that syntax then.
> >
>
> I don't understand this comment.
>

You restrict these type parameters to iterators, but generics are useful in
a lot more places.


> On Thu, Jan 25, 2018 at 5:28 PM, Larry Garfield 
>  wrote:
>
> >
> >
> > Is this to ensure that everything coming OUT of a collection is a given
> > type,
> > or that everything put IN a collection is a given type?
> >
>
> Ensure (or try to ensure, since reporting the promises of another method's
> return type isn't certain) that things coming OUT are a given type.  Leave
> the headache of guarding inputs for another day and RFC.
>
>
> >
> > Asserting that "at this point in time, everything in this collection is a
> > given type" is honestly fairly useless unless it's enforced to stay that
> > way.
>
>
> No more useless than type declarations are if a programmer does this...
>
> function foo (string $a) {
>   $a = (int) $a;
> }
>
> Every feature of the language can be rendered useless by the right amount
> of stupidity. No feature recommendation should be beholden to the "what if
> a moron does X?" argument.
>

Regards, Niklas

>

Re: [PHP-DEV] Difference between smart_str and smart_string

[Sara Golemon]

On Thu, Jan 25, 2018 at 10:50 PM, Ryan McCullagh  wrote:
> I have been browsing php-src and notice smart_string, and smart_str, each 
> with their header files. Why is there two seemingly identical structures with 
> the same name?
>
smart_string targets a raw char* buffer, smart_str targets a
refcountable zend_string*.
You'll almost always want the latter, except when you don't.

-Sara

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

[PHP-DEV] Difference between smart_str and smart_string

[Ryan McCullagh]

Hello internals,

I have been browsing php-src and notice smart_string, and smart_str, each with 
their header files. Why is there two seemingly identical structures with the 
same name?



-- 
Ryan McCullagh
ryanmccullagh.com

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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller  wrote:

>
>>
>> $a instanceof array
>>
>
> That might work, but array should only return true if it's an
> array, not for anything that implements ArrayAccess.
>
>

Related:

On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:

>
>
> I see no value to this operator being applied to non-array
> traversables.


If an array access object can't masquerade as an array it loses some of its
value, but Niklas is right - it is important to distinguish such objects
from native arrays.  One solution would be to promote "iterable" to keyword
status.  The flexibility to take any iterable will be needed I think.

$a instanceof iterable

Would return true for anything iterable (which we can already test with
is_iterable() ) where all values where strings.

On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison  wrote:
>
> Our iterators cannot always be reliably rewound, such as
> when using generators. Checking that the generator returns only
> strings would consume all the input and would therefore be useless.


True - I hadn't thought of those. But as of PHP 7 generators can type
declare their return value.  So, given `$a instanceof iterable`, if
$a is a reference to a generator, then the engine could check the return
type declaration and only give true on a match without attempting to use
the generator.

We can follow this pattern farther - The return of an
ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
instanceof rather than actually pulling data from these methods.

We are having the return rely on the promise of the code, but in each case
TypeError would be raised anyway if it breaks it's promise to instanceof so
errors aren't being avoided.



> Returns true if $a is an array (or implements array access) and that all
>> it's members are strings.
>>
>> $b instanceof SomeClass
>>
>> Returns true if SomeClass can be iterated and contains only strings.
>>
>
> This would block generics with that syntax then.
>

I don't understand this comment.


On Thu, Jan 25, 2018 at 5:28 PM, Larry Garfield 
 wrote:

>
>
> Is this to ensure that everything coming OUT of a collection is a given
> type,
> or that everything put IN a collection is a given type?
>

Ensure (or try to ensure, since reporting the promises of another method's
return type isn't certain) that things coming OUT are a given type.  Leave
the headache of guarding inputs for another day and RFC.


>
> Asserting that "at this point in time, everything in this collection is a
> given type" is honestly fairly useless unless it's enforced to stay that
> way.


No more useless than type declarations are if a programmer does this...

function foo (string $a) {
  $a = (int) $a;
}

Every feature of the language can be rendered useless by the right amount
of stupidity. No feature recommendation should be beholden to the "what if
a moron does X?" argument.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Larry Garfield]

On Thursday, January 25, 2018 4:11:02 PM CST Levi Morrison wrote:
> > IMPLEMENTATION STYLE #1:  collectionof operator
> > The style of implementation I like the most is a collectionof operator in
> > parallel to the instance_of operator.  It would be instanceof's plural
> > brother, so
> > 
> > $arg collectionof \SomeClass
> > 
> > To pass the check $arg must be of the iterable psuedotype with all its
> > values being a \SomeClass object.
> > 
> > This is all well and good, but collection integrity checks are usually
> > going to be looking to see if all the members are the same scalar.
> > 
> > $arg collectionof string
> > 
> > For language consistency we would need to allow instance_of to do the
> > same,
> > which it currently does not.
> > 
> > $arg instanceof string
> > 
> > This does create duplication with the is_* family of functions, but
> > instanceof already overlaps is_a heavily.
> 
> I see no value to this operator being applied to non-array
> traversables. Our iterators cannot always be reliably rewound, such as
> when using generators. Checking that the generator returns only
> strings would consume all the input and would therefore be useless.

I concur.  I'd actually ask what the intended goal is here.

Is this to ensure that everything coming OUT of a collection is a given type, 
or that everything put IN a collection is a given type?

Asserting that "at this point in time, everything in this collection is a 
given type" is honestly fairly useless unless it's enforced to stay that way.  
I can assert that "this array currently contains only strings", but the very 
next line could change that.  Unless we go the generics-lite route and allow 
code to declare $x = array (or whatever), in which case it becomes 
"enforce on the way in", and now we never need to check it because we know 
that only strings can be put in the array.

Plus, as Levi says, asserting that all values in a non-array iterable are a 
given type requires a full scan, which is often a destructive operation.

The better solution IMO is to allow for objects that enforce type on write, 
and for *different* objects that enforce type on read, even if lazy.  That is 
(pseudo code, do not take literally):

$a = new Collection;
$a[] = 5; // This will TypeError

Which we can *almost* get now, but it causes an interface mismatch error:

class Strings extends ArrayObject {
public function offsetSet(string $k, $v) {
parent::offsetSet($k, $v);
}
}

But that's essentially the logic we'd want.

On the read side (which you'd want for a generator or similar), the logic 
you'd want is essentially:

class Ints extends ArrayObject {
public function current() : int {
return parent::current();
}
}

Which lints fine, but when I tested it just now returns strings quite happily 
without a type error, which seems wrong to me.  (Why is it doing that, and is 
it a bug?)

In any case, in neither situation is collectionof particularly useful.  What 
is useful is a syntax-level "this collection will only allow type X to be 
added" specification and a "this iterable will always return type X" 
specification, both of which would generate a runtime TypeError or a compile-
time error if it could be detected.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

[PHP-DEV] Requesting php-src Karma

[Thomas Punt]

Hi internals,


I'd like to request for php-src karma for my account (tpunt) in order to help

with the handling of PRs on GitHub. Having been contributing to PHP for

a few years now, I feel like I've got the hang of things well enough to make

more of an impact to the project now.


Thanks,

Tom

[PHP-DEV] return values of socket_recvmsg

[Sam Ding]

The test case  ext/sockets/tests/socket_recvmsg.php  has following output
on x86_64:

===
...
1 Array
2 (
3[name] => Array
4(
5[family] => 10
6[addr] => ::1
7[port] => 7001
8[flowinfo] => 0
9[scope_id] => 0
10)
11
12[control] => Array
13   (
14[0] => Array
15   (
16[level] => 41
17[type] => 50
18[data] => Array
19   (
20[addr] => ::1
21[ifindex] => 1
22)
23)
24)
...
===
This is output  by c
function:"socket_recvmsg"(/home/work/php/php/ext/sockets/sendrecvmsg.c:214),
 which returns a struct "executor_globals.current_execute_data".

The struct  is defined as :

(gdb)  ptype executor_globals.current_execute_data
type = struct _zend_execute_data {
const zend_op *opline;
zend_execute_data *call;
zval *return_value;
zend_function *func;
zval This;
zend_execute_data *prev_execute_data;
zend_array *symbol_table;
void **run_time_cache;
zval *literals;
} *

Where do  the above output values  (line 18-21) store in the struct
_zend_execute_data ?


Thanks,

Sam

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Levi Morrison]

> IMPLEMENTATION STYLE #1:  collectionof operator
> The style of implementation I like the most is a collectionof operator in
> parallel to the instance_of operator.  It would be instanceof's plural
> brother, so
>
> $arg collectionof \SomeClass
>
> To pass the check $arg must be of the iterable psuedotype with all its
> values being a \SomeClass object.
>
> This is all well and good, but collection integrity checks are usually
> going to be looking to see if all the members are the same scalar.
>
> $arg collectionof string
>
> For language consistency we would need to allow instance_of to do the same,
> which it currently does not.
>
> $arg instanceof string
>
> This does create duplication with the is_* family of functions, but
> instanceof already overlaps is_a heavily.

I see no value to this operator being applied to non-array
traversables. Our iterators cannot always be reliably rewound, such as
when using generators. Checking that the generator returns only
strings would consume all the input and would therefore be useless.

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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Rowan Collins]

On 25/01/2018 20:19, Michael Morris wrote:

He's getting the syntax from Java.


Actually, from C++, and possibly from somewhere before that; at this 
point, it's pretty widely adopted.




The problem is that Java already has the policing
mechanics present in the runtime to police insertions into the collection
and guarantee they are of the correct type. PHP has no such mechanism in
place and in previous discussion threads the primary maintainers have
underscored that adding such is highly difficult.


That's only partially true. As Bishop Bettini pointed out, you can 
*almost* get there with features already in the language, because you 
can implement the magic ArrayAccess interface and intercept all 
assignments using the $foo[]=$val and $foo[$bar]=$val syntaxes.


The main problem, as usual, is references: you can't intercept "$ref =& 
$foo[$bar]; $ref=42;" - if you try, you get a somewhat cryptic notice 
that "Indirect modification of overloaded element of foo has no effect". 
Apart from that, this is a *lot* simpler as a problem than general type 
tracking, because we only care about those two specific operations, not 
everywhere that performs an assignment of any sort.


In that sense, a full implementation of generics is actually simpler: 
the only actual type checks would be on parameters and return types, 
where they're already supported, e.g. class Stack { public function 
push(T $item) { ... } public function pop(): T { ... } }


Like I say, it might be perfectly reasonable to have both a collectionof 
operator and generics in the language, but I don't think it's 
unreasonable to think about where they overlap.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Niklas Keller]

>
> On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller  wrote:
>
>>
>> So, given `$a collectionof string` the operator returns whether or not $a
>>> is, at that time, a collection of strings (be it an array or other
>>> iterable). It doesn't insure $a will stay that way - it's just a check of
>>> the variables status at a given moment, which is the best that can be
>>> hoped
>>> for in PHP.
>>>
>>
>> That should be a function, not an operator, unless you can bring up very
>> good arguments to make it an operator.
>>
>
> Consistency with instanceof.
>
>
>
> Hmm, it might be possible to just pile this all onto instanceof -
> following Derrick's mention of how Java does things, so here's a third
> implementation approach.  It would look like this:
>
> $a instanceof array
>

That might work, but array should only return true if it's an
array, not for anything that implements ArrayAccess.


> Returns true if $a is an array (or implements array access) and that all
> it's members are strings.
>
> $b instanceof SomeClass
>
> Returns true if SomeClass can be iterated and contains only strings.
>

This would block generics with that syntax then.


> The question is can the token parser handle that pattern?  Or does the
> current usage of < and > in their boolean form block this?
>
> If this third approach is accepted then we have no BC breaks at all since
> there's no new keyword or function. We just have a *very* expanded
> instanceof operator.
>

Regards, Niklas

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller  wrote:

>
> So, given `$a collectionof string` the operator returns whether or not $a
>> is, at that time, a collection of strings (be it an array or other
>> iterable). It doesn't insure $a will stay that way - it's just a check of
>> the variables status at a given moment, which is the best that can be
>> hoped
>> for in PHP.
>>
>
> That should be a function, not an operator, unless you can bring up very
> good arguments to make it an operator.
>

Consistency with instanceof.



Hmm, it might be possible to just pile this all onto instanceof - following
Derrick's mention of how Java does things, so here's a third implementation
approach.  It would look like this:

$a instanceof array

Returns true if $a is an array (or implements array access) and that all
it's members are strings.

$b instanceof SomeClass

Returns true if SomeClass can be iterated and contains only strings.

The question is can the token parser handle that pattern?  Or does the
current usage of < and > in their boolean form block this?

If this third approach is accepted then we have no BC breaks at all since
there's no new keyword or function. We just have a *very* expanded
instanceof operator.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Niklas Keller]

Michael Morris  schrieb am Do., 25. Jan. 2018, 21:19:

> On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins 
> wrote:
>
> > On 25/01/2018 14:52, Derick Rethans wrote:
> >
> >> IMO, it makes a lot more sense to check integrity when creating the
> >> "array" structure. Instead, I would suggest to add a native Collection
> >> type, that takes a "type" as argument. They aren't quite full generics,
> >> but it does 1. fix something; 2. isn't really complicated.
> >>
> >> What I am suggesting is to add a new syntax "Collection<$type>",
> >> mimicking a class, but having a type as "argument":
> >>
> >> $a = new Collection;
> >>
> >
> > So would I be right in thinking this would mean adding basic support for
> > generics to the engine, but not letting new ones be defined in userland?
> > So, a bit like how internal or extension classes have the ability to do
> > more overloading of casts and operators than userland classes?
> >
> > If so, I like the concept, but wonder whether the parts of the
> > implementation it would need are the easy parts of the hard ones. I guess
> > not being able to inherit from the generic would get rid of a bunch of
> > complexity, but don't really know where else the challenge lies.
> >
>
> He's getting the syntax from Java.  Java collections allow you to specify
> the type they are constrained to in <> after the class name.  Type Script
> does something similar.  The problem is that Java already has the policing
> mechanics present in the runtime to police insertions into the collection
> and guarantee they are of the correct type.  PHP has no such mechanism in
> place and in previous discussion threads the primary maintainers have
> underscored that adding such is highly difficult.
>
> It is also completely tangential to and a distraction from what I propose
> and would like to focus on here.  Regardless of whether PHP ever gets a
> core class or construct for type uniform collections, the ability to verify
> that variables are a "collection of something" will remain.  That is the
> issue I want to discuss and address here - verifying that existing
> variables are a given collection type, not debating pie-in-the-sky, may
> never be implementable classes that self insure their own integrity.
>
> So, given `$a collectionof string` the operator returns whether or not $a
> is, at that time, a collection of strings (be it an array or other
> iterable). It doesn't insure $a will stay that way - it's just a check of
> the variables status at a given moment, which is the best that can be hoped
> for in PHP.
>

That should be a function, not an operator, unless you can bring up very
good arguments to make it an operator.

Regards, Niklas

>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 2:16 PM, Rowan Collins 
wrote:

> On 25/01/2018 18:56, Michael Morris wrote:
>
>> Ok, let's stay on topic please.
>> This RFC discussion is about an operator or family of functions to verify
>> that a given $var is a collection.  Objects which enforce collection
>> integrity is a tangential but whole other topic outside the scope of what
>> I
>> proposed in the first post.
>>
>
>
> Well, it's more convergent than tangential: if Derick's "generics-lite"
> were implemented, the desire for a collectionof operator might be lower,
> because people would "$foo instanceof Collection" instead.
>

Yes, but given what has been said on the issue by the senior maintainers,
the chances for Derrick's "generics lite" counter-proposal ever seeing the
light of day are somewhere between 0, null, false and empty string.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins 
wrote:

> On 25/01/2018 14:52, Derick Rethans wrote:
>
>> IMO, it makes a lot more sense to check integrity when creating the
>> "array" structure. Instead, I would suggest to add a native Collection
>> type, that takes a "type" as argument. They aren't quite full generics,
>> but it does 1. fix something; 2. isn't really complicated.
>>
>> What I am suggesting is to add a new syntax "Collection<$type>",
>> mimicking a class, but having a type as "argument":
>>
>> $a = new Collection;
>>
>
> So would I be right in thinking this would mean adding basic support for
> generics to the engine, but not letting new ones be defined in userland?
> So, a bit like how internal or extension classes have the ability to do
> more overloading of casts and operators than userland classes?
>
> If so, I like the concept, but wonder whether the parts of the
> implementation it would need are the easy parts of the hard ones. I guess
> not being able to inherit from the generic would get rid of a bunch of
> complexity, but don't really know where else the challenge lies.
>

He's getting the syntax from Java.  Java collections allow you to specify
the type they are constrained to in <> after the class name.  Type Script
does something similar.  The problem is that Java already has the policing
mechanics present in the runtime to police insertions into the collection
and guarantee they are of the correct type.  PHP has no such mechanism in
place and in previous discussion threads the primary maintainers have
underscored that adding such is highly difficult.

It is also completely tangential to and a distraction from what I propose
and would like to focus on here.  Regardless of whether PHP ever gets a
core class or construct for type uniform collections, the ability to verify
that variables are a "collection of something" will remain.  That is the
issue I want to discuss and address here - verifying that existing
variables are a given collection type, not debating pie-in-the-sky, may
never be implementable classes that self insure their own integrity.

So, given `$a collectionof string` the operator returns whether or not $a
is, at that time, a collection of strings (be it an array or other
iterable). It doesn't insure $a will stay that way - it's just a check of
the variables status at a given moment, which is the best that can be hoped
for in PHP.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Rowan Collins]

On 25/01/2018 18:56, Michael Morris wrote:

Ok, let's stay on topic please.
This RFC discussion is about an operator or family of functions to verify
that a given $var is a collection.  Objects which enforce collection
integrity is a tangential but whole other topic outside the scope of what I
proposed in the first post.



Well, it's more convergent than tangential: if Derick's "generics-lite" 
were implemented, the desire for a collectionof operator might be lower, 
because people would "$foo instanceof Collection" instead.


That said, the two don't cover all the same use cases, but it's useful 
to ask the hypothetical question "if we already had generics, would we 
still be keen to add the collectionof operator?"


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Rowan Collins]

On 25/01/2018 14:52, Derick Rethans wrote:

IMO, it makes a lot more sense to check integrity when creating the
"array" structure. Instead, I would suggest to add a native Collection
type, that takes a "type" as argument. They aren't quite full generics,
but it does 1. fix something; 2. isn't really complicated.

What I am suggesting is to add a new syntax "Collection<$type>",
mimicking a class, but having a type as "argument":

$a = new Collection;


So would I be right in thinking this would mean adding basic support for 
generics to the engine, but not letting new ones be defined in userland? 
So, a bit like how internal or extension classes have the ability to do 
more overloading of casts and operators than userland classes?


If so, I like the concept, but wonder whether the parts of the 
implementation it would need are the easy parts of the hard ones. I 
guess not being able to inherit from the generic would get rid of a 
bunch of complexity, but don't really know where else the challenge lies.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 10:14 AM, Bishop Bettini  wrote:

>
> Agreed, and we can get *almost* there today with:
>
> $collection = collection_of('is_int', [ 1, 2 ]);
>

Ok, let's stay on topic please.

This RFC discussion is about an operator or family of functions to verify
that a given $var is a collection.  Objects which enforce collection
integrity is a tangential but whole other topic outside the scope of what I
proposed in the first post.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Andreas Hennings]

I will not

On 22 January 2018 at 22:11, Stanislav Malyshev  wrote:
> Hi!
>
>> I want to see strict typing as an option, not a requirement.
>
> You seem to be under impression that this somehow makes things easier.
> It does not. To explain: let's say you design a strictly typed language,
> like Java. The compiler knows which variable is of which type at every
> point, and if it's not clear for some reason, it errors out. You can
> build a compiler on top of those assumptions.
> Now let's say you design a loosely typed language, like Javascript. The
> compiler knows variables have no types, only values have it, and builds
> on top of that (as in, it doesn't need to implement type tracking for
> variables).
> Now, you come in and say - let's make the compiler have *both*
> assumptions - that sometimes it's strict and sometimes it's not.
> Sometimes you need to track variable types and sometimes you don't.
> Sometimes you have type information and can rely on it, and sometimes
> you don't and have to type-juggle.
> Do you really think this just made things *easier*? To implement both
> Java and Javascript inside the same compiler, with radically different
> types of assumption? If you have desire to answer "yes", then a) please
> believe me it is not true b) please try to implement a couple of
> compilers and see how easy it is.

I do not doubt that it would be a lot of work, possibly so much that
it becomes unrealistic.

There are languages which have a number of strict types and then a
"variant" type.
https://en.wikipedia.org/wiki/Variant_type
https://msdn.microsoft.com/en-us/vba/language-reference-vba/articles/variant-data-type

In PHP, to allow a mix of strict statically typed variables and
dynamically typed variables, we could adopt such a model, where all
dynamically typed variables would have the type "variant".

The strict types would become the basic model, and the variant type
would be a special case within that model.

This does not make this any easier to implement, but it seems more
promising than seeing this as two parallel systems which have to be
maintained separately.


>
> Having two options is not even twice as harder as having one. It's much
> more. So "optional" part adds all work that needs to be done to support
> strict typing in PHP, and on top of that, you also have to add work that
> needs to be done to support cases where half of the code is typed and
> the other half is not. And this is not only code writing work - this is
> conceptual design work, testing work, documenting work, etc.
>
> Without even going to the merits of the proposal itself, it certainly
> looks to me like you are seriously underestimating what we're talking
> about, complexity-wise. I am not saying it's not possible at all - a lot
> of things are possible. It's just "it's merely an option" is exactly the
> wrong position to take.
>
>> Create a symbol table that holds the strict variables and the types they
>> are locked into.  The strict keyword pushes them onto that table, the var
>> keyword pulls them off. When an operation that cares about type occurs
>> check that table - if the var appears there than authenticate it.
>
> And now every function and code piece that works with symbol tables
> needs to be modified to account for the fact that there are two of them.
> Every lookup is now two lookups, and no idea how $$var would even work
> at all.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Ryan Pallas]

On Thu, Jan 25, 2018 at 9:21 AM, Derick Rethans  wrote:

> On Thu, 25 Jan 2018, Ryan Pallas wrote:
>
> > On Thu, Jan 25, 2018 at 7:52 AM, Derick Rethans  wrote:
> >
> > > On Wed, 24 Jan 2018, Michael Morris wrote:
> > >
> > > > Ok, here's another idea I've been mulling over. This I know is
> possible
> > > > because I've done it using user land code, specifically Drupal 8's
> > > > Assertion\Inspector class.
> > > >
> > > > https://api.drupal.org/api/drupal/core%21lib%21Drupal%
> > > 21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x
> > > >
> > > > These methods provide a means to inspect collections - arrays
> usually but
> > > > also Traversables. They fill a hole in the PHP library - the ability
> to
> > > > check collection integrity.
> > >
> > > IMO, it makes a lot more sense to check integrity when creating the
> > > "array" structure. Instead, I would suggest to add a native Collection
> > > type, that takes a "type" as argument. They aren't quite full generics,
> > > but it does 1. fix something; 2. isn't really complicated.
> > >
> > > What I am suggesting is to add a new syntax "Collection<$type>",
> > > mimicking a class, but having a type as "argument":
> > >
> > >
> > Just like to point out if it's considered a class, or takes the same
> space
> > there is likely collisions. While most collection classes on github look
> to
> > be in a namespace, there are lots that aren't. Of course github only
> gives
> > us a view of open source projects that happen to be on github.
>
> PHP owns the top-level namespace. It has always done that. It's even
> documented: http://docs.php.net/manual/en/userlandnaming.rules.php


And yet, it's a point of contention that every proposal adding to the root
namespace has faced.


>
>
> cheers,
> Derick
>
> --
> 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
>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Michael Morris]

On Thu, Jan 25, 2018 at 10:21 AM, Derick Rethans  wrote:

>
> PHP owns the top-level namespace. It has always done that. It's even
> documented: http://docs.php.net/manual/en/userlandnaming.rules.php
>
>
That doesn't stop the bellyaching when the refactoring becomes necessary.
If possible, it is best to avoid choosing a name that will cause a lot of
projects to refactor.

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Derick Rethans]

On Thu, 25 Jan 2018, Ryan Pallas wrote:

> On Thu, Jan 25, 2018 at 7:52 AM, Derick Rethans  wrote:
> 
> > On Wed, 24 Jan 2018, Michael Morris wrote:
> >
> > > Ok, here's another idea I've been mulling over. This I know is possible
> > > because I've done it using user land code, specifically Drupal 8's
> > > Assertion\Inspector class.
> > >
> > > https://api.drupal.org/api/drupal/core%21lib%21Drupal%
> > 21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x
> > >
> > > These methods provide a means to inspect collections - arrays usually but
> > > also Traversables. They fill a hole in the PHP library - the ability to
> > > check collection integrity.
> >
> > IMO, it makes a lot more sense to check integrity when creating the
> > "array" structure. Instead, I would suggest to add a native Collection
> > type, that takes a "type" as argument. They aren't quite full generics,
> > but it does 1. fix something; 2. isn't really complicated.
> >
> > What I am suggesting is to add a new syntax "Collection<$type>",
> > mimicking a class, but having a type as "argument":
> >
> >
> Just like to point out if it's considered a class, or takes the same space
> there is likely collisions. While most collection classes on github look to
> be in a namespace, there are lots that aren't. Of course github only gives
> us a view of open source projects that happen to be on github.

PHP owns the top-level namespace. It has always done that. It's even 
documented: http://docs.php.net/manual/en/userlandnaming.rules.php

cheers,
Derick

-- 
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] Collection Inspection

[Bishop Bettini]

On Thu, Jan 25, 2018 at 9:52 AM, Derick Rethans  wrote:

> On Wed, 24 Jan 2018, Michael Morris wrote:
>
> > Ok, here's another idea I've been mulling over. This I know is possible
> > because I've done it using user land code, specifically Drupal 8's
> > Assertion\Inspector class.
> >
> > https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Comp
> onent%21Assertion%21Inspector.php/class/Inspector/8.5.x
> >
> > These methods provide a means to inspect collections - arrays usually but
> > also Traversables. They fill a hole in the PHP library - the ability to
> > check collection integrity.
>
> IMO, it makes a lot more sense to check integrity when creating the
> "array" structure. Instead, I would suggest to add a native Collection
> type, that takes a "type" as argument. They aren't quite full generics,
> but it does 1. fix something; 2. isn't really complicated.
>
> What I am suggesting is to add a new syntax "Collection<$type>",
> mimicking a class, but having a type as "argument":
>
> $a = new Collection;
>
> And then $a can act as if you'd use an ArrayAccess'ed class.
> Upon each set or update, the type of the value can then be checked
> against the type.
>

Agreed, and we can get *almost* there today with:

$collection = collection_of('is_int', [ 1, 2 ]);
$collection[] = M_PI; // exception thrown

given:

function collection_of(callable $validator, $input = []) {
$collection = new class($input) extends \ArrayObject {
public function offsetSet($index, $value) {
if (($this->validator)($value)) return
parent::offsetSet($index, $value);
throw new \DomainException;
}
};
$collection->validator = $validator;
foreach ($input as $key => $value) $collection[$key] = $value;
return $collection;
}



> Consequently, this would also mean you can type hint on Collection
> instead of for example an earlier suggested array of type, where upon
> passing in the array each member was checked for its type (slow).
>

Regrettably, class_alias cannot quite work here, because the validator is
passed at run-time, so making this part of the language seems a good place
to go.

Cheers,
bishop

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Ryan Pallas]

On Thu, Jan 25, 2018 at 7:52 AM, Derick Rethans  wrote:

> On Wed, 24 Jan 2018, Michael Morris wrote:
>
> > Ok, here's another idea I've been mulling over. This I know is possible
> > because I've done it using user land code, specifically Drupal 8's
> > Assertion\Inspector class.
> >
> > https://api.drupal.org/api/drupal/core%21lib%21Drupal%
> 21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x
> >
> > These methods provide a means to inspect collections - arrays usually but
> > also Traversables. They fill a hole in the PHP library - the ability to
> > check collection integrity.
>
> IMO, it makes a lot more sense to check integrity when creating the
> "array" structure. Instead, I would suggest to add a native Collection
> type, that takes a "type" as argument. They aren't quite full generics,
> but it does 1. fix something; 2. isn't really complicated.
>
> What I am suggesting is to add a new syntax "Collection<$type>",
> mimicking a class, but having a type as "argument":
>
>
Just like to point out if it's considered a class, or takes the same space
there is likely collisions. While most collection classes on github look to
be in a namespace, there are lots that aren't. Of course github only gives
us a view of open source projects that happen to be on github.


> $a = new Collection;
>
> And then $a can act as if you'd use an ArrayAccess'ed class.
> Upon each set or update, the type of the value can then be checked
> against the type.
>
> Consequently, this would also mean you can type hint on Collection
> instead of for example an earlier suggested array of type, where upon
> passing in the array each member was checked for its type (slow).
>
> And on top of this, this could be extended to do proper generics too.
>
> cheers,
> Derick
>
> --
> 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] Collection Inspection

[Derick Rethans]

On Wed, 24 Jan 2018, Michael Morris wrote:

> Ok, here's another idea I've been mulling over. This I know is possible
> because I've done it using user land code, specifically Drupal 8's
> Assertion\Inspector class.
> 
> https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Assertion%21Inspector.php/class/Inspector/8.5.x
> 
> These methods provide a means to inspect collections - arrays usually but
> also Traversables. They fill a hole in the PHP library - the ability to
> check collection integrity.

IMO, it makes a lot more sense to check integrity when creating the 
"array" structure. Instead, I would suggest to add a native Collection 
type, that takes a "type" as argument. They aren't quite full generics, 
but it does 1. fix something; 2. isn't really complicated.

What I am suggesting is to add a new syntax "Collection<$type>", 
mimicking a class, but having a type as "argument":

$a = new Collection;

And then $a can act as if you'd use an ArrayAccess'ed class.
Upon each set or update, the type of the value can then be checked 
against the type.

Consequently, this would also mean you can type hint on Collection 
instead of for example an earlier suggested array of type, where upon 
passing in the array each member was checked for its type (slow).

And on top of this, this could be extended to do proper generics too.

cheers,
Derick

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