On 6 February 2018 21:10:54 GMT+00:00, Michael Morris
wrote:
>On Tue, Feb 6, 2018 at 2:54 PM, Rowan Collins
>wrote:
>> I may be being dumb, but I don't get why you keep referring to this
>as a
>> "hidden dependency". It's a dependency, for sure, but why is it any
>more
>> "hidden" than any other
The Dependency injector isn't aware of the reference and is unable to
modify it in any way. I've been taught to avoid such dependencies, and to
avoid utility libraries which create such dependencies.
On Tue, Feb 6, 2018 at 2:54 PM, Rowan Collins
wrote:
> On 6 February 2018 20:18:07 GMT+00:00, M
On 6 February 2018 20:18:07 GMT+00:00, Michael Morris
wrote:
>I'm fine with this - I just want the inspector to be part of the
>language
>so that a hidden dependency isn't required.
I may be being dumb, but I don't get why you keep referring to this as a
"hidden dependency". It's a dependency,
On Tue, Jan 30, 2018 at 2:24 PM, Levi Morrison wrote:
> On Tue, Jan 30, 2018 at 11:13 AM, Larry Garfield
> wrote:
> > On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote:
> >> On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield >
> >>
> >> wrote:
> >> > Really, these functions would be
On Tue, Jan 30, 2018 at 11:13 AM, Larry Garfield wrote:
> On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote:
>> On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield
>>
>> wrote:
>> > Really, these functions would be useful only on arrays, period. To allow
>> > them
>> > on anything else
On Tue, Jan 30, 2018 at 12:13 PM, Larry Garfield
wrote:
> On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote:
> > On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield
> >
> > wrote:
> > > Really, these functions would be useful only on arrays, period. To
> allow
> > > them
> > > on anyt
On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote:
> On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield
>
> wrote:
> > Really, these functions would be useful only on arrays, period. To allow
> > them
> > on anything else is just dangerous, and on other iterables there are
> > better,
On 30.01.2018 at 01:46, Michael Morris wrote:
> So what about this function
>
> bool array_test(array $array [, callable $callback [, mixed $flag = 0]])
>
> Iterates over $array, passing the value of each element to $callback. If
> the callback returns true for all elements the array_test return
On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield
wrote:
>
>
> Really, these functions would be useful only on arrays, period. To allow
> them
> on anything else is just dangerous, and on other iterables there are
> better,
> more robust approaches (as discussed elsewhere in this thread).
>
> As yo
On Monday, January 29, 2018 3:35:18 PM CST Michael Morris wrote:
> On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins
>
> wrote:
> > Nor are generators the only non-rewindable iterables you need to worry
> > about, so really the only options you have are to only inspect arrays, or
> > to add a big fa
On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins
wrote:
> On 29 January 2018 19:14:43 GMT+00:00, Michael Morris
> wrote:
> > The is_callable()
> >above prevents iteration over generators, potentially consuming them
> >for no purpose.
>
> Unfortunately, it doesn't: it's not the generator definitio
On Mon, Jan 29, 2018 at 3:26 PM, Rowan Collins
wrote:
>
> Nor are generators the only non-rewindable iterables you need to worry
> about, so really the only options you have are to only inspect arrays, or
> to add a big fat warning that the function may consume your iterable (or
> enter an infini
On 29 January 2018 19:14:43 GMT+00:00, Michael Morris
wrote:
> The is_callable()
>above prevents iteration over generators, potentially consuming them
>for no purpose.
Unfortunately, it doesn't: it's not the generator definition that you'll be
passed, but the Generator object returned when you
> The more angles we approach this, the more it looks like generics, or at
> least the same basis.
Which is well outside the scope of what I'd like to see, so let's look at
form 2 in closer detail - the all functions.
bool all_array( mixed $var ) {
if (is_iterable($var) && !is_callable) {
On Friday, January 26, 2018 8:43:20 AM CST Christoph M. Becker wrote:
> On 26.01.2018 at 00:28, Larry Garfield wrote:
> > 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 c
On 26 January 2018 at 14:20, Michael Morris wrote:
> On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller wrote:
> >> >> $b instanceof SomeClass
> >> >>
> >> >> Returns true if SomeClass can be iterated and contains only strings.
> >> >>
> >> >
> >> > This would block generics with that syntax then.
On 26.01.2018 at 00:28, Larry Garfield wrote:
> 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 fin
On Thu, Jan 25, 2018 at 11:59 PM, Niklas Keller wrote:
> 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
>> > arr
On 26 January 2018 at 01:06, Michael Morris wrote:
>
> 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 ther
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 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
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
> >
> > $ar
> 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 ps
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
>
> 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 v
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 s
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 n
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
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
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
pro
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 real
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 c
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
> possib
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 be
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
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://a
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://a
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%
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 p
39 matches
Mail list logo
