Re: [PHP-DEV] Revive Number Format Separator RFC
Hi! > A cursory scan of current usage suggests that number format separator might > be used in scenarios such as: > > Phone numbers > 919_555_1234 > 49_89_636_48018 Just noting here that using integers as phone numbers is not something we want to support, enable or promote. > Date time values > 2018_04_26 > 20180426_183242 Same here, these are not integers (or numbers). > Range end points (using any locale's grouping strategy) > 2_147_483_647 > 1_67_77_215 These are numbers, but should be only ever used in constants (with appropriate comment). I am not exactly against this feature, but the potential for abuse - like enabling people using integers for things that are not integers and should not be stored as integers - worries me now. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Symbol implementation
On Sat, 27 Apr 2019 at 22:05, Bruce Weirdan wrote: > > On Sat, Apr 27, 2019 at 11:57 PM Dan Ackroyd wrote: > > > > typehint > > > > Please could people stop using that word. PHP's type system for > > parameters and return values are actual types, not just hints. > > People use the term PHP itself uses: > https://www.php.net/results.php?q=typehint=en=all The first link has: > This documentation has moved to the function reference. Following that link we have: > Type declarations > > Note: > Type declarations were also known as type hints in PHP 5. > Type declarations allow functions to require that parameters are of a certain > type at call time. I'm sure there will be other places that need updating in the manual. But they should be updated to use the accurate term, rather than the misleading term. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Symbol implementation
On Sat, Apr 27, 2019 at 11:57 PM Dan Ackroyd wrote: > > typehint > > Please could people stop using that word. PHP's type system for > parameters and return values are actual types, not just hints. People use the term PHP itself uses: https://www.php.net/results.php?q=typehint=en=all -- Best regards, Bruce Weirdan mailto:weir...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Symbol implementation
On Sat, 27 Apr 2019 at 20:37, David Rodrigues wrote: > > ES6 supports the Symbol type that is a replacement to hard-coded > identifiers where it are not really need. This seems quite similar to the idea of enums. That Levi and Bob might have been working on: https://wiki.php.net/rfc/enum > typehint Please could people stop using that word. PHP's type system for parameters and return values are actual types, not just hints. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Retiring PHP's Mirror Program
Hello, On Mon, 1 Apr 2019 at 16:26, Robert Hickman wrote: > > Is there any reason not to use 'php.net' raw without the 'www'? > Additional question: Can we maybe get an insight of a canonical, recommended URL which should be used now? Is this www.php.,net or is it php.net without www. Worth noting that now both domains result in 200 OK (previously there was a redirection done from php.net to www.php.net): curl -IL https://www.php.net curl -IL https://php.net Thank you... -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Symbol implementation
ES6 supports the Symbol type that is a replacement to hard-coded
identifiers where it are not really need.
I like to suggests a similar feature to PHP.
#0: it should be a partial class that could not be instantiated (new symbol
should be invalid, like an abstract class).
In this point I should suggests two options:
1. It should works like a new keyword "symbol", but that could be extended
like a class when need. (It will make sense on item #2). But could be
referenced directly without need of the ::class. (eg. $a = symbol;).
2. Other option is use it as a new keyword "symbol" followed by a \Symbol
reference class (like "instanceof Class" works). Eg. $a = symbol \Symbol;
Anyway, maybe \Symbol could works as a default type, so only $a = symbol
could be do the job. Or even consider symbol as a language constructor,
allowing symbol(\Symbol), for instance.
Ok, now to all make senses (I do expects), keep reading... (I will use
otpion 2 as reference for now)
#1: It could be used to fill constants, for instance, with "magic
identifiers" that have no real value, needly.
Eg.:
public const
USER_NOT_FOUND = symbol(),
USER_INVALID = symbol();
Where USER_NOT_FOUND !=/!== USER_INVALID.
#2: Another possibility is to extends it as an class, so it could be used
as parameter typehint: (not available on ES6, I guess)
class UserErrorSymbol extends \Symbol {}
public const
USER_NOT_FOUND = symbol(UserErrorSymbol),
USER_INVALID = symbol(UserErrorSymbol);
public function setError(UserErrorSymbol $error) {...}
#3: it should have a fallback name (storing a scalar value), so in case you
need to persist it (or serialize), so you could give a name:
public const
USER_NOT_FOUND = symbol(UserErrorSymbol as "UserNotFound"),
USER_INVALID = symbol(UserErrorSymbol as "UserInvalid"),
USER_INVALID_B = symbol(UserErrorSymbol as "UserInvalid");
symbol_alias(USER_INVALID) === 'UserInvalid'
(string) USER_INVALID === 'UserInvalid'
USER_INVALID !=/!== USER_INVALID_B
#4: it could be used as a kind of anonymous array or object key:
$arr[symbol()] = 1;
$arr[symbol()] = 2;
count($arr) === 2
$obj->{symbol()} = 1;
$obj->{symbol()} = 2;
count(get_object_vars($obj)) === 2
But symbol could not be accessed without a valid reference:
echo $arr[symbol()]; // error: index symbol() is undefined or maybe symbol
type could not be used directly to read an array value
$symbol = symbol();
$arr[$symbol] = 1;
echo $arr[$symbol]; // print 1
It is just a draft, but I do belive that it will be a good feature for PHP.
[PHP-DEV] TCO: Tail Call Optimization
Not long ago I heard about the Tail Call Optimization from ES6. It seemed obscure to me at first, but once I understood the benefit of having it, it seemed like a good idea of optimization for PHP to avoid recursion problems. Is there any plan to make it possible in the engine? -- David Rodrigues
[PHP-DEV] Re: [discussion] arraykey type
On Sat, 27 Apr 2019 at 00:13, azjezz wrote: > > What do you think about adding the `arraykey` type to PHP. I don't think we should be adding anything to PHP core unless: * there is a strong case for it being needed. * we're sure it's not going to cause problems in the future. * it's clearly the correct thing to implement. * there's good reasons not to implement it in userland. I'm pretty sure this idea fails all of those tests, except the last one. Without generics, it seems the need for an general arraykey type is low, for me at least. For the vast majority of the arrays I use, I don't mix key types. All of the entries in an array will be either 0-based incrementing integer keys, string based keys. I think the Union Types RFC https://wiki.php.net/rfc/union_types has a high chance of being revisited in the future. As Nikic mentioned in the PR we would need to make sure that arraykey would be compatible with it. That is very hard to get right without having the Union Types RFC already implemented, as the behaviour around casting is going to be tricky. Or, more simply, there are some parts of PHP that can be made better by adding small bits at a time. I don't think the type system is one of those parts, and it's better to get the big pieces in place first, so that the smaller bits will fit accordingly with those. If you wanted to proceed with it, I think you'd need to find a really strong reason for why it should be added, rather than just it could be added. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
On 27 April 2019 13:51:11 BST, Lester Caine wrote: >On 27/04/2019 13:37, Rowan Collins wrote: >> The only way I've seen dates stored as integers is as a number of >> seconds / milliseconds / whatever since some epoch, most commonly >> seconds since 1970-01-01 00:00:00 UTC > >Use of a days count rather than a seconds count makes dates a lot >easier >to work with. 2 32bit numbers give a substantial day count along with >either fractional time of day or alternatively a second count for the >day. That makes sense, but it's still a variant on the epoch + count concept, not year-month-day as in Bishop's example. As such, it still wouldn't particularly benefit from separators; you'd probably write constants in string form and convert them on the fly, or have durations which were multiples of 7 or 365 rather than powers of 10 or 16. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
On 27/04/2019 13:37, Rowan Collins wrote: The only way I've seen dates stored as integers is as a number of seconds / milliseconds / whatever since some epoch, most commonly seconds since 1970-01-01 00:00:00 UTC Use of a days count rather than a seconds count makes dates a lot easier to work with. 2 32bit numbers give a substantial day count along with either fractional time of day or alternatively a second count for the day. Genealogical data is substantially easier to manage as a day count which can be expanded in accuracy with a time count either viewed as integers or as floating point numbers ... leap seconds just get hidden in the processing. -- Lester Caine - G8HFL - Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
On 27/04/2019 12:18, Thomas Punt wrote: Storing dates in an integer format can be a valid use case if performance is a concern. It is far faster and more compact to store and compare integer-based dates than using objects for everything. The only way I've seen dates stored as integers is as a number of seconds / milliseconds / whatever since some epoch, most commonly seconds since 1970-01-01 00:00:00 UTC The format Bishop seemed to be suggesting would be absolutely useless for anything other than the simplest comparisons: how do you add a day to the date-as-number 20190430? I'm sure there are use cases for this syntax, but the examples in that e-mail were poorly chosen. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revive Number Format Separator RFC
Hi! > On Fri, Apr 26, 2019 at 4:30 PM Theodore Brown wrote: > > > On Fri, Apr 26, 2019 at 6:10 AM Rowan Collins > > wrote: > > > > I'm not particularly against this proposal, but I'm not sure how often I'd > > use it. > > How often you use numeric separators depends on what you are doing. > I definitely agree that phone numbers and dates are not good use cases, > and that there are usually better ways to write things like the number > of seconds in a day or number of bytes in a gigabyte. Storing dates in an integer format can be a valid use case if performance is a concern. It is far faster and more compact to store and compare integer-based dates than using objects for everything. Anyway, if anyone would like to revive this RFC, then feel free to! Thanks, Tom
