3 ms·

Function naming: We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync

Function naming: We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync(). We're unlikely to change the PHP builtins, but we're fairly likely to build replacements - for example, Hack Arrays are best used with https://github.com/hhvm/hsl https://github.com/hhvm/hsl instead of the PHP array functions, and this also provides replacements for common string operations that are consistent and fit well with the Hack type system (e.g. nullable or throw an exception instead of falseable). For return values, I'm not sure exactly what you mean - could you give a full example? If I take your example verbatim, it's a syntax error in both Hack and PHP - if I go for "5"*10, it's a Hack error (https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085cc120f5 https://gist.github.com/fredemmott/90c5f8eca17d1d4e1204f0085...)

the_duke 9y ago
That naming convention seems quite confusing. Why not make all functions (standalone and methods) either snake or camel case?
- takeda 9y ago
  I hope the previous post was a joke, because it felt like one. Edit: "We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync()." C'mon. That doesn't sound like much improvement compared to the original PHP.
tiffanyh 9y ago
From the blog post: HHVM will not aim to target PHP7 If you don't plan to support PHP5 anymore and HHVM is not targeted at PHP7 ... then my ask is to just make a better language and drop ALL of PHP baggage. When you say: We're unlikely to change the PHP builtins That concerns me. Because why even break support from PHP7 if you don't plan to change (fix) the builtins?
- mxawng 9y ago
  As fredemmott said above, we're hoping to build replacements for the various PHP builtins that we want to be a core part of Hack. I think that replacing the functionality provided by PHP builtins will be a less confusing transition experience than retrofitting them with modified behaviors would. Once we do have a compelling and comprehensive Hack Standard Library, I wouldn't be surprised if we dropped PHP builtins in favor of that.
- mic47 9y ago
  Maybe because there will be replacements instead? I guess that changing behavior (and type signatures) of builtins is not backward compatible with projects that want to use Hack. This way they will be able to migrate at their own pace.
- fredemmott 9y ago
  > my ask is to just make a better language and drop ALL of PHP baggage. Long-term, we hope to make pure-hack projects more practical, and we're aiming to make Hack the best web development language. This will take time - both to decide what parts of PHP we want to keep (it definitely does have excellent parts), and how we want to change the things we think need improvement. > Because why even break support from PHP7 if you don't plan to change (fix) the builtins? Sorry, I was unclear: changing the behavior of the PHP builtins will break BC with PHP, and the result would still not be what we want for hack. We're likely to build Hack-only replacements for the PHP builtins, instead of changing the behavior of them.

the_duke 9y ago

That naming convention seems quite confusing. Why not make all functions (standalone and methods) either snake or camel case?

takeda 9y ago
I hope the previous post was a joke, because it felt like one. Edit: "We're moving towards functions_like_this(), instanceAndStaticMethodsLikeThis(), and async functions like foo_async() and methods like fooAsync()." C'mon. That doesn't sound like much improvement compared to the original PHP.

tiffanyh 9y ago

From the blog post: HHVM will not aim to target PHP7 If you don't plan to support PHP5 anymore and HHVM is not targeted at PHP7 ... then my ask is to just make a better language and drop ALL of PHP baggage. When you say: We're unlikely to change the PHP builtins That concerns me. Because why even break support from PHP7 if you don't plan to change (fix) the builtins?

mxawng 9y ago
As fredemmott said above, we're hoping to build replacements for the various PHP builtins that we want to be a core part of Hack. I think that replacing the functionality provided by PHP builtins will be a less confusing transition experience than retrofitting them with modified behaviors would. Once we do have a compelling and comprehensive Hack Standard Library, I wouldn't be surprised if we dropped PHP builtins in favor of that.
mic47 9y ago
Maybe because there will be replacements instead? I guess that changing behavior (and type signatures) of builtins is not backward compatible with projects that want to use Hack. This way they will be able to migrate at their own pace.
fredemmott 9y ago
> my ask is to just make a better language and drop ALL of PHP baggage. Long-term, we hope to make pure-hack projects more practical, and we're aiming to make Hack the best web development language. This will take time - both to decide what parts of PHP we want to keep (it definitely does have excellent parts), and how we want to change the things we think need improvement. > Because why even break support from PHP7 if you don't plan to change (fix) the builtins? Sorry, I was unclear: changing the behavior of the PHP builtins will break BC with PHP, and the result would still not be what we want for hack. We're likely to build Hack-only replacements for the PHP builtins, instead of changing the behavior of them.