Re: AW: [PHP-DEV] Types on the right or on the left
2014-11-04 9:51 GMT-08:00 Stas Malyshev smalys...@sugarcrm.com: Hi! I thought it was inconsistent, but after discussions on StackOverflow, I don't think it actually is. If you specify the type once as Foo something and once as something: Foo then I don't see how there's even a place for discussions that it's inconsistent. Return types describe the return type of a function, not the type of a function. Given that in PHP functions do not have types, not being objects of the language, this seems to be argument invented just to ignore the inconsistency. Moreover, in languages where functions do have types - e.g. ML for example - the return of the function is specified in exactly the same manner as parameter type, and type of the function itself is never specified explicitly, but if needed, it is referred to with different syntax (-). See: https://en.wikipedia.org/wiki/Standard_ML Same situation with ActionScript: https://en.wikipedia.org/wiki/ActionScript both parameters and return type use : and nobody thinks that specifies type of the function - as, again, nobody ever specifies type of the function as such. In fact, I can remember no language that would specify type of the function (as opposed to parameters + returns) when declaring a function, even among languages with first class functions. Haskell does: length :: [a] - Int length [] = 0 length (_:xs) = 1 + length xs Also, it's worth bearing in mind that `public Foo function` was rejected previously. Many things were rejected previously, but the RFC does not bring any argument about it and never even mentions it as far as I can see. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Language constructs and callability
2013/7/19 Peter Cowburn petercowb...@gmail.com
On 19 July 2013 17:36, Daniel Lowrey rdlow...@gmail.com wrote:
I have a simple question about the callability of language constructs and
whether or not that's something that might change in the future.
Consider:
var_dump(is_callable('echo')); // bool(false)
var_dump(call_user_func('echo', 'foo')); // E_WARNING
echo('foo'); // foo
var_dump(is_callable('isset')); // bool(false)
var_dump(isset(1)); // E_ERROR
Obviously this behavior arises because tokens like `echo` and `isset` are
language constructs and not functions. I can see some potential benefits
for working around this. For example, say I want to filter only the NULL
elements from an array but keep the other falsy values. Recognizing
`isset` as callable would allow me to do this:
var_dump(array_filter([0, FALSE, NULL], 'isset')); // [0, FALSE]
array_filter([…], 'is_null');
That would do the opposite of what you want.
Of course, this limitation is trivial to work around with a userland
callback to check for the explicit NULL equivalency, but it would be nice
to avoid the hassle. So my question is ...
How deeply ingrained into the engine is this behavior? Is there any
chance
of language constructs ever passing the tests for callability or is that
just a pipe dream that's not worth the implementation effort?
Re: [PHP-DEV] Allow (...)-foo() expressions not only for `new`
2013/2/25 Nikita Popov nikita@gmail.com
Hi internals!
PHP 5.4 added support for expressions of the kind (new Foo)-bar(), (new
Foo)-bar and (new Foo)['bar'].
I'd like to extend this support to any expression instead of just new.
Why should be do this? Because it's just an arbitrary restriction. Removing
it would for example allow clone calls in the parens, so you could do
something like (clone $date)-modify('...'). Which - you may have already
noticed this - is more or less a replacement for the DateTimeImmutable
class that was added for 5.5 (with the nice benefit of being fully
compatible and not being an object oriented abomination :) That's just one
example, but I think there are a lot more (especially if you also consider
that it allows array dereferencing too). One further use that is of
interest to me personally is for https://github.com/nikic/scalar_objects,
so I can do calls like (foo)-bar().
Out of curiosity, will the parser blow up if we remove the requirement for
parentheses, so that things like foo-bar() would be possible?
A nice side benefit from this is that it removes a shift/reduce conflict
from the parser.
The patch for the change can be found here:
https://github.com/php/php-src/pull/291/files. It's a very simple patch,
it
basically just changes one parser rule and adjusts the allowed opp types
for some opcodes. The rest is just the vm regeneration for the new op
types.
I hope that this change is trivial enough to not require dragging it
through the whole RFC process. If there are no objections I'd commit it
sometime soon.
Thoughts?
Nikita
Re: [PHP-DEV] Allow non-variable arguments to empty()
2012/4/10 Nikita Popov nikita@googlemail.com Hey internals! Currently the empty() language construct only works on variables. You can write if (empty($array)) but not empty if (empty(getSomeArray()). The original reason for this restriction probably is that - in a way - it doesn't make sense to pass anything but a variable to empty() as you could just use the ! operator in this case. if (empty(getSomeArray())) is logically equivalent to if (!getSomeArray()). I'd like to propose to change empty() to accept arbitrary expressions. The reason is simple: Even though it is possible to write if (!getSomeArray()) with the same effect, if (empty(getSomeArray())) reads much nicer. !getSomeArray() to me somehow implies that getSomeArray() may return a bool(false) or something like that. On the other hand empty(getSomeArray()) seems naturally fit for checking for empty arrays. Another reason is that currently you get a very obscure error message if you try to use empty() on a function return value: Can't use function return value in write context. Aha. Where did I try to write to the return value?! So, what do you think? I think this is a useful simplification of the language, removing an unnecessary exception. Would it also make sense to make empty() into a library function instead of a language construct? That would not result in any BC break as far as I can see, but would allow some things that are currently impossible (e.g., a method called empty) and further simplify the language. Nikita PS: The patch is trivial: https://gist.github.com/2355274 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TSRMLS_* keywords in PHP source
Those are macros that are defined only if PHP's Thread-Safe Resource Manager is enabled at compile time; it passes in additional information needed by the TSRM. 2012/3/19 Barbu Paul Gheorghe paullik.p...@gmail.com Hello! What role does the keywords TSRMLS_CC, TSRMLS_DC, TSRMLS_D have when passed along with a argument in PHP's source? For example in this random file: http://lxr.php.net/opengrok/**xref/PHP_5_4/ext/intl/** formatter/formatter_data.chttp://lxr.php.net/opengrok/xref/PHP_5_4/ext/intl/formatter/formatter_data.c I don't even know if keyword is the right technical term for it because it's the first time I see this kind of call in C: foo(data_type variable_name keyword); -- Barbu Paul - Gheorghe Common sense is not so common - Voltaire Visit My GitHub profile to see my open-source projects - https://github.com/paullik -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
