Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

type juggling and Countable using an integer: 0 == false == empty Otherwise, similar to alternative #1. 3. Or, modify Iterator to include the empty() and bool() methods (or possibly leverage the valid() method that already exists?); otherwise, similar to alternative #2. Cheers, Josh >

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

ept - does this thing resolve to true *or* false (null), yeah? Cheers, Josh ps. Added open issue of what to do with callable: https://wiki.php.net/rfc/objects-can-be-falsifiable - specifically in the context of __invoke() Added invokable RFC to RFC list. > On Nov 3, 2022, at 4:30 AM, C

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

tely feasible. Interesting use case. Haven’t used SimpleXMLElement enough to comment. Interested to hear more. > This is absolutely terrifying. Not sure if this is referring to the SimpleXMLElement reference or beyond it. :) Cheers, Josh > On Nov 2, 2022, at 2:09 PM, Marco Pivetta wrote: &

[PHP-DEV] Change email address associated with account

? Cheers, Josh

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

today, the last example is always true. You wouldn’t be able to create a guard clause for the negation: If ( $obj = Object::init($response) and $obj === false ) { // handle invalid object, which could include something like $obj->failed() } Cheers, Josh > On Sep 26, 2020, at 5:20

Re: [PHP-DEV] [VOTE] Fibers

HI Rowan, Thanks for sharing your thoughts. On Fri, Mar 19, 2021 at 7:55 PM Rowan Tommins wrote: > > On 18/03/2021 09:20, Josh Di Fabio wrote: > > "If you want to enable fibers in your application, you must be > > confident about the implementation details of

Re: [PHP-DEV] [VOTE] Fibers

On Thu, Mar 18, 2021 at 1:55 PM Guilliam Xavier wrote: > > Hi, > >> Guzzle's requestAsync() returns a promise, it does not >> interrupt/suspend the callsite. For example: >> >> // this function is not interrupted/suspended -- it will return >> synchronously >> function doSomething() { >>

Re: [PHP-DEV] [VOTE] Fibers

Hi Peter, Thanks for clarifying. On Thu, Mar 18, 2021 at 2:43 AM Peter Stalman wrote: > > On Wed, Mar 17, 2021 at 7:41 AM Josh Di Fabio wrote: >> >> Note the difference between the two. Also note how, in both of the >> above cases, the asynchronicity is explicit and th

Re: [PHP-DEV] [VOTE] Fibers

On Wed, Mar 17, 2021 at 9:06 AM Peter Stalman wrote: > > On Tue., Mar. 16, 2021, 23:49 Josh Di Fabio, wrote: >> >> Imagine for a moment that you create a library, awesome-library-x, >> which uses a PSR logger internally. You will most certainly allow that >> l

Re: [PHP-DEV] [VOTE] Fibers

Hi Peter, Thanks for the feedback! On Wed, Mar 17, 2021 at 3:02 AM Peter Stalman wrote: > > On Tue., Mar. 16, 2021, 13:58 Josh Di Fabio, wrote: >> >> Fibers will not make those issues obvious at all. The issues I'm >> describing will only crop up spontaneously

Re: [PHP-DEV] [VOTE] Fibers

Hi Larry, Thanks for the feedback. Replies inline. On Tue, Mar 16, 2021 at 8:33 PM Larry Garfield wrote: > > On Tue, Mar 16, 2021, at 1:44 PM, Josh Di Fabio wrote: > > > Perhaps we could rather make fibers *opt in* at the *callsite* > > (similar to goroutine calls) in order

Re: [PHP-DEV] [VOTE] Fibers

Hi Niklas, On Tue, Mar 16, 2021 at 8:07 PM Niklas Keller wrote: > > Hey Josh, > >> >> > This is a very valid concern to have. However, this code won't simply >> > break if executed asynchronously. >> > It only breaks if the same method (or other

Re: [PHP-DEV] [VOTE] Fibers

On Tue, Mar 16, 2021 at 6:20 PM Niklas Keller wrote: > > Hey Josh, > >> >> Apologies, this is a long one! >> >> This RFC strikes me as being very dangerous. Implicitly allowing code >> which is synchronous by design to be executed asynchronously seems >&g

Re: [PHP-DEV] [VOTE] Fibers

On Fri, Mar 12, 2021 at 10:54 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: > >>>

Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays

d without users needing to change their current mental models - do a lot of us *want* to have this ability (verify the metadata on keys of an array)?? Or is it just a fringe group of pedantic experimenters like me?? :) Cheers, Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays

keys ordered and starting at 0, - int-only keys ordered and *not* starting at 0, - int-only keys unordered, - string-only keys, and - int-or-string keys. And the automatic casting of strings to ints. Cheers, Josh

Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays

to another layer: ex. using string with specifying string details function hello(string $arg) { if (str_starts_with($arg, “wor”)) { } else { trigger_error } } Cheers, Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add is_list(mixed $value): bool to check for list-like arrays

a later date; short version: is_array and is_dict(ionary). 1. Sequential using int starting at 0 2. Non-sequential using strings for all keys 3. Standard PHP array with potential mixed keys. Cheers, Josh > On Dec 20, 2020, at 2:09 PM, tyson andre wrote: > > Hi Larry Garfield, &

Re: [PHP-DEV] Suggestion: Inconsistency: Allow array spread operator to work on string keys

ck only look at if the keys contain one that is a string, that they’re all integers (not float), that they’re all sequential?? Cheers, Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate passing null to non-nullable arguments of internal functions

_arg > <https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg> > > I started an informal discussion for this change during the 7.4 cycle > already, but decided to postpone the change at the time. For what it’s worth, you had me at more consistent (and constrained) use of “null”. Cheers, Josh

Re: [PHP-DEV] Nullsafe

i.php.net/rfc/objects-can-be-falsifiable <https://wiki.php.net/rfc/objects-can-be-falsifiable> - sounds like this thread might bring more supporters to that table/discussion. Cheers, Josh

Re: [PHP-DEV] Nullsafe

w null...at which point the world has not changed, just perceived default and desirable methods. Cheers, Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

continue going through the tutorials from Nikita and others on doing development Internals. Cheers, Josh > On Aug 30, 2020, at 9:32 AM, Josh Bruce wrote: > > Hey Tyson, > > This is great! Thank you so much, sincerely. > > Still slow goings, which is fine, we have

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

link: foreach ($arr as $key =>) Cheers, Josh

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

> > In terms of readability, I'm more likely to do > $keys = array_keys($array); > foreach($keys as $key){ Fair point. I would too. I have actually forgone even grabbing the keys and just using the loop without touching value in the body. Cheers, Josh -- PHP Intern

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

> On Sep 2, 2020, at 12:05 PM, Michael Voříšek - ČVUT FEL > wrote: > > I like "void", as "null" can be ambiguous. > > Imagine function example($a = 'default value 1', $b = 'default value 2') {} > > With "void", we can allow skipping arguments in advance to the default > pamameter value like

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

> On Sep 2, 2020, at 6:27 AM, Dik Takken wrote: > > On 02-09-2020 12:48, Olle Härstedt wrote: >> An alternative syntax would be >> >>foreach($iterable as $key => _) { ... } >> >> Using underscore as a way to signal "I don't care about this value". >> Same could be possible with list dest

Re: [PHP-DEV] Request for couple memory optimized array improvements

That’s interesting as I haven’t played with iterates and generators much. If the iterator can’t take an iterable, the idea of something like __toArray seems way more convenient: https://wiki.php.net/rfc/to-array Cheers, Josh > On Aug 31, 2020, at 4:39 PM, Michael Voříšek - ČVUT FEL >

Re: [PHP-DEV] array_reject() as counterpart of array_filter()

, Josh >> On Aug 30, 2020, at 6:55 PM, Larry Garfield wrote: >> >> On Sun, Aug 30, 2020, at 9:38 AM, David Rodrigues wrote: >> Currently we have array_filter(), but sometimes we need an inverse function >> like array_reject(). >> array_reject('is_null&#

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

() (less) or implode() (more). sum(), for this example, would be very confusing. Naming things is hard. lol Cheers, Josh ps. I don’t know the origins for some of most of the functions in the standard library, but it is fascinating from a communication perspective. > On Aug 30, 2020, at

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

> “Type system” implementation - https://github.com/8fold/php-shoop/blob/master/src/Filter/TypeAsBoolean.php <https://github.com/8fold/php-shoop/blob/master/src/Filter/TypeAsBoolean.php> Cheers, Josh > On Aug 9, 2020, at 3:59 PM, tyson andre wrote: > > Hi Josh, > > I

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

a database or some ORM, I *get* all - I’m not verifying “all pass [a predicate]”. Cheers, Josh > On Aug 29, 2020, at 6:48 PM, tyson andre wrote: > >> The “any” check is just to if anything in the iterable passes the predicate, >> yeah?? >> >> What I find mysel

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

even if the output isn’t different in most cases. example(true, true, false); example(USE_BLUE, DROP_FIRST... With names arguments in 8 we do get helped, I think. mb_case_switch had 3 flags in the beginning, now gas 6 - if I’m remembering and interpreting the docs correctly. Cheers, Josh

Re: [PHP-DEV] Proposal: Adding functions any(iterable $input, ?callable $cb = null, int $use_flags=0) and all(...)

not be completely following. Cheers, Josh > On Aug 29, 2020, at 3:39 PM, Alex wrote: > > I like it! > > What is the $use_flags parameter for? > >> On Sat, Aug 29, 2020 at 10:24 PM tyson andre >> wrote: >> Hi internals, >> The primitives any() and a

Re: [PHP-DEV] [Concept] Don't cast keys in array to int

Thanks Rowan. I can appreciate that rationale. Also let’s me in on why we might want to have an indexed array that is not necessarily sequential - but are integers. Thanks again. Cheers, Josh > On Aug 17, 2020, at 4:17 AM, Rowan Tommins wrote: > > On Mon, 17 Aug 2020 at 05:19

[PHP-DEV] [Concept] Don't cast keys in array to int

f course, casting back puts us back to an indexed array. I’ve picked up that type juggling might be a touchy point - but the focus is on why the key gets cast at all when it’s an array type. Is it to facilitate the type juggle from an object to an array?? Cheers, Josh -- PHP Internals - PHP

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

are-development/php-falsifiable-objects> 2. I agree some type of working concept should be a thing. 3. Have some other projects taking precedent, any assistance on implementation would be greatly appreciated. Cheers, Josh > On Jul 22, 2020, at 7:49 AM, Larry Garfield wrote: > > On Tue, Jul

Re: [PHP-DEV] [RFC] Import of variables

or method on a class. Cheers, Josh > On Aug 9, 2020, at 9:58 AM, David Rodrigues wrote: > > I suggests to make something like Node does: import "file.php" ($a, $b) so > $a and $b must be extracted from file.php context. All other variables > should be ignored. >

Re: [PHP-DEV] Allow two words keywords

Maybe add it to that thread?? https://externals.io/message/111218 Cheers, Josh > On Jul 30, 2020, at 4:50 AM, Deleu wrote: > > Such a nice syntax. Even better than @@ and @. I wish this could get more > attention/traction. > >> On Wed, Jul 29, 2020, 19:46 David Rodrig

Re: [PHP-DEV] Registration on wiki

mentions. Also not sure if the question changes - it’s always been the same for me. Would give credit to the person who pointed this out earlier to someone else that I happened to see and try, but I don’t remember who it was. Cheers, Josh > On Jul 28, 2020, at 12:54 AM, [ ] wrote: > &

[PHP-DEV] Re: [RFC][Discussion] Objects can be declared falsifiable

estions, and concerns! Cheers, Josh

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

> On Jul 16, 2020, at 10:28 AM, Josh Bruce wrote: > > https://wiki.php.net/rfc/objects-can-be-falsifiable > <https://wiki.php.net/rfc/objects-can-be-falsifiable> > > Updates: > > - Open issues (outstanding questions/concerns) updated > - Future scope

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

> On Jul 15, 2020, at 3:26 AM, Nikita Popov wrote: > > On Tue, Jul 14, 2020 at 5:37 PM Josh Bruce <mailto:j...@joshbruce.dev>> wrote: > New to the discussion and being this deep; so, apologies for any bumps. > Mainly questions. > > Does this only affect t

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

https://wiki.php.net/rfc/objects-can-be-falsifiable Updates: - Open issues (outstanding questions/concerns) updated - Future scope - References now have links to original copies on GitHub (still updating 0002) - will be removed if accepted a

[PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

ate it! Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declareemptiness and by extension truthiness

> On Jul 14, 2020, at 1:24 PM, Josh Bruce wrote: > > >> On Jul 13, 2020, at 12:14 PM, Christoph M. Becker wrote: >> >> On 13.07.2020 at 17:18, Josh Bruce wrote: >> >>> Re the wiki: I can edit pages now, it doesn’t look like I can create them. >

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declareemptiness and by extension truthiness

> On Jul 13, 2020, at 12:14 PM, Christoph M. Becker wrote: > > On 13.07.2020 at 17:18, Josh Bruce wrote: > >> Re the wiki: I can edit pages now, it doesn’t look like I can create them. >> There’s another thread I’ve been watching and I think I need more karma to >

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

, if I had class “String” would that still throw a reserved word violation? Cheers, Josh > On Jul 14, 2020, at 5:52 AM, Brent Roose wrote: > > Hi Nikita > > What happens to the attributes syntax if this RFC doesn't pass? > > Furthermore, I think voting against this RF

Re: [PHP-DEV] Drop warning about non-public magic methods

rement make the following impossible: class SomeClass { private function __toString() {} } $instance = new SomeClass(); $instance->__toString(); It’s one thing if PHP can always reach it, it’s a different thing if I, as the developer, can make it so others can’t. Cheers, Josh > On Jul

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

nerObject) { // I know it can give and receive messages, and is not empty } else { // I know it can give and receive messages, but is empty } I remember hearing what sounds like hyperbole but it said something like 40% of code written is guarding against null. I can totally see that being real so didn’t look much further into it. If we can guarantee that an object is that type of object - just happens to be empty, maybe we reduce or remove the need null-checks?? Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

nother thread I’ve been watching and I think I need more karma to make that a thing. I will continue working on this and if it generates enough pull then maybe I’ll be let in - I’ll also contribute where I can to start earning karma. Updated: https://bit.ly/php-0002 <https://bit.ly/php-0002> Cheers, Josh

[PHP-DEV] [CONCEPT][DISCUSSION] Allow objects to declare emptiness and by extension truthiness

t; Thanks for all the feedback so far! Definitely feels like progress. Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

to maintain consistency - but object may be an exception??). Cheers, Josh ps. Also did get registered to the wiki from a different thread conveniently happening at the same time. :)

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

cast to bool either effectively return the result of an empty check or a not-zero check - an object, if instantiated, is always true. __toBool would give us a way of saying it’s not true (it’s not empty, it's not zero, but it's not okay for some reason - maybe we need to do some follow-on configuration method calls…just making stuff up). :) Cheers, Josh

Re: [PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

> On Jul 8, 2020, at 12:54 PM, Marcio Almada wrote: > > Hello Josh, > >> Link to working draft: https://bit.ly/php-0001 <https://bit.ly/php-0001> > > From a type safety POV I'd prefer to have an interface available, the > same way we did > to the Stri

[PHP-DEV] [CONCEPT][DISCUSSION] Instance as boolean

ng the overly contrived nature of the samples and will improve those over time should interest maintain or increase. Cheers, Josh ps. If you have any feedback or information on social interactions here that might help, please do let me know, normally I would have watched for a while before putt

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

 > On Jul 7, 2020, at 3:24 PM, Rowan Tommins wrote: > >> On 07/07/2020 18:13, Josh Bruce wrote: >> Decided to put something >> together:https://github.com/joshbruce/external-project-proposals/blob/master/php-concepts/interact-with-instance-as-php.md > > > H

Re: [PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

> On Jul 6, 2020, at 11:54 AM, Marco Pivetta wrote: > > Hey Josh, > > Similar proposals were raised recently for `__toArray()`: see > https://externals.io/message/108369#108369 > > I'd endorse avoiding object-to- casts via cast operations: they are > a good so

[PHP-DEV] Proposal: A way for classes to define a response to any primitive type cast

Bool() would be of the most personal benefit - if proposal is converted to an RFC, would it be better (faster/smoother) to do one RFC for all the cast possibilities - or to have an RFC for each cast separately? Thank you for the consideration, information, and feedback. Cheers, Josh ps. Also, a

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

On Fri, Apr 12, 2019 at 4:27 PM Fabien S wrote: > > > > On 12 Apr 2019, at 16:46, Theodore Brown wrote: > > > > On Thursday, April 11, 2019 at 10:22 AM Fabien S > > wrote: > > > >> I really like the Haskell `\($x)` syntax, could someone confirm if > >> it would possible to drop the parenthesis

Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures

On Thu, Mar 14, 2019 at 7:42 PM Theodore Brown wrote: > > On Thu, March 14, 2019 10:41 AM Nikita Popov wrote: > > > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov wrote: > > > > > Hi internals, > > > > > > Motivated by the recent list comprehensions RFC, I think it's time we took > > > another loo

Re: [PHP-DEV] [RFC] Arrow functions / short closures

On Thu, Mar 14, 2019 at 3:49 PM Rowan Collins wrote: > > Is it really that important to save two key strokes per closure? > I'd say that the (probably overwhelming) majority of arrow functions have a single parameter and, in those cases, the JS syntax saves four characters, ignoring whitespace. A

[PHP-DEV] Internal LRU cache implementation

Hello internals, In my experience, LRU cache is a common pattern in userland. Each time I write one in PHP, I suspect that it would probably be much more efficient if it was implemented in C. If this is indeed a very common pattern, and it would be much more efficient implemented internally, is t

Re: [PHP-DEV] [RFC] Parameter No Type Variance

On Mon, Nov 21, 2016 at 9:40 AM Niklas Keller wrote: > Morning Internals, > > I'd like to announce a RFC to allow omitting the type declarations for > parameters in subclasses: > https://wiki.php.net/rfc/parameter-no-type-variance > > PHP doesn't currently allow variance for parameters as checkin

Re: [PHP-DEV] Countable Type Hint

On Thu, Nov 17, 2016 at 2:01 PM Craig Duncan wrote: > On 17 November 2016 at 13:50, Josh Di Fabio wrote: > > What's the benefit of such an interface? Why not simply ask for `int > $count` in your param list instead? > > > Using the example from my original email, it

Re: [PHP-DEV] Countable Type Hint

On Thu, Nov 17, 2016 at 1:00 PM Levi Morrison wrote: > On Thu, Nov 17, 2016 at 5:52 AM, Craig Duncan wrote: > > Hi everybody > > > > Following on from the recent rfc for *count()* ( > > https://wiki.php.net/rfc/counting_non_countables) and the one for > *iterable* > > (https://wiki.php.net/rfc/i

Re: [PHP-DEV] [RFC][VOTE] Object typehint

On Mon, Nov 14, 2016 at 8:54 AM Michał Brzuchalski wrote: > Hi All, > > Id' like to anounce voting reset - will end in two weeks on 28.11.2016 at > midnight and requires 2/3 majority as previously. > > There were improvements suggested by Joe Watkins and earlier by Nikita > Popov to the patch. >

Re: [PHP-DEV] [RFC] Intersection Types

On Thu, Apr 28, 2016 at 4:54 AM, Levi Morrison wrote: > Internals, > > As alluded to last week I have another RFC for improving the type > system: [intersection types][1]. > > It allows parameters to define multiple type constraints that must be > satisfied. Common combinations of our built-in typ

Re: [PHP-DEV] [RFC:generics]

On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate wrote: > Thanks for you're input everyone. > > So far, we have read some ideas for handling upper bounds, or multiple there > of. > The preferred keywords appear to be either "as" or "instanceof". > > class Foo {} > class Foo {} > > We would like t

Re: [PHP-DEV] [RFC:generics]

On Mon, Apr 18, 2016 at 10:47 AM, Josh Di Fabio wrote: > On Mon, Apr 18, 2016 at 6:20 AM, Rasmus Schultz wrote: >> Hello internals, >> >> I'd like to introduce an RFC proposing the addition of generic types >> and functions: >> >> https://wiki.php.net/

Re: [PHP-DEV] [RFC:generics]

On Mon, Apr 18, 2016 at 6:20 AM, Rasmus Schultz wrote: > Hello internals, > > I'd like to introduce an RFC proposing the addition of generic types > and functions: > > https://wiki.php.net/rfc/generics > > Ben Scholzen started this RFC as a quick draft with a few code samples > in August last year

Re: [PHP-DEV] PHP 7.0.0RC7 is available

All of you guys contributing to the core are brilliant people doing great work; as a userland developer I just want to say thanks and keep up the good work! Thank you! On Thu, Nov 12, 2015 at 1:11 PM, wrote: > Hi, > > The seventh release candidate for 7.0.0 was just released and can be > downlo

Re: [PHP-DEV] Re: Some words about the basic ideas of PHP

There have been some good points made here but I think everything which needs to be said has been said. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFE to allow dirname($foo, 2)

Great suggestion, Remi, I'd love to see this change! On Wed, Jul 22, 2015 at 7:49 PM, Sara Golemon wrote: > > On Wed, Jul 22, 2015 at 4:55 AM, Remi Collet wrote: > > See https://bugs.php.net/bug.php?id=70112 > > > I'm not inherently against it, but this really really sounds like a > job for a us

Re: [PHP-DEV] Reviving scalar type hints

See above -- relying on (or even really thinking about) this distinction is relying on implementation details which are going to change. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

On Dec 12, 2014, at 11:09 AM, Josh Watzman wrote: > On Dec 10, 2014, at 11:24 PM, Stanislav Malyshev wrote: > >>> the real-world code I've seen, it is the least confusing. (I'll see >> >> Which real-world code you are talking about? Examples please. &

Re: [PHP-DEV] [RFC] Nullsafe calls

rrences of this feature and I have yet to find a single one where the short circuit matters or not -- so maybe my recollection and intuition here are just wrong. I'll keep digging and thinking about this. Not convinced yet, but starting to feel less strongly about it. Josh -- PHP Internal

Re: [PHP-DEV] [RFC] Nullsafe calls

On Dec 10, 2014, at 4:12 PM, Christoph Becker wrote: > Josh Watzman wrote: > >> However, for a lot of failures, I don't feel that exceptions are >> appropriate. I tend to only use them for exceptional behavior -- >> usually, some failure that needs to be propaga

Re: [PHP-DEV] [RFC] Nullsafe calls

had a busy morning :) All of that said: it's not clear to me that this actually matters that much. I wasn't able to quickly find an example because the vast majority of the Hack code I have that uses this operator isn't actually affected one way or the other. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

, catching exceptions here aren't appropriate in the slightest. (Not that *throwing* them is wrong -- if you expect that object to be non-null, then throwing one is great -- my problem is with dealing with that failure by immediately catching it. See my original post for the extended ex

Re: [PHP-DEV] [RFC] Nullsafe calls

d chains are probably a bad idea, but one or two is fine in a lot of cases. But I very vehemently disagree that method chains are *always* a bad idea (i.e., the Law of Demeter) -- or basically any hard and fast rule about programming, for that matter. It can be done tastefully, and for tasteful uses this reduces a lot of boilerplate. Basically every language feature can be abused, and I don't think this one is particularly more prone to abuse than anything else. Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

ty strongly that this is the correct behavior. It may sound strange when talking about isolated examples like this, but in the real-world code I've seen, it is the least confusing. (I'll see if I can dig up a better example instead of just citing nebulous "real-world code" ;)) Josh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullsafe calls

On Dec 9, 2014, at 3:18 PM, Andrea Faulds wrote: >> On 9 Dec 2014, at 23:07, Josh Watzman wrote: >> >> Hey internals! A useful feature that Hack picked up in the last few months >> are "nullsafe calls", a way of propagating failure forward in a series of >

[PHP-DEV] [RFC] Nullsafe calls

would be a good one for PHP as well, so I'm submitting this RFC to add it -- you can see the RFC itself for a full discussion of the motivation for the feature, as well as the feature itself: https://wiki.php.net/rfc/nullsafe_calls Josh Watzman -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] [RFC] Abstract final classes

ether means you have a class that has no instances itself, and cannot be subclasses, so you can never have an object of that type. The use cases for being able to override such a class are questionable at best, as above. This really is just the combination of two existing class modifiers -- no ne

Re: [PHP-DEV] [RFC] Safe Casting Functions

On Oct 20, 2014, at 6:17 PM, Andrea Faulds wrote: >> On 21 Oct 2014, at 02:07, Josh Watzman wrote: >> >> Throwing an exception or even returning NULL seems so much better than >> returning "false" -- "false" is a boolean, not an error, and despite s

Re: [PHP-DEV] [RFC] Safe Casting Functions

On Oct 20, 2014, at 3:57 PM, Andrea Faulds wrote: > Good evening, > > I am presenting a new RFC to add a set of three functions to do validated > casts for scalar types: > > https://wiki.php.net/rfc/safe_cast > > Please read it. > > Thanks! I think this is pretty cool, but I'm really worrie

Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures

On Aug 10, 2014, at 11:20 AM, Andrea Faulds wrote: > Hi! > > Sorry for the slow response, I’ve been on holiday. No problem! > On 8 Aug 2014, at 01:32, Josh Watzman wrote: > >> The RFC goes a long way to fixing this, but one important place it misses is >>

Re: [PHP-DEV] [RFC] Closure::call and Function Referencing as Closures

[Andrea, please forward this to internals if you don't see my message appear there in a few hours; as you know, FB is working through issues sending email to internals, and though I think I know how to get it through, if it doesn't make it, please help :) Thanks!] On Aug 4, 2014, at 12:49 PM, A

Re: [PHP-DEV] About PHP NG "document lacking" argument

On 25 July 2014 16:06, Zeev Suraski wrote: > I'd prefer that over a non-vague and very public character assassination > that me and others are experiencing instead. I cannot comment on that statement but character assassination is bad either way, sure. > I'm also wondering why you're replying t

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

detail that "strict enforcement" for scalars is defined in terms of "lossless conversion" as outlined in the RFC, since that's the "PHP way" of loosely dealing with scalar types. The idea of "lossless conversion" has just never been relevant before since

Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

On 24 May 2013 10:44, Stas Malyshev wrote: > > It is rather surprising that you would expect that as a PHP programmer, > since it never worked this way in PHP, and no PHP code works this way > either. I'm saying that "as a PHP programmer" because my expectation is not based on how other languages

Re: [PHP-DEV] Bug #64910: Line number of $e = new Exception vs. line number of throw $e

On 23 May 2013 22:22, Stas Malyshev wrote: > If we update file/line here, we lose original exception information and > file/line in the exception becomes useless. Right now, since 99.99% of > the code does "throw new", it is always useful. So how you would propose > to solve this? As a PHP progr

Re: [PHP-DEV] Adding a more logical string slicing function to PHP

On 30 March 2011 15:05, Hannes Landeholm wrote: > Parsing is a problem in many real-world > problems and substr currently works great for that purpose. That's funny because the first thing I thought when I read the original mail was "oh that would be great for parsing." In fact, I've just grep'ed

Re: [PHP-DEV] Strict typing

2010/8/12 Johannes Schlüter : > Yes, my blog posting reflects my opinion and therefore is manipulative Indeed. Depending where you'll look, you'll find big communities that have no clue about or no need for type hinting/checking/casting, some communities where "strict" typing is heresy, others whe

Re: [PHP-DEV] Strict typing

On 12 August 2010 00:11, Zeev Suraski wrote: > I'm not sure how long you've been on internals, but I'm not sure there's any > precedence to such strong and diverse opposition to a feature - amongst both > core developers, original authors and the community at large. I don't know, I remember some

Re: [PHP-DEV] Strict typing

On 11 August 2010 23:26, Zeev Suraski wrote: > matter how much I try to explain - it won't help - we probably see things > too differently for us to ever agree on it.  Let's end it by saying that a > great deal of people here think it's horrible to introduce strict typing to > PHP period. Sure, a

Re: [PHP-DEV] Strict typing

On 11 August 2010 21:59, Zeev Suraski wrote: > Consensus about what?  About two similar features with slightly different > syntax being a bad thing?  I don't think we need consensus for that.  That's > not up for discussion.  It's an axiom for PHP. Of course it depends on your definition of "simi

Re: [PHP-DEV] Strict typing

On 11 August 2010 20:40, Zeev Suraski wrote: > Josh, > > This too (having both options) was debated many times.  Read the archives. I have already read the archives thank you very much. I'm sure you have too and you remember that there's never been a consensus. I'm su

Re: [PHP-DEV] Strict typing

On 11 August 2010 19:11, Alexey Zakhlestin wrote: > Did you read second RFC? The one which is about "so called" weak typehinting. > Stas (and a lot of people on this list) prefer it. > http://wiki.php.net/rfc/typecheckingstrictandweak Yes of course, but reposting that link is a good idea. :) > I

  1   2   >