Hacker News Reader

Comment by fredemmott | Hacker News Reader

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 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/90c5f8eca17d1d4e1204f0085...)

View on HN

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?

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.

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.

> 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.

That naming convention seems quite confusing.

Why not make all functions (standalone and methods) either snake or camel case?

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.

Reply on news.ycombinator.com