hi Ralph,
Given the current discussions and the few votes, I would recommend to
move this RFC back to the discussion phase, clear the open questions
(syntax or other) again before moving back to vote.
Cheers,
On Tue, Sep 11, 2012 at 4:39 PM, Ralph Schindler
wrote:
> Hi internals!
>
> The ::clas
Hi,
On Fri, Sep 14, 2012 at 12:24 AM, Stas Malyshev wrote:
> Hi!
>
>> In the current patch, this does not work and would need another run in
>> the parser.
>
> Couldn't we just stuff it in ZEND_FETCH_CONSTANT? I'm not arguing for
> it, I'm just saying *if* we wanted it...
Even though it's not r
Hi!
> In the current patch, this does not work and would need another run in
> the parser.
Couldn't we just stuff it in ZEND_FETCH_CONSTANT? I'm not arguing for
it, I'm just saying *if* we wanted it...
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 e
The PHP development team announces the immediate availability of PHP
5.4.7 and PHP 5.3.17. These releases fix over 20 bugs. All users of PHP
are encouraged to upgrade to PHP 5.4.6, or at least 5.3.16.
Key enhancements in these releases include:
* Fixed bug #62955 (Only one directive is loaded fr
Hey Stas,
* Here are the edge cases / implementation details that need a decision:
- $variable::class (should it even be supported?)
I don't see it doing anything useful.
I generally agree.
In the current patch, this does not work and would need another run in
the parser.
- se
Hi!
> Right now, you can access static properties and methods from a
> string/object by doing $var::$foo... I would assume that this works the
> same way. That way, you can take in a string class name, or an object,
> and get the class in one shot `$obj::class` instead of
> `get_class($obj)`... Ju
Hi!
> * Here are the edge cases / implementation details that need a decision:
>
>- $variable::class (should it even be supported?)
I don't see it doing anything useful.
>- self, static, parent::class not in a class definition
>- self, static, parent::class in a method signature
>
Stas,
On Thu, Sep 13, 2012 at 4:58 PM, Stas Malyshev wrote:
> Hi!
>
> >>> I would expect $variable::class to work (like late static bindings).
>
> What this would mean? ClassName::class has a clear meaning - ClassName
> is a name of the class (possibly aliased) and class is the property of
> this
Perhaps get_class_fqn(string:ClassName) ?
Do you propose a function? Because I don't see how it can work as
function - namespace resolution is compile-time.
I personally think we should keep resolutions as much to compile time as
possible.
Your suggestion implies that we now have either a
Hi all,
I know there are few edge cases that need to be resolved. What I am
looking for in the RFC/vote is to determine if ::class (as it works in
the PoC patch) has enough acceptance for inclusion in master.
If there is not enough interest in this by the powers that be, or the
feature as c
Hi!
>>> I would expect $variable::class to work (like late static bindings).
What this would mean? ClassName::class has a clear meaning - ClassName
is a name of the class (possibly aliased) and class is the property of
this class, namely its full name. However I do not see how
$variable::class ca
Hi!
> Perhaps get_class_fqn(string:ClassName) ?
Do you propose a function? Because I don't see how it can work as
function - namespace resolution is compile-time.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runti
On 9/13/12 3:36 AM, Lars Strojny wrote:
Hi Simon,
Am 13.09.2012 um 10:34 schrieb Simon J Welsh :
[...]
I would expect $variable::class to work (like late static bindings).
[...]
Than better try the patch, as it doesn’t work now :)
But it is a good point indeed. @Ralph: what do you think?
cu
I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).
I am not a big fan of the syntax class(ShortClass\Name) as to me it
looks like a function call.
Personally, I like drawing parallels from the same languages that I
think helped shaped
On Thu, Sep 13, 2012 at 3:21 PM, Stas Malyshev wrote:
> Hi!
>
> Does anybody know who is responsible the snaps.php.net machine? It seems
> to be serving 5.4 builds under then name of php-trunk and that confuses
> people. Not only we don't have "trunk" as such since the move to git,
> people expect
Hi!
Does anybody know who is responsible the snaps.php.net machine? It seems
to be serving 5.4 builds under then name of php-trunk and that confuses
people. Not only we don't have "trunk" as such since the move to git,
people expect the latest dev build there which is master and not 5.4.
--
Stani
Hi,
Am 13.09.2012 um 16:02 schrieb Marco Pivetta :
> I don't think autoloading is needed here, since the FQCN can be resolved
> without it (exactly like with type hinting).
Has nothing to do with autoloading. It only checks if there is a use statement.
Auto-loading is triggered during call time
Hi JD,
On 13 September 2012 15:57, Jan Dolecek wrote:
> I'm not able to try it myself at the moment and it's not described in the
> RFC, so I'd like to ask:
>
> Will it invoke autoloading, if the class does not exist (yet)?
>
> I think this should be considered. If so, it's not good as it kills
I'm not able to try it myself at the moment and it's not described in the
RFC, so I'd like to ask:
Will it invoke autoloading, if the class does not exist (yet)?
I think this should be considered. If so, it's not good as it kills
lazy-loading. If not so, it we may get errors later than expected.
hi,
I wonder why you are not doing at least one RC for 5.3.17. We have
messed enough releases in the past by not doing any QA before
releasing final releases.
Do you mind to explain me why you go for final directy? We had
5.4.7RC1 and it should have given a 5.3.17RC1 as well at the same
time, as
>
> With respect to adding those algorithms for generating hashes, I'm 100%
> dead set against it.
>
Ok, I understand and agree, generating hashes for weaker algos is not a
good idea.
The point I wanted to address was forward/backward compatibility with
existing password databases that use PHPass
Nicolas:
On Thu, Sep 13, 2012 at 7:33 AM, Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Hi,
>
> What do you think about adding PHPass compatibility to the password hashing
> API ?
> We could add two new algos : PASSWORD_MD5 and PASSWORD_EXT_DES.
> That way, existing password crypted usi
Hi,
What do you think about adding PHPass compatibility to the password hashing
API ?
We could add two new algos : PASSWORD_MD5 and PASSWORD_EXT_DES.
That way, existing password crypted using phpass ($P$*, $H$*, _* prefix)
could be verified using the password hashing API.
PHPass implementation cou
Hi Dmitry,
Am 13.09.2012 um 11:12 schrieb Dmitry Stogov :
> We already have isset(), empty(), unset() that are a special purpose
> functions handled by compiler.
[...]
That’s exactly my point: these special purpose functions present themself to
the user as usual functions and set a certain exp
On Thu, Sep 13, 2012 at 11:12 AM, Dmitry Stogov wrote:
> We already have isset(), empty(), unset() that are a special purpose
> functions handled by compiler.
>
> Thanks. Dmitry.
Yes, if we communicate the right way about our feature not beeing a
true PHP function and taking isset(), empty() et a
We already have isset(), empty(), unset() that are a special purpose
functions handled by compiler.
Thanks. Dmitry.
On 09/13/2012 12:28 PM, Lars Strojny wrote:
Hi Dmitry,
Am 13.09.2012 um 10:17 schrieb Dmitry Stogov :
[...]
I think the syntax is wired.
Instead of classname::class I would pre
On Thu, Sep 13, 2012 at 10:36 AM, Lars Strojny wrote:
> Hi Simon,
>
> Am 13.09.2012 um 10:34 schrieb Simon J Welsh :
> [...]
>> I would expect $variable::class to work (like late static bindings).
> [...]
>
> Than better try the patch, as it doesn’t work now :)
>
> But it is a good point indeed. @
Hi Simon,
Am 13.09.2012 um 10:34 schrieb Simon J Welsh :
[...]
> I would expect $variable::class to work (like late static bindings).
[...]
Than better try the patch, as it doesn’t work now :)
But it is a good point indeed. @Ralph: what do you think?
cu,
Lars
--
PHP Internals - PHP Runtime Dev
On 13/09/2012, at 8:28 PM, Lars Strojny wrote:
> Hi Dmitry,
>
> Am 13.09.2012 um 10:17 schrieb Dmitry Stogov :
> [...]
>> I think the syntax is wired.
>> Instead of classname::class I would prefer something like class(classname).
>
> Wouldn’t this look too much like a function with all the impl
Hi Dmitry,
Am 13.09.2012 um 10:17 schrieb Dmitry Stogov :
[...]
> I think the syntax is wired.
> Instead of classname::class I would prefer something like class(classname).
Wouldn’t this look too much like a function with all the implications that
might cause like users expecting class($variable
@Dmitry that looks more like a function call, while (IMO) it is more
intuitive to consider it like a static property...
Marco Pivetta
http://twitter.com/Ocramius
http://marco-pivetta.com
On 13 September 2012 10:17, Dmitry Stogov wrote:
> Hi Ralph,
>
> I think the syntax is wired.
> Instead
Hi Ralph,
I think the syntax is wired.
Instead of classname::class I would prefer something like class(classname).
Thanks. Dmitry.
On 09/11/2012 06:39 PM, Ralph Schindler wrote:
Hi internals!
The ::class resolution proposal had significant discussion in April and
I've updated the patch to add
32 matches
Mail list logo
