On Tue, Nov 19, 2019, at 9:54 AM, Rowan Tommins wrote:
> Yes, I would see that as a better example. I think operator overloading in
> general makes sense when the object itself can be thought of as a
> special-case of the primitive it's emulating operators for. So in this
> case, the IsSuccessful
On Tue, 19 Nov 2019 at 17:58, Mike Schinkel wrote:
> But AFAIK no other "better" features were proposed. Do you have an
> alternate to propose for __toArray()? I am all ears.
>
It's hard to know without understanding the use cases, which is why I got
so hung up on your "consistency" argument
> On Nov 19, 2019, at 10:54 AM, Rowan Tommins wrote:
> Neither. We should discuss the advantages of the feature, the potential
> costs, and whether other features would be even better.
In concept, I agree.
But AFAIK no other "better" features were proposed. Do you have an alternate
to
On Tue, 19 Nov 2019 at 03:19, Mike Schinkel wrote:
> Should we make decisions about future language enhancements based on
> conflicting and impossible to forecast predictions, or when a significant
> subset of PHP developers see value in a feature for their use-cases *and*
> others can simply
On Mon, 18 Nov 2019 at 17:55, Mike Schinkel wrote:
>
> Yes, a team lead could require an interface be used for consistency across
> a team, which is fine, but it is not consistent across unrelated projects.
> Having worked with GoLang for a while where interfaces are not required to
> be
> On Nov 18, 2019, at 5:53 AM, Rowan Tommins wrote:
>
> On Mon, 18 Nov 2019 at 00:18, Mike Schinkel wrote:
>> Even if short, a code base littered with method names like toV5Json() or
>> getV5Array() or formatForJsonV5() is still inconsistent.
>
> Inconsistent with what?
Inconsistent with
On Mon, 18 Nov 2019 at 00:18, Mike Schinkel wrote:
> I now realize that my commenting on my experience in reviewing legacy code
> — where long names are frequently used, regardless of the fact they are not
> required — caused you to focus on the long naming comment aside and not on
> the primary
pon., 18 lis 2019 o 09:39 Peter Bowyer
napisał(a):
> On Sun, 17 Nov 2019 at 23:44, Ben Ramsey wrote:
>
> >
> > > On Nov 17, 2019, at 17:28, Mike Schinkel wrote:
> > >
> > > If we are going to open up arrays for enhancement in PHP 8 I would ask
> > that we seriously consider addressing the
vember 17, 2019 10:41 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Concept: "arrayable" pseudo type and \Arrayable
> interface
>
> Since PHP 7.1 there's the "iterable" pseudo type hint that matches "array"
> and "Traversable".
>
On Sun, 17 Nov 2019 at 23:44, Ben Ramsey wrote:
>
> > On Nov 17, 2019, at 17:28, Mike Schinkel wrote:
> >
> > If we are going to open up arrays for enhancement in PHP 8 I would ask
> that we seriously consider addressing the various differences between a
> built-in array and an instance of
> On Nov 17, 2019, at 6:51 PM, Rowan Tommins wrote:
>
> I'm not sure avoiding the name "toArray" necessarily leads to "really long
> method names" - even with extremely specific distinctions, you don't need to
> call the method "toJsonArrayForVersion5OfTheApi", just "toV5Json" or
>
On 17/11/2019 23:01, Mike Schinkel wrote:
Consider this: __toArray() is hardly a rare case where a short
name can be applied in multiple contexts. We have infinite
contexts where we need to name methods for one context that might
conflict with others, and so I have been
> On Nov 17, 2019, at 17:28, Mike Schinkel wrote:
>
> If we are going to open up arrays for enhancement in PHP 8 I would ask that
> we seriously consider addressing the various differences between a built-in
> array and an instance of ArrayObject and/or the related associated interfaces
>
> On Nov 17, 2019, at 9:41 AM, Aimeos | Norbert Sendetzky
> wrote:
>
> Since PHP 7.1 there's the "iterable" pseudo type hint that matches
> "array" and "Traversable".
>
> PHP frameworks would profit from support of an "arrayable" pseudo type
> hint that matches "array" and all objects that
> On Nov 17, 2019, at 2:27 PM, Rowan Tommins wrote:
> Well, pretty much any method that returns array *could* be called "to array",
> but not many would be good candidates for such a generic name. You might
> return an array structure to be incorporated into a JSON response, or to be
> passed
[Note: I've included the full text of the previous message as it wasn't
sent to the list.]
On 17/11/2019 18:35, Aimeos | Norbert Sendetzky wrote:
It feels like there are two alternative suggestions here. Not only do
they use the same keyword to mean different things, but "convertible to
On 17/11/2019 14:41, Aimeos | Norbert Sendetzky wrote:
PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".
...
It would be useful to implement an Arrayable interface
>>> And if necessary, we can convert them to native arrays:
>>>
>>> if( $arrayable instanceof \Arrayable ) {
>>>$arrayable = $arrayable->toArray();
>>> }
>>
>> Also the toArray() should be called when an Arrayable is cast to an array:
>> (array)$arrayable.
>>
>> And shouldn’t the toArray match
I proposed a while back adding a new magic method __toArray that would
automatically cast. I'm halfway through writing the RFC (in draft and
unpublished).
I wonder how that could tie in to this proposal. Or even be a precursor to
this.
Sent from my iPhone
> On Nov 17, 2019, at 11:10 AM,
On Sun, Nov 17, 2019 at 9:42 AM Aimeos | Norbert Sendetzky <
norb...@aimeos.com> wrote:
> Since PHP 7.1 there's the "iterable" pseudo type hint that matches
> "array" and "Traversable".
>
> PHP frameworks would profit from support of an "arrayable" pseudo type
> hint that matches "array" and all
Since PHP 7.1 there's the "iterable" pseudo type hint that matches
"array" and "Traversable".
PHP frameworks would profit from support of an "arrayable" pseudo type
hint that matches "array" and all objects that implements "Traversable",
"ArrayAccess" and "Countable".
Thus, we could pass arrays
21 matches
Mail list logo
