2015-07-14 11:05 GMT+02:00 S.A.N ua.san.a...@gmail.com:
Maybe implement getter/setter as ECMAScript 6?
class Person
{
get name ():string { return $this._name }
set name (string $value) { $this._name = $value }
}
Which was rejected some time ago. (34 vs 22 in favor):
Hi,
I like the general idea behind that proposal.
I'm not sure how you would want to implement that however (please
expand the rfc on that topic).
Do you want to give the cast syntax a special meaning if used in
connection with json_decode or add the general ability to
cast a stdClass object (as
Hi,
the proposed syntax also clashes with the new return type hints. They don't
make sense on construct, but reusing the same syntax for two different
things should be avoided if possible.
Hack implements a related approach (without most of the c++ guarantees and
benefits as it is pure syntactic
Hi,
2015-06-15 16:09 GMT+02:00 Jakub Kubíček kelerest...@gmail.com:
I think clean global namespace isn't enough argument, we can exist in
the current situation and considering the fact that most of the new
PHP applications have their own namespaces, it could probably make
more sense to
Hi,
2015-03-21 19:30 GMT+01:00 Marc Bennewitz dev@mabe.berlin:
I also had a question! Didn't you noticed it?
Am 20.03.2015 um 16:49 schrieb Marc Bennewitz:
Why not simply allow the callback to be an array, too?
Because arrays are valid callbacks. [$object, 'cb'] would call the the
'cb'
Hi,
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki yohg...@ohgaki.net:
Distinguishing array and callable is problematic.
Array callable is better to be deprecated in the long run. IMHO.
Then how would you write an callback containing an already constructed object?
$a = [$object, 'method'];
The
Hi,
2015-03-19 17:17 GMT+01:00 S.A.N ua.san.a...@gmail.com:
Then how would you write an callback containing an already constructed
object?
$a = [$object, 'method'];
The alternative is unnecessarily cumbersome:
$a = function($methodArg1, $methodArg2) use($object) { return
Hi,
2015-03-18 20:42 GMT+01:00 Lazare Inepologlou linep...@gmail.com:
However, it seems that the second form is possible to fail, and that
depends on the mode (strict or not) of the library that contains the
function a. It does not depend on the mode that I have chosen to work with.
The two
Hi,
2015-03-17 21:35 GMT+01:00 Stanislav Malyshev smalys...@gmail.com:
Or, even worse, given current tendencies, somebody submits a proposal,
couple of people say yeah good idea, then vote happens and somehow
there's 30 no votes without any explanation - and without possibility
to fix it
Hi,
2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com:
If you need to confirm the statistics, or gather more background data,
then feel free to contact me privately, off the list, and I'll get you
the account approval dates (karma and/or wiki).
While I agree that the
Hi,
2015-03-07 17:41 GMT+01:00 Kalle Sommer Nielsen ka...@php.net:
I'm a big -1 on this, while I know it returns the memory size in a C
perspective, I think it makes perfect sense to remain an alias, it
would break lots of applications for a very tiny to nothing gain.
I don't think the alias
Hi,
2015-02-13 14:45 GMT+01:00 Thomas Punt tp...@hotmail.co.uk:
Hi Francois,
From: franc...@tekwire.net
May I suggest to extend your proposal to is_null() with the same logic ?
If we were to do the same with is_null(), then would it not be best to do it
with all the is_*() functions? I
Hi,
2015-02-13 18:37 GMT+01:00 Lester Caine les...@lsces.co.uk:
On 13/02/15 17:27, Andrea Faulds wrote:
But with Marcio’s proposal, we could instead write this:
use function SomeLibrary\Math\{sin, cos, tan, degrees, radius};
Well it used to be simply ...
require
Hi,
2015-02-13 1:33 GMT+01:00 Netroby hufeng1...@gmail.com:
For Human type experience, {} is harder than () to type, see your
keyboard, can you easier type {} or easier type ()
That depends on your keyboard and its configuration and might not be
true for the majority of php users.
I hate {}
Hi,
2015-02-12 0:08 GMT+01:00 Zeev Suraski z...@zend.com:
It gives the exact same
value from an API author’s point of view.
But not from an api-consumers point of view. Without either
introducing a new set of casting/conversion rules or changing existing
behavior (**exclusively**) 'weak'
2015-01-04 18:31 GMT+01:00 Derick Rethans der...@php.net:
On Wed, 31 Dec 2014, Stanislav Malyshev wrote:
The issue is the class names though. E.g. see:
https://github.com/ralphschindler/zf2-db/blob/master/research/ColumnType/Integer.php
That's in a namespace, so it's not actually Integer,
- on-numeric strings not accepted. Numeric strings with trailing
characters are accepted, but produce a notice.
I would rather not allow fancy conversions here. Any trailing non
white spaces characters should not be allowed. I know it is not what
PHP does now in some cases but this is really
That might just work, but it's still close to currently possible code.
Why don't we use something that would currently produce a parse error
and is not as close to valid code
as the examples above?
Annotation('abc'), foo // Used as it's different from
T_SL, but it works for hack, so maybe
Just as a note: /** and /* are already treated differently by the
parser (T_DOC_COMMENT vs. T_COMMENT, this difference is also present
in opcache).
Anyway, metadata/annotations/whatever you want to call them should be
seperated from comments and verbal descriptions on a
syntax level, not just by
19 matches
Mail list logo
