Live data from Hacker News

Announcing a specification for PHP

hhvm.com

251–260 of 263 posts

Re: Announcing a specification for PHP

#251
post #231
post #209

Earlier quoted context omitted.

> Just spin up a preconfigured dokku droplet and git push. Exactly the kind of things I don't want to be bothered with. I'm just saying that traditional web hosts suit my needs perfectly and DigitalOcean is no replacement.

So that would be "I don't want to be bothered with two clicks and a single terminal command." Really? Leaving aside the whole "PHP sucks" vs "PHP is great/fine for my purposes" thing, this is really breathtaking. The fact that you can just FTP up your folder does not mean that's a sensible best-practice way to deploy anything, PHP, Ruby, Brainfuck or whatever you like. It isn't. FTP is insecure[0]. If you're balking…

What I use it for: my own personal projects where I don't care about security. What I don't use it for: work.

Even if I can configure it down to two clicks it still comes with the cost of having to worry about maintaining a VPS.

Re: Announcing a specification for PHP

#252

Earlier quoted context omitted.

Hmm. Looks like Hack still includes files based on strings: https://github.com/hhvm/hack-example-site/blob/master/index.... How can a language be statically typed when the instructions telling it what code to use are dynamic?

include "foobar.php", IIRC, is executed at compile-time, and I assume must be in Hack's type checker too. Also, I don't see how pausing execution and re-invoking the compiler at run-time to load the rest of the code base (which you can do in PHP with a conditional include, don't know about Hack) can't be done with static typing.

Let's say we have the following:

file1.hh:

     1)? function(array $x) {}
                                 : function(stdClass $x) {};
    $anArray = [];
file2.hh:

    
file3.hh:

     1)? ['file1.hh', 'file2.hh']
                                 : ['/dev/random', '/dev/random'];
    include $f1;

    if (time() > 1) $anArray = new stdClass;

    include $f2;
As far as I understand it, the following will happen when we run file3.hh:

- HHVM will compile file3.hh. This phase doesn't know what $f1 or $f2 will be, or whether $anArray will become a new stdClass, since they depend on the output of time().

- HHVM finishes compiling file3.hh

- HHVM will execute file3.hh, setting $f1 to 'file1.hh' and $f2 to 'file2.hh'.

- HHVM will compile file1.hh. This phase doesn't know what $giveMeAnArray will be, since it depends on the output of time().

- HHVM will finish compiling file1.hh

- HHVM will run file1.hh, defining $giveMeAnArray = function(array $x) {} and $anArray = []

- HHVM will resume running file3.hh and set $anArray = new stdClass

- HHVM will compile file2.hh, which contains a type error. How does it know?

The most likely answer is that type information is stored in values and checked during usage. That is not static typing, it's 'dynamic typing' (tag-checking).

There is an alternative possibility: the state of the compiler could be preserved between files, so type information from file3.hh and file1.hh is available when compiling file2.hh. However, this information wouldn't include knowledge that "$my_account = new stdClass" has been executed, since that's dynamic run-time information which is only knowable after file3.hh and file1.hh have finished compiling.

There is no way (to my knowledge) that interleaving static type-checking with dynamic execution can produce a type-error when file2.hh is compiled. The type-checking must have access to the execution state of the program, ie. it must be dynamic.

If type-checking happens during/alongside/interleaved-with execution, the compilation phase (which must be done prior to execution) cannot know the types of the code it's compiling. Without this knowledge, the first unit of code it produces is forced to use dynamic types (AKA a unitype). Once that unit is type-checked/executed, the runtime information gained may be used to partially-inform subsequent compilation, somewhat like a JIT, but there would always need to be dynamic fallbacks. Of course, a dynamic fallback defeats the main point of using static types: being informed when there's an error. There may be incidental benefits from doing this though, like faster code.

Re: Announcing a specification for PHP

#253

Earlier quoted context omitted.

That workflow is pretty outdated, you know. It's about akin to using tables for layout, and about as much of a no no. I know, git can be pretty confusing, but using version control, even in a one man shop, is a huge boon.

who says Kiro isn't using version control? traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that. You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid w…

It's a strong implication.

Kiro quotes two items from the parent, and says he doesn't want to be bothered with "those" things.

Kinda implies he doesn't use git, since that was one of the two items quoted.

Re: Announcing a specification for PHP

#254
post #210

Earlier quoted context omitted.

The far greater wart is passing functions as string names. PHP is so bad that it's hard to imagine that it isn't a giant troll. No amount of modernizing will ever turn PHP into anything close to sane; the amount and depth of craziness is simply too huge.

A lot of languages have ways of calling functions and methods by string names -- PHP just makes it very easy and the design is actually really clean.

> PHP just makes it very easy and the design is actually really clean.

Very little about PHP's treatment of functions is easy or clean.

    function foo() { echo "Hello world"; }

    $w = 'foo';
    echo $w;  // foo
    $w();     // Hello world
    'foo'();  // PHP Parse error: syntax error, unexpected '('

    function bar() { return 'foo'; }
    $x = bar();
    echo $x;  // foo
    $x();     // Hello world
    bar()();  // PHP Parse error:  syntax error, unexpected '('

    $o = new stdClass;
    $o->baz = 'foo';
    $y = $o->baz;
    echo $y;  // foo
    $y();     // Hello world
    $o->baz();  // PHP Fatal error:  Call to undefined method stdClass::baz()
Heck, PHP doesn't even recognise function-call syntax applied to a function!

    $z = function() {
           echo "Hello world";
         };
    $z();  // Hello world
    (function() {
       echo "Hello world";
     })();  // PHP Parse error:  syntax error, unexpected '('

Re: Announcing a specification for PHP

#255

Earlier quoted context omitted.

A lot of languages have ways of calling functions and methods by string names -- PHP just makes it very easy and the design is actually really clean.

> PHP just makes it very easy and the design is actually really clean. Very little about PHP's treatment of functions is easy or clean. function foo() { echo "Hello world"; } $w = 'foo'; echo $w; // foo $w(); // Hello world 'foo'(); // PHP Parse error: syntax error, unexpected '(' function bar() { return 'foo'; } $x = bar(); echo $x; // foo $x(); // Hello world bar()(); // PHP Parse error: syntax error, unexpected '(…

When this[1] RFC goes through most of those issues will be resolved. Even without them, ignoring edge cases ('foo'() isn't useful), it's still quite reasonable. The RFC linked above just improves on the design, it doesn't change it.

[1] https://wiki.php.net/rfc/uniform_variable_syntax

Re: Announcing a specification for PHP

#256
post #250
post #230

Earlier quoted context omitted.

I feel like its callable system is simple, easy to use, and frankly awesome. I can do $func = ['object', 'staticMethodName']; $func = [$instance, 'publicMethodName']; $func = 'functionName'; $func = '\namespaced\functionName'; $func = function(){ ... }; $func = $callableObject; // ( http://php.net/manual/en/language.oop5.overloading.php#objec... ) I can execute any of the above by calling `$func('doIt');` Moreover al…

The problem is that a function is a thing. A string is a different thing. Imagine if arrays were represented as comma delimited strings, and you had a function isArray to check if a string has the right format to represent an array. That would be ridiculous right? An array should be its own type. The same goes for functions. Representing functions as string names is just as crazy as representing arrays as comma delim…

Ridiculous or not, Tcl works like this. Everything is a string.

Re: Announcing a specification for PHP

#257

Earlier quoted context omitted.

I'm sure you've already seen this (it's been around a while), but if not, you'll find it amusing: http://www.phpwtf.org/ Last I checked, it wasn't quite as good as wtfjs, but it looks like quite a few new surprises have been added rather recently. Edit: Correction, there's only one new entry as of this year, which is a shame. :)

The first two I read aren't even WTF the worthy and are perfectly reasonable. Even in the classic fractal of bad design article, only 1/3 of it is actually valid.

I half agree, but I'd like to point out that the likely reason the curator of this site thinks of these as "WTFs" has more to do with PHP's (lack of?) consistency and it's relatively bizarre behavior when compared with saner languages.

The other thing to consider (looking at it again, particularly at the second example) is that there are some surprising side effects that can snag newcomers, depending on their background and whatever other languages they know.

Perhaps one of the drawbacks with programming PHP is that you become so desensitized to weirdly inconsistent/surprising behavior that there's almost nothing left to be surprised about.

Re: Announcing a specification for PHP

#258

Earlier quoted context omitted.

who says Kiro isn't using version control? traditional web hosts provide a level of management that isn't present in VPSes. You may be able to get turnkey instances, but you still have to be responsible for managing them and maintaining them. Vs a traditional webhost where you don't have to worry about all that. You can claim that its "outdated" and "akin to using tables for layout", but its also still a very valid w…

It's a strong implication. Kiro quotes two items from the parent, and says he doesn't want to be bothered with "those" things. Kinda implies he doesn't use git, since that was one of the two items quoted.

I do use git. Just not for deployment. To be honest though I could live without it.

Re: Announcing a specification for PHP

#259

Earlier quoted context omitted.

PHP is on the server .

A lot of the sites we frequent have python, ruby or C# on the server.

That's not the point. PHP is the lingua franca of the server-side as it's by far the most commonly used language and widely understood. Do others exist? Sure. Just as other languages exist. But PHP's the big one.

Re: Announcing a specification for PHP

#260

Earlier quoted context omitted.

The first two I read aren't even WTF the worthy and are perfectly reasonable. Even in the classic fractal of bad design article, only 1/3 of it is actually valid.

I half agree, but I'd like to point out that the likely reason the curator of this site thinks of these as "WTFs" has more to do with PHP's (lack of?) consistency and it's relatively bizarre behavior when compared with saner languages. The other thing to consider (looking at it again, particularly at the second example) is that there are some surprising side effects that can snag newcomers, depending on their backgro…

It's nit-picky to the point of ridiculousness. Take the first example, even the title "Objects with __toString are not strings." is already WTF worthy. Of course objects with a __toString method are not strings! It means they can be converted to strings when unambiguously used as strings. Which is exactly what happens! The whole entry is stupid. The author even complains that PHP will issue an error if __toString doesn't return a string! I mean really.

Most other entries involve doing something bizarre with obviously undefined consequences and then marveling that PHP does it different than they expect. Or failing to understand PHP's basic rules and then again, on edge cases, marveling at weirdness of the perfectly logical result.

The "PHP protected and an assault" entry just fails to comprehend how access modifiers actually work with the classes.

There are real PHP WTF's but honestly they were all discovered 10 years ago. Probably 50% of all entries on the site are people misunderstanding how references work over and over and over.

Post reply on HN