> On May 23, 2024, at 1:20 PM, Tim Düsterhus wrote:
>
> Hi
>
> On 5/22/24 02:48, Aaron Piotrowski wrote:
>> Perhaps not as clean and easy as the functionality being built-in, but it
>> gets the job done.
>
> I would suggest to use the built-in functi
_dump(ExampleEnum::from('ONE'));
var_dump(ExampleEnum::from('FOUR'));
```
Perhaps not as clean and easy as the functionality being built-in, but it gets
the job done. :-D
Aaron Piotrowski
accomplish this, such as a ref
object like
https://github.com/azjezz/psl/blob/21bf0cd3d6d6055fc88541e9b24f3140bd179b2d/src/Psl/Ref.php,
but a weak-ref to $this would certainly be more convenient.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
mp/blob/27219ddbc0bbc3fd0db4d7380eaed6489c7291ed/lib/functions.php#L135
<https://github.com/amphp/amp/blob/27219ddbc0bbc3fd0db4d7380eaed6489c7291ed/lib/functions.php#L135>
I agree, it is a bit unpleasant and looks like a hack. I would welcome an
isAnonymous() method.
Cheers,
Aaron Piotrowski
/pull/7155
Nothing has functionally changed about the method, only the name.
Fiber::current() is another possibility, but was not chosen because it may be
conflated with Iterator::current().
Does anyone object to this rename? Shall we have a vote or is that not
necessary?
Cheers,
Aaron Piotr
On May 14, 2021, at 7:36 PM, Larry Garfield wrote:
>
> On Fri, May 14, 2021, at 7:20 PM, Aaron Piotrowski wrote:
>>
>>> On May 14, 2021, at 7:00 PM, Larry Garfield wrote:
>>>
>>> Is that actually going to come up? Given that PHP functions (at least
>
with args bound to all four
params: `fourParams(1, 2, 3, 4, ?)`.
What would error is `fourParams(1, 3, ?, ?)`, as the second ? is meaningless.
I think you've convinced me that one-for-one matching on ? is burdensome, but
the above is a happy medium perhaps?
Cheers,
Aaron Piotrowski
--
PHP
> On May 14, 2021, at 6:09 PM, Paul Crovella wrote:
>
> On Fri, May 14, 2021 at 2:49 PM Aaron Piotrowski wrote:
>>
>> Consider `function foo(int $x, int $y, int $z) {}` with a partial defined as
>> `$partial = foo(?, 42)`.
>>
>> If the partial is c
rwarded to `$z` or
should the call error as providing too few arguments? Or perhaps should the
partial declaration should error, as it should have been `foo(?, 42, ?)` or
`foo(?, 42, ...?) so the partial provided all required arguments to foo.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP R
several years ago when I started compiling PHP
myself and was confused why `php -a` broke. An error message would have saved
me some time. So yes, please, merge it.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
n object seems like the correct approach.
>
> One thing I'm not 100% clear on from the RFC, does this also deprecate
> random_int()/random_bytes()? Those are (AFAIK) unseeded, so they seem like
> they'd continue to serve their current purpose, but it's not clear fro
ially chose `noreturn` simply because I
was familiar with the name from C and didn't have a strong opinion. However, I
agree that `noreturn` is a poor choice for reuse as a bottom type, so I changed
my vote to `never`.
Cheers,
Aaron Piotrowski
> On Mar 19, 2021, at 5:47 PM, Levi Morrison
> wrote:
>
> On Fri, Mar 19, 2021 at 3:54 PM Niklas Keller <mailto:m...@kelunik.com>> wrote:
>>
>> Hey Levi,
>>
>>> On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski wrote:
>>>>
>
> On Mar 12, 2021, at 4:36 PM, Christoph M. Becker wrote:
>
> On 12.03.2021 at 23:04, Michael Wallner wrote:
>
>> Thank you, and everyone involved, for your effort.
>>
>> On 08/03/2021 20.40, Aaron Piotrowski wrote:
>>> Greetings everyone!
>>
PI provided by PHP for fibers, allowing it to drop the
boost dependency.
This leads me to believe my proposal would be mutually beneficial to both your
extension and the wider PHP community that could use fibers outside of your
framework or Swoole.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP
$i) {
echo $result, "\n";
$result = $fiber->resume();
}
echo "Generated ", $i, " numbers before generating zero.\n";
```
This short script works just as expected, cool! :-D
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> On Mar 11, 2021, at 10:41 AM, Ben Ramsey wrote:
>
>> On Mar 11, 2021, at 10:29, Aaron Piotrowski wrote:
>>
>> There is not an internal API to create fibers at this time. However, I
>> planned to collaborate with other internals developers to add this API (a
able to
PHP extensions.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
not average PHP users, we
> believe there would be little effect to the community to take this step.
>
> Cheers,
> Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
Hi everyone!
I’m concerned
all the tools for fantastic, clear, intuitive user space
async code. This is the one missing piece.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
l, I do
not condone sending emails to people privately off list asking them to vote in
a particular way.
For clarification to those that may have not received the email in question, I
did not send the email nor did I request that it be sent.
Thanks,
Aaron Piotrowski
--
PHP Internals - PHP Runt
ant to be a lightweight implementation to enable user
space green-threads/coroutines. I would love to see more async tools in PHP,
but that will require much more work. This is meant to be a first step toward
that eventual goal, without conflicting with or restricting future additions.
Cheers,
ibers can certainly be done if the need
arises.
- Being marked experimental: I was hoping this would be a good compromise
between allowing people to experiment with fibers and providing the ability to
make minor BC breaks if the need arose. I realize this is generally not the PHP
way, howev
> On Mar 8, 2021, at 1:40 PM, Aaron Piotrowski wrote:
>
> Greetings everyone!
>
> The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers
> <https://wiki.php.net/rfc/fibers>
>
> Voting will run through March 22nd.
>
> Cheers,
> Aaron Pi
Greetings everyone!
The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers
<https://wiki.php.net/rfc/fibers>
Voting will run through March 22nd.
Cheers,
Aaron Piotrowski
voting on the RFC next week Monday.
If you have any questions or concerns, please do raise them now, as it’s always
more difficult to address these once voting has started.
I feel this feature deserves a lot of time to merge and test if it is to be
included in 8.1, so I’d like to move forward
> On Feb 3, 2021, at 11:32 AM, Aaron Piotrowski wrote:
>
>
>> On Jan 31, 2021, at 11:29 AM, Levi Morrison via internals
>> wrote:
>>
>> I think it would probably be advantageous to have an observer that
>> alerts interested parties when the fiber swit
> On Feb 12, 2021, at 4:05 PM, Aaron Piotrowski wrote:
>
> The Fiber API would conflict or prevent async / await from being added to PHP
> in the future. The two APIs can coexist and serve different purposes.
>
While probably obvious from the rest of the context of the ema
> On Feb 12, 2021, at 3:47 PM, Mark Randall wrote:
>
> On 12/02/2021 21:40, Aaron Piotrowski wrote:
>> I would like to open voting for this RFC around the beginning of March, so
>> please review the minimal API and provide any feedback soon.
>
> Removing the sched
> On Dec 17, 2020, at 10:30 AM, Aaron Piotrowski wrote:
>
> Hello everyone!
>
> I would like to introduce an RFC for adding full-stack fibers to PHP:
> https://wiki.php.net/rfc/fibers
>
> Fibers are primarily used to implement green-threads or coroutines for
> a
d.
Since FiberScheduler internally is just another fiber, there’s nothing really
special done to switch to a fiber scheduler. Requiring suspending to a
scheduler rather than an arbitrary fiber prevents users from attempting to
switch to an already running fiber.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
vi,
Yes, I agree and will look at implementing an observer API.
Cheers,
Aaron Piotrowski
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> <https://www.php.net/unsub.php>
had issues when trying to implement this in the
extension during shutdown due to stacks being freed. Something I think can be
addressed if adding to core with the help of someone more familiar with how
references to these stacks are kept and what should be modified in the
functions generating backtraces.
om/amphp/amp/tree/v3/examples/pipeline or in react-fiber
https://github.com/trowski/react-fiber/tree/master/examples where the Fiber API
is handled by the library rather than “application” code.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
't hesitate to ask.
Cheers!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
> On Dec 21, 2020, at 4:33 PM, Mike Schinkel wrote:
>
>> On Dec 17, 2020, at 11:30 AM, Aaron Piotrowski wrote:
>>
>> Hello everyone!
>>
>> I would like to introduce an RFC for adding full-stack fibers to PHP:
>> https://wiki.php.net/rfc/fibers
>
eed to
be declared using `async` and return an Awaitable. Your example declares
`async_task()` as async, while a similar function using the proposed fiber API
would not need to change the function declaration to use `Fiber::suspend()`.
There's an example in the RFC using `Amp\delay()` that is
think fibers offer a distinct advantage to using promise for
async code.
Cheers,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
complex feature. The RFC contains many examples and links to code
using fibers to help explain and demonstrate what is possible, however I’m
certain many more questions and concerns will arise. Looking forward to
feedback and discussion.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development
d classes probably should be used in the future, but for
logically grouped classes (such as DOM), extensions, etc.
Attributes are a basic language feature, and therefore should live in the
global namespace the same way as Throwable, Iterator, Countable, etc.
I did not want naming to be a blocker on the
ub.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
>>
>> <https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916>
>>>
>>> No catch block would catch it, because it wouldn't implement Throwable
>> nor extend Exception or Error.
>>>
>>
>> Very elegant solution!
>>
>> PS: Naming things is hard, but `Throwable` could not have been a
>> better choice in retrospect. Ty ;)
Thanks! Every once-in-a-while I manage to name something correctly!
>>
>>> Aaron Piotrowski
>>>
>>
>> Márcio
Aaron Piotrowski
ace, which is rather odd. It still allows
> explicitly catching the exit.
>
> 3. Introducing a function like catch_exit(function() { ... }). This would
> still allow catching exits (for phpunit + daemon use cases), but the fact
> that this is actually implemented based on an exception would be hidden and
> the only way to catch the exit is through this function.
>
> 4. Don't allow catching exits at all. In this case the exception is just an
> implementation detail.
>
> Nikita
+1 for option 3.
EngineShutdown could be a special exception to the engine, being handled like
an exception internally, but not implement Throwable and therefore not an
exception from user-land's point-of-view.
EngineShutdown could be added to the list of "throwables", but forbid
instigation in user-land.
https://github.com/php/php-src/blob/db233501ff9d56765ef4a870b777a643c2136711/Zend/zend_exceptions.c#L909-L916
No catch block would catch it, because it wouldn't implement Throwable nor
extend Exception or Error.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
act.
> What keywords do you like for fibers and why do we need them?
> Why do we need Promise/Awaitable in the core?
> If you have concrete solution (just API), lets discuss it in separate email
> thread.
Niklas and/or I will put something together and start a new thread.
Regards,
Aaron Piotrowski
er unexpected
behaviors. I think PHP is absolutely ready to shine in environments outside of
per-request SAPIs. Core support for async is one of the few ingredients missing.
Aaron Piotrowski
[1] https://github.com/amphp/green-thread
[2] https://github.com/am
ed from methods, named functions, etc with less boilerplate.
Thanks to you and Dmitry for working on this!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
oloading and further optimizations.
+1
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
;ed on a constructive comment, or
too little is filtered and there's still noise from those replying to the
filtered user. Banning or suspension should not be used lightly, but I think
we've reached a point where it is warranted.
I think a simple PHP CoC similar to the JS Foundation [1]
> On Jun 7, 2017, at 6:31 AM, Derick Rethans wrote:
>
> I voted no because of the BC break.
>
Changed my vote to no for the same reason. The subtly of the BC would make bugs
potentially difficult to discern. Would happily vote yes again for an RFC
targeting 8.
Aaron Piotr
confusing when something like `|| => $x ** 2` may be
more confusing, so point taken. Regardless, I still prefer the visual
difference since the auto-capture behavior is so different from other functions.
Cheers!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Feb 3, 2017, at 9:06 PM, Stephen Reay wrote:
>
>
>> On 4 Feb 2017, at 07:25, Aaron Piotrowski wrote:
>>
>> $callback = |int|float $x| => $x ** 2;
>
> Forget the parser, you're giving my eyes diabetes trying to read that.
I absolutely agree th
nd | is not followed by =>, the parser should be able to discern
that a union type is being used.
Regards, Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Below are a couple of real-world single line closures using the proposed syntax:
[1] Loop::defer(|| => ($this->when)($exception, $value));
[2] $this->watcher = Loop::delay($time, || => $this->resolve($value));
IMHO, the reduced boilerplate required makes it easier to discern what
Name()` method. The rest of the RFC was not
implemented. This should be completely BC while allowing future types like
unions or callables. See some discussion here:
https://github.com/php/php-src/pull/2068
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
k of, and it would break existing code.
It sounds like you'd prefer the ? was not prepended to the string as well, is
that correct? Again it sounds like it would be better to use methods other than
__toString(). I understand __toString() was the only way to get the type name
before, but n
llable types just created
another headache for you. :-(
Aaron Piotrowski
[1] https://github.com/php/php-src/pull/2068#issuecomment-239983716
(Forgot to CC internals again... ugh)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
pe::__toString() will return
"?\Type\Name" or without the changes I committed it would return "?Type\Name".
If you need the type name without the leading ? or \, use
ReflectionNamedType::getName().
It would be nice to have no BC breaks, but right now I'm not seeing a
.
If anyone has objections to these changes, please let me know.
Thanks!
Aaron Piotrowski
[1]
http://git.php.net/?p=php-src.git;a=commitdiff;h=20fdd47921f423728b409fd0ae0106dab9c34573
[2] http://news.php.net/php.internals/94452
[3] https://wiki.php.net/rfc/reflectiontypeimprovements
[4] https
Hi Levi,
> On Jul 9, 2016, at 10:12 AM, Levi Morrison wrote:
>
> On Sat, Jul 9, 2016 at 8:16 AM, Aaron Piotrowski <mailto:aa...@trowski.com>> wrote:
>>
>>
>> Additionally, I propose adding a getName() method to ReflectionType that
>> return
ility. Casting should
not be required to get information from an object, but currently this is the
only way to get the type name from ReflectionType. Most other reflection
classes include a getName() method, this seems to have been an oversight.
Joe and Davey, what are your thoughts on this?
at it will still work, but stdClass would not
> be instanceof Iterable?
That code will continue to work just as it always has. stdClass will not be
accepted by the iterable type.
Aaron Piotrowski
was a reasonable and simple requirement to allow an
instance of stdClass to be iterable. I do not think stdClass was designed for
iteration, but rather is just used this way because of the behavior of foreach.
I'd prefer json_decode() to return an iterable object... maybe an RFC for
another day.
Aaron Piotrowski
er to take a look at the
changes made to ensure I have not missed cleaning up cases where bail-out
behavior was being relied upon.
Cheers!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ting actually opens. There seems to be a pattern
of issues with RFCs not being discussed until voting has begun. The pre-vote
phase could replace one week of the discussion period, so an RFC would still
only need a minimum of two weeks between announcement and voting.
Cheers!
Aaron Piotrowski
--
to modify overall
error handling in each extension. I would rather individual extension
maintainers make decisions on error levels.
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
om/php/php-src/pull/1942
<https://github.com/php/php-src/pull/1942>
Aaron Piotrowski
Hello,
Voting on the Iterable RFC has opened and will remain open until 7/2/16 at
11:59 GMT.
https://wiki.php.net/rfc/iterable
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
as `Iterator`
or `IteratorAggregate`, using `iterable` was about equal in performance. [6]
Overall in my opinion, the performance impact of this RFC is negligible.
Dmitry, could you take a look at the patch and do some of your own performance
checks?
Thanks!
Aaron Piotrowski
[1]
https:
Hi all,
I plan on bringing the iterable RFC (https://wiki.php.net/rfc/iterable) to a
vote in about a week, does anyone have any further feedback on this proposal?
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
/throw_error_in_extensions
PR: https://github.com/php/php-src/pull/1942
Thanks!
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/rfc/iterable
<https://wiki.php.net/rfc/iterable>
Thanks!
Aaron Piotrowski
> On Jun 1, 2016, at 3:56 PM, Rowan Collins wrote:
>
> On 01/06/2016 19:36, Aaron Piotrowski wrote:
>> While this might be considered a BC break, I can't imagine there's an actual
>> code out there relying on suppressing the warning just to call a function
>
ious reason. A function should not be called if too few
arguments are provided.
While this might be considered a BC break, I can't imagine there's an actual
code out there relying on suppressing the warning just to call a function
without enough arguments. I see no problem putting
is is somewhat off-topic of this particular RFC, since we can already
do general type-aliasing with `use`,
use SomeFoo as Foo;
perhaps similar syntax could be used for type expressions, eliminating the need
for a new keyword.
use callable(int, int): int as IntReducer;
use array | Traversable as Itera
e functions. Setting a custom error handler before calling these
functions and removing the error handler afterwards is a clunky solution. Any
proposal to remove the @ operator needs to address how functions issuing
unavoidable warnings will be changed.
Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eption($message);
}
There is no way of knowing if the stream buffer is full before calling
fwrite(), resulting in a warning and 0 being returned. IMO, just 0 should be
returned without issuing a warning.
Aaron Piotrowski
https://trowski.com
@trowski2002
--
PHP Internals - PHP Runtime Devel
avior of method and property visibility.
Interfaces should only be allowed to have public constants. Protected constants
would infer that the interface knows something about implementation, which
doesn’t make sense for an interface. I think the RFC should be updated to
remove this ambiguity.
I’m not sure if this would require the vote to be restarted, as I doubt anyone
who voted yes would now vote no with this change.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e
program is given the chance to be executed. This behavior is similar to
async/await, instead using a generator as the async function and yield as
await. There are several packages available for Icicle that implement
non-blocking I/O and concurrency (multithreading). There are no extensions
required for Icicle and no black magic – just making good use of the tools
already available.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
low at that point until the promise is resolved. Perhaps in
this way existing functions could be modified to support async/await while
maintaining the existing blocking behavior when called without the await
keyword.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
nt from a function returning int, to a function returning int|null.
I would also be in favor of throwing TypeError from zpp calls in new functions
(and quite frankly, from zpp calls in all functions, including old functions).
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t, then I think
Sammy should update his PRs to throw an Error so they can be merged before the
next beta release.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
al functions can result in an instance of Error being thrown,
particularly with declare(strict_types=1). So those looking for consistency can
be satisfied that other internal functions already can behave similarly, and
those looking to fail closed can be satisfied that an exception will be thr
> On Jul 13, 2015, at 1:56 PM, Dean Eigenmann wrote:
>
> I have updated the RFC with a new section showing the updates
>
> Sent from my iPhone
>
>> On 13 Jul 2015, at 20:47, Benjamin Eberlei wrote:
>>
>> On Mon, Jul 13, 2015 at 3:22 PM, Dean Eigenmann
>> wrote:
>>
>>> Ive just opened a new
Hi Anatol,
> On Jul 6, 2015, at 8:29 AM, Anatol Belski wrote:
>
> Hi Bob,
>
>> -Original Message-
>> From: Bob Weinand [mailto:bobw...@hotmail.com]
>> Sent: Monday, July 6, 2015 2:59 PM
>> To: Anatol Belski
>> Cc: Aaron Piotrowski; intern
troduces no functional changes, only more specific types of Errors
are thrown from conditions that were already throwing Error objects.
I was hoping this could be merged before beta 1, though I’m not sure if the
time table is too tight.
Cheers,
Aaron Piotrowski
erator IMO shouldn't be the
> recommended way to handle fundamental operations.
>
> You ideally just check if the divisor is 0 and then do the operation.
> And at that point, we should just throw the DivisionByZeroError.
>
> Honestly, a warning is just the wrong thing to us
could not be cast to ClassName). It was just a suggestion to see
what others thought because someone suggested supporting casting syntax such as
$ustring = (UString) $scalarString. I don’t really care for either method
though (__cast() or enabling casting just for UString), as they don&
hould be able to be cast to a scalar string using (string)
$ustring. If performance is a concern, UString::__toString() should cache the
result so multiple casts to the same object are quick.
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Quickly applying bug fixes.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
*)zend_string) + 16))" would be an example of not programming to the API.
> That's what a struct provides. A layer of abstraction over the offset. Hence
> it's already a level of abstraction.
>
> I'd like to urge you to not have two (used) APIs. And considering, that IMHO
> the direct accessors are much more readable than the macros and currently
> also much more widely used, I'd like to remove these 4 macros/inline
> functions.
>
> Thanks,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I’m very much in agreement with Bob on the confusion that these macros create.
Most of the source still uses zend_string->val or zend_string->len, while now a
few places now use ZSTR_VAL(zend_string) and ZSTR_LEN(zend_string). Which am I
suppose to use? Do you intend to change every occurrence of direct access to
the struct members to use the macros instead?
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
= 'Foo::';
> $callable(); // Fatal error: Uncaught Error: Call to undefined function
> Foo::()
>
> This behavior is inconsistent!
>
> Thanks
> Marc
>
Interesting, I didn’t consider that an empty method name should invoke
__callStatic(). I’ll look into fixing this sometime today or tomorrow.
Thanks,
Aaron Piotrowski
llable and the callable type-hint.
>
> There is also a PR open since April 2014 :
> https://github.com/php/php-src/pull/659
>
Actually this has already been fixed for PHP 7, see this commit:
https://github.com/php/php-src/commit/071111ecfc7ba9dabc4dfb2a068744b76540308b
Thanks,
Aaron Piotrows
Hello,
Voting for the Throwable Interface RFC has been changed to remain
open only through today at midnight EST so the patch can be
merged and tested before the next alpha release.
https://wiki.php.net/rfc/throwable-interface
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime
in
> master.
>
> Kalle, Ferenc, how do you feel about this?
>
Is changing the voting dates on the RFC to run only through tomorrow
allowed? If so, I can make that change so it can be merged this week.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing Li
> On Jun 15, 2015, at 9:53 AM, Dmitry Stogov wrote:
>
> On Mon, Jun 15, 2015 at 4:55 PM, Aaron Piotrowski <mailto:aa...@icicle.io>> wrote:
>
>>
>> On Jun 15, 2015, at 6:56 AM, Anatol Belski > <mailto:anatol@belski.net>> wrote:
>>
> On Jun 15, 2015, at 6:56 AM, Anatol Belski wrote:
>
> Hi Dmitry,
>
>> -Original Message-
>> From: Dmitry Stogov [mailto:dmi...@zend.com]
>> Sent: Monday, June 15, 2015 10:53 AM
>> To: Aaron Piotrowski
>> Cc: Anatol Belski; PHP Internals
o resolve the merge conflicts later today, so I will be
happy to take care of that.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
Resending this notification with the proper subject line.
Voting is now open on the Throwable Interface RFC:
https://wiki.php.net/rfc/throwable-interface
Voting will remain open through June 24th.
Regards,
Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To
> On Jun 10, 2015, at 7:42 PM, Yasuo Ohgaki wrote:
>
> Hi Aaron,
>
> On Thu, Jun 11, 2015 at 2:50 AM, Aaron Piotrowski <mailto:aa...@icicle.io>> wrote:
> > On Jun 10, 2015, at 12:29 PM, Christoph Becker > <mailto:cmbecke...@gmx.de>> wrote:
> >
> On Jun 10, 2015, at 12:29 PM, Christoph Becker wrote:
>
> Aaron Piotrowski wrote:
>
>> Voting is now open on the Throwable Interface RFC:
>>
>> https://wiki.php.net/rfc/throwable-interface
>
> When will the voting end? It seems to be best to
>
> On Jun 10, 2015, at 10:13 AM, Levi Morrison wrote:
>
> On Wed, Jun 10, 2015 at 9:05 AM, Aaron Piotrowski wrote:
>> Hello,
>>
>> Voting is now open on the Throwable Interface RFC:
>>
>> https://wiki.php.net/rfc/throwable-interface
>
> N
1 - 100 of 110 matches
Mail list logo
