[HN Gopher] Whats New in PHP 8.2
___________________________________________________________________
Whats New in PHP 8.2
Author : maydemir
Score : 123 points
Date : 2022-04-25 12:49 UTC (10 hours ago)
(HTM) web link (stitcher.io)
(TXT) w3m dump (stitcher.io)
| Ciantic wrote:
| > Deprecate dynamic properties
|
| That's pretty big one. Lot of JSON can be deserialized to
| basically bunch of objects with dynamic properties, since it's
| parameter in deserialization.
|
| For example `json_decode("...", false)` where second parameter
| (false) explicitly says it should return object. After that it's
| typical to set values such as `$post->name = 'Name';`, which
| would now give warning and in PHP 9 an error.
|
| Maybe we shouldn't characterize PHP as dynamic language after the
| change?
| masklinn wrote:
| > Maybe we shouldn't characterize PHP as dynamic language after
| the change?
|
| By that definition, Smalltalk isn't a dynamically typed
| language. Neither is Clojure.
|
| That is obviously complete nonsense.
|
| A dynamically typed language is one where types are resolved at
| runtime. That doesn't mean it can't have restrictions.
| iforgotpassword wrote:
| I always wondered why you want to deserialize JSON as ab object
| tree instead of associative array. Just because the syntax is
| nicer? I mean, your ide still can't autocomplete the fields for
| you since it's just a stdclass and it doesn't know anything
| about the JSON structure right?
|
| Also, probably not relevant in practice, but one of those two
| is probably faster?
| lambic wrote:
| As far as speed is concerned (and yes this is a
| generalization):
|
| defined object > dynamic object > array
|
| But it's very much a micro-optimization.
| toast0 wrote:
| You can get an associative array with one more parameter, so
| that's what I do. Array access is nicer than object access to
| me, but maybe that's just me.
| duskwuff wrote:
| > I always wondered why you want to deserialize JSON as ab
| object tree instead of associative array.
|
| To prevent [] and {} from both being deserialized to an empty
| array.
| falsenapkin wrote:
| This is the most convincing answer to me. I learned this
| the hard way recently.
| tored wrote:
| One important difference is how you will pass the decoded
| JSON data afterwards within your application, objects are
| passed as reference and arrays are passed as copy on write,
| thus if you intent to modify it it can be easer with an
| object.
|
| Another is if you going to merge JSON data and send it
| further then an object can be easier because that is how the
| rest of the world views it.
|
| However there many more array functions in the standard
| library than object functions.
|
| I think it is generally easier to annotate arrays vs objects
| with phpdoc.
|
| If this blog post is still true today when it was written
| (2018 PHP 7.2), then arrays are better for performance vs
| stdClass, but a real class is better than both, but sadly you
| can't JSON decode into a class directly.
|
| https://steemit.com/php/@crell/php-use-associative-arrays-
| ba...
| mhitza wrote:
| From the RFC
| https://wiki.php.net/rfc/deprecate_dynamic_properties
|
| > stdClass and __get/__set are not affected by this change.
|
| Your json example, or object cast of an array, or directly
| defining properties on a stdClass will not cause a deprecation.
| coolgoose wrote:
| _Classes marked with #[AllowDynamicProperties] as well as their
| children can continue using dynamic properties without
| deprecation or removal. The only bundled class marked as
| #[AllowDynamicProperties] is stdClass._
|
| Aka stdClass based obj's are still fine to have dynamic
| properties. So mostly sure it's still going to work.
| wackget wrote:
| Yeah this seems like a bad one to me.
| tored wrote:
| It is only for classes not for objects (stdClass). You can mark
| a class with the attribute #[AllowDynamicProperties] to allow
| dynamic properties.
|
| You can also still implement the __get/__set methods on the
| class to have dynamic properties.
|
| What this RFC does is to remove not declared dynamic
| properties.
|
| https://wiki.php.net/rfc/deprecate_dynamic_properties
| thinkindie wrote:
| json_decode('...', false) will deserialize into a stdClass -
| which I guess implements magic methods __set() and __get. I've
| never checked this but I guess that would do the trick has
| mentioned in the article itself.
| kijin wrote:
| stdClass doesn't implement magic methods -- any properties
| you add are added directly to the object, not to any kind of
| internal data store -- but it is explicitly marked as an
| exception to the proposed rule.
| GeneralTspoon wrote:
| This won't affect that case, as it uses stdClass (which is
| allowed to use dynamic properties).
|
| This is only for cases where you have a specific class like
| User, and you don't want people setting random dynamic
| properties on it.
|
| If you do you can also mark the class with an annotation to
| allow dynamic properties.
| pwdisswordfish9 wrote:
| Indeed, I've noticed a while ago it's slowly becoming a Java
| with lots of dollar signs.
| AdrianB1 wrote:
| Is there any programming language that changed so much as people
| that know the initial versions will not be able to understand the
| latest one? This is my impression about PHP and I cannot remember
| a single other such case. My memories go back to the 80's (Basic,
| Pascal, Cobol, SQL), I am not familiar with the current state of
| C, but my feeling is that the latest PHP and the original PHP
| share little more than the name.
| nobleach wrote:
| It's entirely possible. I wrote my last real PHP in 2014. Even
| then I was maintaining a very old app. I did write a quick API
| in Laravel back in 2017 just to see what all the fuss was
| about. And even then. PHP felt a LOT different.
|
| I keep an eye on the language and I'll admit, it's VERY far
| from what I originally used. That's a good thing.
| hu3 wrote:
| function alwaysFalse(): false { return false;
| }
|
| This function return is... interesting.
| alex-zierhut wrote:
| AS far as I know, this is because it was and still is common
| practice to return a result from a function, but return false
| if something didn't work. Having this type helps return type
| declaration like: false|ResultObject
|
| In my opinion, using Exceptions or nullable types is a better
| practice in those cases, but I am not against having more
| options.
| nicoburns wrote:
| Yeah it makes a lot of sense just to be able to type existing
| functions. Seems weir d not to allow true though. I feel like
| both should be added for completeness.
| matsemann wrote:
| Kinda make sense, though, as what would that "true" really
| mean? That the function succeeded? But then the result
| should be the output.
| cestith wrote:
| I don't mind a unit type for failure. I just don't think it
| should be called "false". Maybe make true and false Boolean
| and have a unit type for failures called "fail" or
| "failure".
| simion314 wrote:
| I think for new code Exceptions are the preferred
| solution in case your code errors out , much more clear
| to return just one type of data. So this seems to be just
| a solution for improving type declaration for older code
| that that use the pattern to return false in case of
| error instead of an exception with a much more clear
| information on what went wrong.
| djbusby wrote:
| PEAR_Error
| sfteus wrote:
| Right, in the context of PHP it makes sense, as bool would
| imply you might need to handle a truthy value when in reality
| the return type of several built-in functions is
| result|false.
|
| Nullable types generally work well, unless you're you have a
| function that may return nothing, or an error. IE
| findUser(string $name): ?User wouldn't be able to
| differentiate between a database error or just not finding a
| user with that name. Exceptions would work fine here
| (specifically due to a DB error), but seem a little
| superfluous for smaller functions.
|
| Personally, I've grown to love the tuple return types of
| Go/Rust, and I'd love to see first-class support for that
| within PHP. You can emulate it by returning an array and
| unpacking it / using list(), but it adds a decent amount of
| boilerplate and you lose aspects of type covariance in always
| returning an array.
| Helitioo wrote:
| Funny to see PHP staying weird.
|
| Introducing false and null loving it :D
| alex-zierhut wrote:
| The last few years have brought insane progress to the PHP
| language. I absolutely love the direction. Personally, the next
| feature I'd like to see the most is a great implementation of
| Tasks / Asynchronously, something the language always lacked,
| possibly because it is nearly exclusively used with web servers.
| I mostly get around that by extensively using queues, software
| like RabbitMQ, and spawning micro services. I would like to see
| it move towards more general purpose usability.
| tgtweak wrote:
| Just be a real cowboy and use pcntl_fork()
|
| Partially not kidding - I've used this as far back as 2004 to
| build cron jobs that pull a dataset, split it into N subsets,
| then fork out into N children to process those subsets of data
| in parallel. It's certainly not fluid like tasks and it creates
| a lot of memory duplication if you fork AFTER your data is
| pulled, but it works surprisingly well. Parent thread can wait
| for children to finish and even message children through socket
| pairs (or pcntl_signal for very basic stuff). I agree that it
| would be nice to have a native abstraction for tasks with
| messaging and concurrency limits built in.
| hu3 wrote:
| Fyi someone took pcntl_fork() in PHP seriously and made
| WorkerMan: https://github.com/walkor/workerman/blob/515ed41ac
| 4fc51fc995...
|
| A quick test got me 50k req/s HTTP "hello world" on my
| laptop.
|
| The madlad even managed to place PHP in top 22 TechEmpower
| benchmark: https://i.imgur.com/6fKUpbV.png
| Shish2k wrote:
| > The last few years have brought insane progress to the PHP
| language
|
| I've been hearing this for ~20 years, and yet somehow I still
| find it more painful to use than other languages that didn't
| even exist 10 years ago...
|
| (Except for "being easy to deploy on any random bargain-
| basement shared web host", which is a hugely important factor
| where PHP is genuinely best-in-class and no other language even
| seems to care about competing, and is the reason that I still
| regularly need to use it)
| vegai_ wrote:
| This. PHP is PHP just like Javascript is Javascript. Their
| growth process was a bunch of people needing things and just
| implementing them one by one without a grand design. It kinda
| works, but it'll never be Good in a theoretical sense.
|
| Disturbingly for us language geeks, it doesn't seem to matter
| at all that they're not very good.
| Beltalowda wrote:
| The real problem with PHP was always the standard library and
| its many caveats, outright bugs, and inadequacies, rather
| than the PHP language itself (there's a few language issues
| as well, but I found those less painful than the standard
| library).
|
| A few of these things have been fixed, but by and large the
| situation has remained unchanged for a long time. It's not an
| easy problem due to compatibility reasons; adding new
| language features and such is comparatively easy.
| exikyut wrote:
| PHP _seriously_ needs an event loop. The Node model, where
| things that call into libuv to wait on servers and such prevent
| the script from exiting, is simple enough to implement and
| while mildly unintuitive to newcomers is still accessible
| thanks to Node 's popularity.
| hu3 wrote:
| If anything the NodeJs model is trickier to scale because it
| requires discipline to never block the loop unnecessarily.
|
| PHP/Go/C# one-thread-per-HTTP-request also requires less
| cognitive load where everything is synchronous by default.
| Also PHP's throw-away-everything after each request tolerates
| much more junior-code abuse.
|
| Forgot to close a database connection or transaction? No
| problem, PHP will do that for you. Left a file open? Forgot
| to close a CURL handle? No worriers the janitor is coming to
| clean your mess at the end of the request.
|
| With that said, PHP does _have_ an event loop. See ReactPHP
| and Swoole. They existed for years and while they have their
| uses, they aren 't going to overtake "standard" PHP execution
| model anytime soon partly because of the reasons above.
| brimble wrote:
| As long as _from the programmer 's perspective_ it's opt-in
| rather than opt-out--that is, "await" by default. That was a
| huge mistake for Node and will seemingly haunt it forever.
| francislavoie wrote:
| PHP has support for event loops, including libuv. See
| https://reactphp.org/ you can build performant websocket
| servers with this.
| rabuse wrote:
| PHP is currently my favorite language to work in, especially as
| a freelancer who needs to just get things implemented quickly.
| No strange docker log issues like I've had with python/node
| stacks of errors not showing in docker logs until a service
| restart; just reload a page and bam.
| pantulis wrote:
| This is more related to how you deploy PHP or Python to the
| languages themselves...
| francislavoie wrote:
| Well, PHP is specifically optimized for that usecase, with
| opcode caching etc. Python doesn't do well when initialized
| on every request.
| VWWHFSfQ wrote:
| isn't this what pyc's are? what's the difference?
| saila wrote:
| It sounds like they're talking about deployments where a
| new process is spawned to handle each request, but for
| the most part no one deploys Python web apps that way, so
| I'm not sure.
|
| PHP may have some advantages in terms of _deployment_ ,
| so I guess it's a question of whether those advantages
| outweigh the potential advantages of using Python for
| _development_ , which is of course
| subjective/situational.
| chippiewill wrote:
| It's because PHP uses a CGI process-per-request style
| model, while there's no good or modern for support in
| Python for that execution model these days (the community
| is built around WSGI and ASGI instead). Opcode caching
| isn't actually relevant because PHP reuses the processes
| and in-memory structures these days as much as possible.
| Helitioo wrote:
| Have you ever dropped a frame while debugging and fixing it
| on the fly in a debugger?
|
| I think you miss out if you feel that this is a win when
| doing PHP.
| blowski wrote:
| Like Fibers? https://www.php.net/manual/en/language.fibers.php
| kijin wrote:
| Fibers don't run concurrently with the main thread. They're
| like preemptive multitasking, not simultaneous multitasking.
|
| For example, if you have a long-running database query, disk
| I/O, or some other blocking function, you can't simply send
| it to the background and do something else while waiting for
| the result. Network requests are better, but only because the
| underlying functions support a rudimentary form of async
| calling.
| tored wrote:
| Someone has apparently implemented async library with
| fibers and stream wrappers.
|
| https://www.reddit.com/r/PHP/comments/u80gyg/true_coroutine
| s...
| alberth wrote:
| PHP has really become quite great to work with.
|
| I wish there was a fork of PHP that cleaned up all the things
| that would break backward compatibly (e.g. have consistently
| method naming, clean up type casting for methods that do that
| which can today lead to weird bugs, etc). Essentially, haven't an
| entire "clean" language to work with.
| francislavoie wrote:
| A fork would completely fracture the community. No thanks.
| dcgudeman wrote:
| There already is a fork, https://hacklang.org/. It didn't
| fracture the community, people just don't use hack.
| tored wrote:
| My suggestion would be to create a language that compiles to
| PHP, similar what TypeScript is to JavaScript.
| caditinpiscinam wrote:
| https://hacklang.org/
| alberth wrote:
| I was under the impression that even though Hack no longer is
| backward compatible with PHP - that in practice, it's still
| largely the same (not much has changed). Or am I mistaken?
| tored wrote:
| Lots of changes. Like built in async, generics, shapes
| (typed associative arrays) and I learned the other day here
| on HN that XML templating is built into the language,
| somewhat similar to JSX.
| slimginz wrote:
| JSX in React was actually based on XHP (Hack's XML
| template framework) since both were developed at Facebook
| allendoerfer wrote:
| The most annoying thing you encouter daily in PHP is the
| needle/haystack problem. There is no consistency with parameters
| of the standard library. It could be fixed in two ways:
|
| a) Make everything an object, where methods can be called on:
| $arr = []; $arr->key_exists('key');
|
| b) Create a new class-based standard library, where you call
| those functions statically and needle/haystack are always in the
| same place: Arr::key_exists($arr, 'key');
|
| Either way, you can deprecated all the array_..., str_..., etc.
| functions and end the guessing game. Other than that PHP is
| turning out great.
| tored wrote:
| There is actually _some_ consistency, array functions have the
| same parameter order and string functions have theirs, it just
| different order between these two groups of functions.
| Reubensson wrote:
| > array functions have the same parameter order and string
| functions have theirs
|
| Except when they have different order :)
| array_filter(array $array, ?callable $callback = null, int
| $mode = 0): array array_map(?callable $callback, array
| $array, array ...$arrays): array
| francislavoie wrote:
| Userland frameworks/libs provide those kinds of helper classes
| already.
|
| And IDEs completely solve the problem of knowing parameter
| orders by hinting them as you type the functions.
|
| This really isn't that big of a deal.
| allendoerfer wrote:
| I would like it to look pretty.
| algerd wrote:
| I'm suggesting to use https://github.com/azjezz/psl nice
| wrapper on php std library
| conradfr wrote:
| This is so funny to me how it's constantly brought up here but
| has never been an inconvenience to me, and I started with PHP3
| in 1998.
|
| Even before auto-completion I guess I would just read the docs.
|
| To each his own I guess.
| Reubensson wrote:
| I am sure that if you use a language/library for long enough,
| its bad design descisions aren't a huge problem to you.
|
| Reading the docs of course helps, but it is still
| inconvenience and waste of time to check inconsistent
| parameter order and function naming from docs. I don't
| understand why people are so keen on defending these things.
| CiPHPerCoder wrote:
| That was fixed already.
|
| https://wiki.php.net/rfc/named_params
| allendoerfer wrote:
| That's a good addition but not really a fix. A fix would be
| to have a consistent ordering of parameters and a
| conceptually consistent interface.
| jw1224 wrote:
| Laravel's "Collections" library [1] solves this, and is a
| breath of fresh air. Easily one of the best features of the
| framework (though you can also use it as a separate package,
| outside of a Laravel app [2]).
|
| It's simple to use, but extremely powerful. I pretty much
| always use Collections over native array functions these days.
|
| [1] https://laravel.com/docs/9.x/collections
|
| [2] https://github.com/illuminate/collections
| user3939382 wrote:
| Doctrine Collections similarly solves this.
| [deleted]
| Epskampie wrote:
| For an always up-to-date overview check out PHP RFC Watch
| https://php-rfc-watch.beberlei.de/
|
| Not a dig against sticher.io, love their to the point
| descriptions.
| muglug wrote:
| The site doesn't make it clear, but this isn't a full list, since
| PHP 8.2 will be accepting RFCs until mid-July (see
| https://wiki.php.net/todo/php82 for the release timeline).
|
| Even though it's incomplete, this page helps to generate
| excitement about PHP generally, which is a good thing -- the PHP
| community sometimes struggles with its reputation as a dying
| language.
| [deleted]
| kalev wrote:
| Funny thing is this reputation is imo being upheld by PHP users
| themselves, for example in PHP tutorials comparing to different
| languages.
| whenlambo wrote:
| Dying?
|
| "PHP is the most used server-side programming language
| globally"
|
| https://kinsta.com/php-market-share/
| kstrauser wrote:
| I think those can both be true. For instance, Google
| Trends[0] shows interest in it falling significantly with
| time. However, Wordpress is written in it, so a lot of people
| are still running PHP on their servers.
|
| I wonder if PHP:Wordpress is becoming like Ruby:Rails, where
| there's no reason you can't use the language for other
| things, but in practice it's mostly used for one specific
| purpose?
|
| [0] https://trends.google.com/trends/explore?date=all&geo=US&
| q=%...
| jotm wrote:
| It's not only Wordpress. There's also Drupal, Joomla and
| the myriad of plugins written for them, as well as forums
| software like Vanilla, phpbb and vBulletin. Actually, I
| predict a resurgence in forum software popularity as more
| people realize Reddit is for suckers; there is of course
| Discourse, but that's like New Reddit, looks cool until you
| use it and realize it's kinda shit.
| xorcist wrote:
| Try discourse with javascript disabled, much more usable.
| antifa wrote:
| > Discourse looks cool until you use it and realize it's
| kinda shit
|
| What do you recommend instead?
| the_only_law wrote:
| I've thought about returning to old times and spinning up
| a phpBB site.
| ipaddr wrote:
| Smf reminds me of old times. phpBB is still active.
| the_only_law wrote:
| Yeah, I just haven't used one in over a decade. Most of
| the communities I used to use had one.
| kstrauser wrote:
| Those are rounding errors compared to WordPress[0]. BTW,
| I'm neutral on WP. I've used it before and it was fine,
| but I don't work for Automattic or anything. I think it's
| the elephant in the PHP room, though. No one can claim
| that PHP is _only_ used for WordPress, but I bet that the
| majority of PHP installations are there because that 's
| what WP happens to be written in.
|
| [0] https://w3techs.com/technologies/overview/content_man
| agement
| chippiewill wrote:
| I don't think it's exactly synonymous with market share.
|
| The numbers are a bit distorted due to a few "killer apps"
| like Wordpress. I think if you looked at it in terms of
| number of developers using a language then it will have
| fallen quite precipitously.
|
| Dying is an exaggeration anyway, I think PHP is just no
| longer in it's glory days of the 00s.
|
| I'm personally hopeful that PHP might have a renaissance. The
| language developers have done a really good job of
| modernising it and removing the really nasty stuff over the
| last ~7 years, I think it's just the standard library that's
| left as a significant eyesore. Unfortunately Nikita's stepped
| down from PHP development recently and he was a real
| powerhouse so it remains to be seen if it can maintain its
| trajectory.
| dabernathy89 wrote:
| They said "reputation", not that PHP was _actually_ dying
| antifa wrote:
| Mostly people who've never written a line of php in their
| life assuming the same about everyone else.
| tored wrote:
| PHP 8.2 will probably not add many new features more of cleaning
| up the language (still important ofc), similar to PHP 7.2 or PHP
| 7.3.
|
| PHP 7.4 did however add a lot of interesting features like FFI,
| JIT, preloading, typed properties and arrow functions.
|
| Thus if PHP 8 development will by any way similar how PHP 7 was
| developed you need to hang in there for at least one more release
| but probably two more releases or wait for PHP 9.
| kijin wrote:
| Makes sense. It takes time for new features to get traction and
| iron out any missing parts that the original RFC didn't think
| of. Lots of software projects alternate between new-feature
| releases and cleanup/bugfix/housekeeping releases. Users also
| like to have a period of stability before they need to change
| things up again.
| bufferoverflow wrote:
| > and false as standalone types
|
| That's just wrong. Boolean is the type. False is just one
| possibile value of that type.
| Dragony wrote:
| Sadly there are a number of functions in the PHP standard
| library that literally never can return true. Often they return
| a resource or false, for example. In those cases the `false`
| type is more accurate than boolean. That's the reason for the
| distinction.
| cestith wrote:
| I don't think the argument is against unit types. I think the
| argument is against calling one "false", and I agree. If
| you're going to have a reserved keyword "false", have "true"
| and "false" as Boolean. If you want a unit type to mean
| "failed", "failure", "incomplete", or something, use one of
| those words.
| djbusby wrote:
| Good design choice for new lang. What about when there is
| 20+ years of history? Can't just move fast and break
| things.
| cestith wrote:
| Isn't this an announcement about introducing this and
| other changes into the language now?
| masklinn wrote:
| It's really an announcement about the formalisation of
| existing API patterns: returning FALSE on failure
| (regardless of the "success" type) is part of many old
| php apis, this change allows properly typing those.
| kijin wrote:
| It actually makes a bit of sense if you think of Bool as a
| class instead of a primitive type, and True and False as
| subclasses of Bool. So a function can either declare its
| return type as "bool", or as the more specific "false".
| True is simply not implemented.
|
| PHP isn't exacly an "everything is an object" language, but
| it's been slowly moving in that direction for years,
| replacing most callables, resources, etc. with
| corresponding objects. I wouldn't be surprised if the
| designers are approaching this issue with an object-
| oriented mindset, though it still feels wrong to make an
| exception for only one half of a boolean pair.
| steve_adams_86 wrote:
| This works fine in TypeScript. You can specify a type as
| boolean, true, or false, and it works exactly as you'd
| expect. I don't see an issue with doing the same in PHP
| bow_ wrote:
| Introducing `false` as a standalone type but not `true`
| is what makes this weird. Generic, literal returns are
| fine. Python is another language that has it [1].
|
| The introduction of the RFC [2] also still mentions
| `false` is of type bool:
|
| > null corresponds to PHP's unit type, i.e. the type
| which holds a single value. false is a literal type of
| type bool.
|
| But why call it bool if `true` is not a standalone type
| too?
|
| [1] https://docs.python.org/3/library/typing.html#typing.
| Literal
|
| [2] https://wiki.php.net/rfc/null-false-standalone-types
| cestith wrote:
| It would not surprise me any to have a Boolean type and
| have both true and false as restricted subtypes of that.
| However, in this case of it being used primarily as a
| return type for failure in a function call, I think
| they're conflating the tradition from C-style languages
| of returning a false-ish value in-bound rather than
| creating a type specific to the error condition.
| masklinn wrote:
| > I think they're conflating the tradition from C-style
| languages of returning a false-ish value in-bound
|
| It's not really conflation when php has been doing that
| since forever as it originally was little more than a
| thin shim over C (you can see that in lots of older APIs
| e.g. the mysql_ stuff is straight transcribed from the C
| library).
| cestith wrote:
| Oh, it makes sense. It would just make more sense to me
| if the unit type for an error or failure was called
| "error" or "failure". They're sort of overloading the
| idea of true/false here with the historical baggage of
| returning a value that evaluates to false-ish for
| failure, then codifying that in a new type rather than
| taking the chance to make the new type a clean break from
| that in-band concept.
| kijin wrote:
| What else do you expect, PHP has its roots in a bunch of
| wrappers around C functions with in-band error signaling.
| Those functions are like grandpa's old watch that you
| just can't bring yourself to throw away even though it
| doesn't match any of your new outfits. Mama WordPress
| would be mad. :)
| cestith wrote:
| I appreciate the humor.
|
| On a little more serious note, Perl is an earlier
| language and even more closely tied to C tradition. Many
| (but not all) of its built-ins and library functions and
| methods return undef rather than 0 for failure.
| mikojan wrote:
| "false" is a literal type in TypeScript, Coq, Agda, Idris,
| Scala.
| zozbot234 wrote:
| False in Coq/Agda/Idris is a zero type, not a unit type. True
| is a unit type. Now PHP is making the opposite choice.
| Confused enough?
| blowski wrote:
| It's for backwards compatibility with functions that return
| either the expected value (maybe an array or a string) or false
| (never true). So you can use it in a union like `foo():
| string|false {}`. In that sense, it's not a boolean because it
| will only ever be a string or false.
| tyingq wrote:
| That makes sense, though you would want a linter or something
| to check that callers are doing "=== false" and not "==
| false", since falsy (but not false) values would match the
| latter.
| blowski wrote:
| If you're using `==` in 2022 without testing or linting,
| this would be the least of your problems. Also, with the
| strict_types declaration, it wouldn't be coerced.
| tyingq wrote:
| " == false" is sprinkled all over some pretty popular
| products, like Wordpress.
| masklinn wrote:
| > That's just wrong. Boolean is the type. False is just one
| possibile value of that type.
|
| Having false and true be singleton types is perfectly
| cromulent.
|
| That's how Smalltalk has been doing it for 40 years, and why it
| can do without control structures: Boolean
| subclass: False [ ifTrue: trueBlock ifFalse:
| falseBlock [ ^falseBlock value ]
| "..." Boolean subclass: True [
| ifTrue: trueBlock ifFalse: falseBlock [
| ^trueBlock value ] "..."
| thibran wrote:
| The feature I missed the most when writing PHP was something like
| a pipeline operator to easily chain functions.
|
| https://stackoverflow.com/a/55143445
| tyingq wrote:
| It was considered, but declined: https://wiki.php.net/rfc/pipe-
| operator-v2
|
| Laravel has pipelines, but it's not generically useful for
| existing functions. https://dev.to/abrardev99/pipeline-pattern-
| in-laravel-278p
| bovermyer wrote:
| So essentially, PHP 9.0 is a different language, and not
| compatible with the vast majority of PHP applications out in the
| wild.
|
| This isn't necessarily a bad thing, but it does mean that a lot
| of applications are going to be stuck on old versions.
|
| For my part... I think this will make me fully abandon PHP and
| just rewrite old apps in other languages, like Go and Rust.
| alberth wrote:
| >> "So essentially, PHP 9.0 is a different language
|
| How did you come to that conclusion from that post?
| bovermyer wrote:
| Perhaps I should have qualified the phrase "different
| language."
|
| It'd be more accurate to say 9.0 is a dialect, rather than a
| wholly separate language.
| tored wrote:
| You can of course argue that any major update that breaks
| backwards combability the slightest is a dialect of the
| previous version, but that is just silly. -
| Looking for PHP 8.2 dialect programmers! - I have
| only coded in PHP 8.1 dialect. - Sorry, won't do.
|
| The changelog tells you want you need to fix on existing
| code when upgrading and the manual usually gives you a
| workaround if it is something larger. And in this specific
| case you just add the attribute #[AllowDynamicProperties]
| to you dynamic class and be done with it.
| zozbot234 wrote:
| Is there an easy way of doing HTML templating with Go/Rust, as
| you would in PHP?
| [deleted]
| bovermyer wrote:
| Not as easily as in PHP, but yes.
|
| https://pkg.go.dev/html/template (for Go)
| johnmaguire wrote:
| IMO the template package in Go is kind of awful.
|
| The contextual escaping is very cool (although a little
| frightening given the complexity of it), but the ergonomics
| of parsing, nesting, and executing templates is very
| confusing IMO.
| 0des wrote:
| > the ergonomics of parsing, nesting, and executing
| templates is very confusing IMO
|
| Can you elaborate on this?
| steve_adams_86 wrote:
| I guess that depends on what you mean by "as you would in
| PHP". I assume everyone uses something like Twig these days,
| so in that case, absolutely. You even get compile time
| checking from Rust libraries like askama:
| https://github.com/djc/askama
| smt88 wrote:
| Rust has lots of template libraries. HTML templating is a
| solved problem that PHP doesn't uniquely do well anymore.
| oversocialized wrote:
| tored wrote:
| There is nothing in this blog post nor in the PHP 8.2 release
| that suggests that PHP 9.0 will be different language and not
| compatible with previous versions.
| [deleted]
| smt88 wrote:
| Major backward-incompatibility is a huge mistake. Python made
| it and had 10+ years of a mess with incompatible v2 and v3 code
| bases confusing and infuriating people.
| TheRealPomax wrote:
| Yep, thankfully PHP respects semantic versioning. Much like
| Python 3 broke 2.x compat, PHP 9 breaks 8.x compat. Although
| the truly backward compat breaking changes are quite few, and
| uplifting 8 to 9 will be fairly low effort (and almost
| certainly something that linting can spot for the vast majority
| of code bases with near-trivial fixes).
|
| We had to do this when we went from v4 to v5, we had to do this
| when we went from v5 to v7, we had to do this (but less so)
| going from v7 to v8, so if having to do this from v8 to v9 as
| well is suddenly too much work, either you haven't been using
| PHP for very long, or you took a weird moment to suddenly take
| exception with codebase migrations. Especially as, of all the
| version updates so far, 9 promises to be by far the most worth
| it.
| yccs27 wrote:
| Now that you put it this way - is this going to be another
| python 2-to-3 problem? I hope they have some solution to
| quickly bring everything to the new version; the proposed
| changes seem reasonable though.
| ipaddr wrote:
| Not a fan of Deprecate dynamic properties. This is one
| change/direction that may make me reconsider php in the future.
___________________________________________________________________
(page generated 2022-04-25 23:02 UTC)