You probably can’t implode them.
If I did this in Laravel (or any other equivalently modern OO-first environment), my array internally isn’t a list of names. It’s an array of author objects. (It might even be something resembling Laravel’s Collection helper which definitely is not an array)
You cannot just implode a list of objects unless you’ve gone out of your way to seediness specific methods to say to PHP “if someone tries to use this object as a string, do this with it”
But this is really more a case combined with the first thing: you probably have a book object with its array of author objects and you might want to let other parts of the code have access to the real array, but they can have a pre-made digest format.
Really it’s about making it easier to define ways to get at the data an object already has. You’re thinking about my example solely in the context of that example, when that’s really not the intent of the feature.
OK, better example: I have a system that handles money. Everything is done in fixed precision for accuracy. I have an object that represents the product with its price, in home currency. What I also will need from time to time is the price of that product in Stripe terms. For those not familiar with Stripe’s API, a product that is USD 149.99 is not sent to Stripe as $149.99 - rather it’s sent as 14999 US cents.
Since I know I’m going to need the price for Stripe on various things, I define a new property in the current longhand way that says “get me the current actual price, then convert it to what Stripe wants” meaning that I have my product and can ask for $product->price_regular and get its price for normal purposes as well as ask for $product->price_stripe and get it ready formatted for Stripe without having to duplicate the logic everywhere I would otherwise need to do the conversion. I also never want to allow anything to override this value.
Similarly I can define $product->tax_amount as a property where the rest of the system can just trust that the product knows how much of its own price is taxable and therefore how much tax is liable.
What we’re really saying here is that in the pre 8.4 world we can define properties that are either read/write or not accessible (with no easy gated update method) and any additional behaviour is much more longhand, and that in 8.4 we can very easily define any type of attribute we like and make it very easy to define “if you get asked for this, here is what you do and if you get asked to update it, here is what you do” including “you can look but you can’t touch” attributes and entirely derived or computed attributes that are made from something else.
If I did this in Laravel (or any other equivalently modern OO-first environment), my array internally isn’t a list of names. It’s an array of author objects. (It might even be something resembling Laravel’s Collection helper which definitely is not an array)
You cannot just implode a list of objects unless you’ve gone out of your way to seediness specific methods to say to PHP “if someone tries to use this object as a string, do this with it”
But this is really more a case combined with the first thing: you probably have a book object with its array of author objects and you might want to let other parts of the code have access to the real array, but they can have a pre-made digest format.
Really it’s about making it easier to define ways to get at the data an object already has. You’re thinking about my example solely in the context of that example, when that’s really not the intent of the feature.
OK, better example: I have a system that handles money. Everything is done in fixed precision for accuracy. I have an object that represents the product with its price, in home currency. What I also will need from time to time is the price of that product in Stripe terms. For those not familiar with Stripe’s API, a product that is USD 149.99 is not sent to Stripe as $149.99 - rather it’s sent as 14999 US cents.
Since I know I’m going to need the price for Stripe on various things, I define a new property in the current longhand way that says “get me the current actual price, then convert it to what Stripe wants” meaning that I have my product and can ask for $product->price_regular and get its price for normal purposes as well as ask for $product->price_stripe and get it ready formatted for Stripe without having to duplicate the logic everywhere I would otherwise need to do the conversion. I also never want to allow anything to override this value.
Similarly I can define $product->tax_amount as a property where the rest of the system can just trust that the product knows how much of its own price is taxable and therefore how much tax is liable.
What we’re really saying here is that in the pre 8.4 world we can define properties that are either read/write or not accessible (with no easy gated update method) and any additional behaviour is much more longhand, and that in 8.4 we can very easily define any type of attribute we like and make it very easy to define “if you get asked for this, here is what you do and if you get asked to update it, here is what you do” including “you can look but you can’t touch” attributes and entirely derived or computed attributes that are made from something else.
no going out of your way and its not seediness 
IE also, not seedy 
