Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 3.0 Final is out (1998)

web.archive.org

Post reply on HN
Print view View original

171–176 of 176 posts

Re: PHP 3.0 Final is out (1998)

#171

Post by tored »

innocenat wrote: post #156
forgotpwd16 wrote: post #139

Earlier quoted context omitted.

How bad will be running the built-in web server on public network?

You meant PHP built-in server (php -S)? It doesn't even support concurrent connection. Neither mod_php nor php-fpm is related to the built-in server though. Both are designed for production.

Built-in web server has experimental concurrent support since PHP 7.4

> Set the PHP_CLI_SERVER_WORKERS environment variable to the number of desired workers before starting the server

https://www.php.net/manual/en/features.commandline.webserver...

Re: PHP 3.0 Final is out (1998)

#172

Post by dspillett »

tannhaeuser wrote: post #109
dspillett wrote: post #30

Earlier quoted context omitted.

It basically did for simple web programming what visual basic did for Windows desktop toys: allowed you to throw some UI together (drag & drop components in the VB case, any old HTML with links or forms for PHP) then start stringing bit of code in haphazardly to link it together. No need to learn a more complex compiler or other build tools, worry about configuring CGI or other web server tech (unless running PHP you…

Injecting strings from user input into generated HTML? Sure, to hell with checking if it contains script tags and/or onclick= attributes, or perform any kind of escaping alltogether for that matter.

Worse, automatically adding request variables to the global namespace, in an order that if input validation is implemented but naively/buggily there can be easy ways to bypass it.

Re: PHP 3.0 Final is out (1998)

#173

Post by dspillett »

bruce343434 wrote: post #126
tannhaeuser wrote: post #109

Earlier quoted context omitted.

Injecting strings from user input into generated HTML? Sure, to hell with checking if it contains script tags and/or onclick= attributes, or perform any kind of escaping alltogether for that matter.

this is the programmer's fault and responsibility

Unfortunately the low barrier for entry meant that many programmers hit the ground "running" with no knowledge of such issues, so ended up creating much insecure code simply by never knowing any better.

Re: PHP 3.0 Final is out (1998)

#174

Post by dspillett »

waheoo wrote: post #164
iforgotpassword wrote: post #123

Earlier quoted context omitted.

Care to elaborate? It felt like the best thing ever when switching to InnoDB.

Elaborate on what? They're an opinion that data integrity is dependent on foreign keys containing pointers at existing data. In systems where actual row deletion doesn't actually happen its kind of a pointless kick to the nuts. Now I have to create things in a specific order for no reason other than foreign keys say so. When you're using uuids for reference keys you're not beholden to what order you insert you can ha…

I see your point for decentralised systems, "eventual consistency" is an unavoidable evil in many cases there at least if you don't want a performance hole caused by distributed transaction requirements.

But otherwise, I disagree strongly.

> feigned idea about data integrity but it's mostly bullshit

I call BS on your call of BS.

> The other common situation is...

If that is common in your production environments, then I never want to work with your production environments.

> foreign keys just get in the way.

Disable them, do the jiggery-pokery, and then replace them. Again, but not in production systems.

If FKs are an inconvenience day-to-day then you have something seriously wrong somewhere. They are protection against bugs and other unpredictables causing corruption of data that other code later relied upon being correct.

Re: PHP 3.0 Final is out (1998)

#175

Post by verelo »

ancarda wrote: post #133
542458 wrote: post #18

Earlier quoted context omitted.

As somebody who loves PHP, some PHP mockery is deserved. The standard function naming and argument ordering is inconsistent and stupid. It throws errors written in Hebrew. There were fundamental decisions made that harmed web security for years. Unicode wasn’t in PHP for a long time. Getting decent performance and/or scaling was/is a major challenge. The comparison tables are questionable at best. Etc. The language i…

> The standard function naming and argument ordering is inconsistent and stupid This is quite hard to fix, as it would break almost everything. So you'd end up with a Python 3 situation. However, as of PHP 8, it's less of an issue. If you can't remember the order for arguments, you can use named arguments https://3v4l.org/cY1PB > like so: strpos(needle: "foo", haystack: "foobar") > It throws errors written in Hebrew…

oh man, named arguments are great. I should have read the release notes sooner, i had no idea this change came out. Thanks for mentioning it!

Re: PHP 3.0 Final is out (1998)

#176

Post by cies »

ancarda wrote: post #146
cies wrote: post #136

Earlier quoted context omitted.

> PHP's own type system is usually expressive enough. I'd say it's one of the worst type systems. Expressive enough not to need docblocks, ok. Expressive as a type system: hell no.

I meant expressive enough that you don't need DocBlocks as often. We're nowhere near being done, PHP still lacks proper Generics and Algebraic Data Types. Recently we got Union Types (8.0) and will soon have Enums (8.1). If you really needed generics today, you can do it with DocBlocks and static analyzers like PHPStan: https://phpstan.org/blog/generics-in-php-using-phpdocs >. I'm hopeful that in the future, you won'…

You just said exactly what I said in my comment you reply on. More words, and more promo for future versions of PHP.

Seriously, try build something trivial with a strongly typed lang like Haskell or Elm (Elm is quite easy to get started with), and we can talk type systems after :)

Post reply on HN