Hi!
> If it could return `string`, that'd be super useful!
Would it? There's no class "string". So for all purposes other than
printing out, that would be a pretty big footgun.
> We have tons of lines of code that look like: is_object($foo) ?
> get_class($foo) : gettype($foo)
> Getting rid of
On Tue, 14 Jan 2020 at 19:05, Ralph Schindler
wrote:
>
>
> > just return $string, to be consistent with usual behavior of
> > "::CONST_NAME", which allows objects and class names on the left hand
> side.
>
> Having given it more thought, it seems like like $string::class should
> be more aligned
just return $string, to be consistent with usual behavior of
"::CONST_NAME", which allows objects and class names on the left hand side.
Having given it more thought, it seems like like $string::class should
be more aligned with get_class($string), which at current throws a PHP
Warning
On 10/01/2020 17:29, Larry Garfield wrote:
But having some kind of working way to reference a function that doesn't
involve concatenating a string onto a namespace constant would be*super* nice.
Whether it's called ::func or ::nameof I don't much care.
Viz, replace this:
$func =
On Thu, Jan 9, 2020, at 6:10 PM, Marcio Almada wrote:
> Em qui., 9 de jan. de 2020 às 20:57, Mike Schinkel
> escreveu:
> >
> > > On Jan 9, 2020, at 6:53 PM, Marcio Almada wrote:
> > >
> > > Because we would be expanding a construct that already looks
> > > inappropriate from a purely
> > >
Hi,
On Thu, Jan 9, 2020 at 10:02 PM Kalle Sommer Nielsen wrote:
>
> [...]
>
> use Interfaces;
> if(!$object instanceof Interfaces\MyInterface)
> {
> // Notice the ! is right associative and instanceof is non
> associative, hence the lack of parantheses
> }
Sorry for off-topic but that comment
Em qui., 9 de jan. de 2020 às 20:57, Mike Schinkel
escreveu:
>
> > On Jan 9, 2020, at 6:53 PM, Marcio Almada wrote:
> >
> > Because we would be expanding a construct that already looks
> > inappropriate from a purely
> > semantic POV with aliases that also would allow inappropriate usage
> >
> On Jan 9, 2020, at 6:53 PM, Marcio Almada wrote:
>
> Because we would be expanding a construct that already looks
> inappropriate from a purely
> semantic POV with aliases that also would allow inappropriate usage
> `some_function::interface`.
> I'd rather have a generally unsatisfying
>
> Hey Marco,
>
> > On Jan 9, 2020, at 5:04 PM, Marcio Almada wrote:
> >
> > Regarding the inclusion of new keywords with similar behavior of `:class`:
> >
> > Would `Interfaces\FooInterface::trait` or `Traits\FooTrait::interface`
> > cause a run time error? If I'm not mistaken `::class` can't
Hey Marco,
> On Jan 9, 2020, at 5:04 PM, Marcio Almada wrote:
>
> Regarding the inclusion of new keywords with similar behavior of `:class`:
>
> Would `Interfaces\FooInterface::trait` or `Traits\FooTrait::interface`
> cause a run time error? If I'm not mistaken `::class` can't trigger
> error
> On Jan 9, 2020, at 5:30 PM, Kalle Sommer Nielsen wrote:
>
> I cannot see any benefits to adding the ::trait syntax (nor the ::interface)
> one
> besides some OCD issue that you are using ::class on an instance or name
> of something that technically is not a class, like in your below
>
Den tor. 9. jan. 2020 kl. 23.30 skrev Mike Schinkel :
>
> > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel :
> >
> > Traits are compiler assisted code copy/paste and not contracts (unlike
> > interfaces), so there is no gain in having ::trait.
>
> It can already be referring to using ::class
About the proposal itself of allowing `($expression)::class`, I'd be in favor.
>
> > Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel :
> >
> > Traits are compiler assisted code copy/paste and not contracts (unlike
> > interfaces), so there is no gain in having ::trait.
>
> It can already be
> Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel :
>
> Traits are compiler assisted code copy/paste and not contracts (unlike
> interfaces), so there is no gain in having ::trait.
It can already be referring to using ::class so it makes little sense to
disallow ::trait unless there is a
Moi
Den tor. 9. jan. 2020 kl. 22.41 skrev Mike Schinkel :
>
> > On Jan 9, 2020, at 3:29 PM, Ralph Schindler
> > wrote:How would you get the right semantics out of $object::interface, or
> > $object::trait, and/or do you have an example of what you're expecting?
>
> Sorry, I was only thinking
On Thu, Jan 9, 2020 at 9:49 PM Nicolas Grekas
wrote:
>
> > $fooClass = Foo::class;
>> > echo $foo::class; // TypeError b/c string?
>>
>> Yes, at least per the current proposal. Whether to allow this is listed as
>> an open question.
>>
>
> I missed that part!
>
> If it could return
> > $fooClass = Foo::class;
> > echo $foo::class; // TypeError b/c string?
>
> Yes, at least per the current proposal. Whether to allow this is listed as
> an open question.
>
I missed that part!
If it could return `string`, that'd be super useful!
We have tons of lines of code that
On Thu, Jan 9, 2020 at 3:28 PM Ralph Schindler
wrote:
>
> > Another small RFC, to allow $object::class syntax:
> >
> > https://wiki.php.net/rfc/class_name_literal_on_object
>
> Hi Nikita,
>
> Glad to see enhancements to ::class. Open questions, given:
>
>
> class Foo {}
>
> $foo = new
> On Jan 9, 2020, at 3:29 PM, Ralph Schindler
> wrote:How would you get the right semantics out of $object::interface, or
> $object::trait, and/or do you have an example of what you're expecting?
Sorry, I was only thinking about using it on Interface and Trait names, not on
objects.
I have a
Along those lines, is there any consideration of adding ::interface and
::trait, where applicable?
How would this be applicable?
In the context of variables, an object can be only of a single class
type, whereas it can be an *instanceof* multiple interfaces (or an
extension of other
> On Jan 9, 2020, at 5:27 AM, Nikita Popov wrote:
>
> Hi internals,
>
> Another small RFC, to allow $object::class syntax:
+1
Along those lines, is there any consideration of adding ::interface and
::trait, where applicable?
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To
Another small RFC, to allow $object::class syntax:
https://wiki.php.net/rfc/class_name_literal_on_object
Hi Nikita,
Glad to see enhancements to ::class. Open questions, given:
class Foo {}
$foo = new Foo;
echo $foo::class; // Foo
$fooClass = Foo::class;
echo
Hi internals,
Another small RFC, to allow $object::class syntax:
https://wiki.php.net/rfc/class_name_literal_on_object
Regards,
Nikita
23 matches
Mail list logo
