2015-07-14 11:05 GMT+02:00 S.A.N :
> 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):
https://wiki.php.net
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 :
> 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 reserve global namespace
Hi,
2015-03-21 19:30 GMT+01:00 Marc Bennewitz :
> 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' method on the
Hi,
2015-03-19 17:17 GMT+01:00 S.A.N :
>> 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
>> $object->method($methodArg
Hi,
2015-03-19 12:51 GMT+01:00 Yasuo Ohgaki :
> 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 alternative is unneces
Hi,
2015-03-18 20:42 GMT+01:00 Lazare Inepologlou :
> 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 closures will no
Hi,
2015-03-17 20:55 GMT+01:00 Hannes Magnusson :
> 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 issue at hand was not presen
Hi,
2015-03-17 21:35 GMT+01:00 Stanislav Malyshev :
> 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 since by the tim
Hi,
2015-03-07 17:41 GMT+01:00 Kalle Sommer Nielsen :
> 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 make sense
Hi,
2015-02-13 18:37 GMT+01:00 Lester Caine :
> 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 Som
Hi,
2015-02-13 14:45 GMT+01:00 Thomas Punt :
> 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 would be more
Hi,
2015-02-13 1:33 GMT+01:00 Netroby :
> 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 {}
>
> If you like t
Hi,
2015-02-12 0:08 GMT+01:00 Zeev Suraski :
> 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' typehints may b
2015-01-04 18:31 GMT+01:00 Derick Rethans :
> 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, but
>
>> - 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 thi
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 m
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 s
19 matches
Mail list logo
