> $object is not guaranteed to be an object, it could be anything (int,
> string, etc) or nothing (null). using ::class for a variable, I'd argue,
> makes for less consistency. What would the replacement be for non-object
> variables? An error, exception, or false, or string type? At least in
>
On 7 May 2015 at 16:04, Ralph Schindler wrote:
>
> 2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
>>>
>>> I'll grant you the consistency argument. I'm all for consistency, but
>> that's the ONLY valid reason you've stated.
>>
>
> Even then I think this part of the arg
2. Illogically - Bar::class valid syntax, $object::class invalid syntax.
I'll grant you the consistency argument. I'm all for consistency, but
that's the ONLY valid reason you've stated.
Even then I think this part of the argument is fairly weak. In
Bar::class, the context of Bar is alway
On Mon, Apr 27, 2015 at 10:28 AM, S.A.N wrote:
>> Why not?
>>
>
> 1. get_class($object) - looks bad and long
>
It's a function call. A pretty much self-declarative one at that.
What is "bad" about it? For that matter, what's "long" about it? It's
pretty short as PHP function calls go.
> 2. Illo
On 27 April 2015 at 19:39, Rowan Collins wrote:
> Marco Pivetta wrote on 27/04/2015 18:25:
>
>> On 27 April 2015 at 16:35, Anthony Ferrara wrote:
>>
>> On Mon, Apr 27, 2015 at 7:18 AM, S.A.N wrote:
>>>
Now this code causes an error PHP 5-7.
PHP Parse:
Syntax error, unexpect
Marco Pivetta wrote on 27/04/2015 18:25:
On 27 April 2015 at 16:35, Anthony Ferrara wrote:
On Mon, Apr 27, 2015 at 7:18 AM, S.A.N wrote:
Now this code causes an error PHP 5-7.
PHP Parse:
Syntax error, unexpected 'class' (T_CLASS), expecting identifier
(T_STRING) or variable (T_VARIABLE) or
Hi!
> 1. get_class($object) - looks bad and long
There's nothing bad in calling functions. Functions are part of PHP and
are completely OK.
> 2. Illogically - Bar::class valid syntax, $object::class invalid
> syntax. 3. Function call get_class($object) is slower
Unless you code is doing get_cla
2015-04-27 20:33 GMT+03:00 Nicolas Grekas :
>
>> Systems that depend on `get_class()` a lot would
>
> An for non-objects types, I suggest that $var::class could return the same
> as get_type($var). That would allow saving ref mismatches when $var is a
> ref.
+1
--
PHP Internals - PHP Runtime Dev
> Systems that depend on `get_class()` a lot would
An for non-objects types, I suggest that $var::class could return the same
as get_type($var). That would allow saving ref mismatches when $var is a
ref.
> Why not?
>
> Seriously, why not? ::class was added because there was no easy way to
> get from the symbol class name to the string representation of it (you
> couldn't pass it to a function, etc since it would look like a
> constant). So ::class is a purely compile time construct to turn a
> lite
On 27 April 2015 at 16:35, Anthony Ferrara wrote:
> On Mon, Apr 27, 2015 at 7:18 AM, S.A.N wrote:
> > Now this code causes an error PHP 5-7.
> >
> > PHP Parse:
> > Syntax error, unexpected 'class' (T_CLASS), expecting identifier
> > (T_STRING) or variable (T_VARIABLE) or '{' or '$'
> >
> > Do no
On Mon, Apr 27, 2015 at 7:18 AM, S.A.N wrote:
> Now this code causes an error PHP 5-7.
>
> PHP Parse:
> Syntax error, unexpected 'class' (T_CLASS), expecting identifier
> (T_STRING) or variable (T_VARIABLE) or '{' or '$'
>
> Do not want to use get_class($object)
Why not?
Seriously, why not? ::cl
Now this code causes an error PHP 5-7.
PHP Parse:
Syntax error, unexpected 'class' (T_CLASS), expecting identifier
(T_STRING) or variable (T_VARIABLE) or '{' or '$'
Do not want to use get_class($object)
Thank.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
13 matches
Mail list logo
