On Tue, 17 Sep 2019 at 01:10, Mike Schinkel <m...@newclarity.net> wrote:
> But as I said before, naming is hard — except for abstract examples where > you can just name it "Something" :-) — and developers often don't know what > object schema they will need until they have written much of the code. So > the ability to have a syntax that supports stepwise refinement rather than > starting with one and having to switch to the other makes a lot more sense > to me. > > Allowing developers to start with doSomething(int $a, object $options = > null) and then later refine the code to doSomething(int $a, > SomethingOptions $options = null) creates less discontinuity for development > There is a tip that I picked up somewhere that if you're struggling to name something (e.g. a function or a class), it may be because you've defined its responsibilities poorly, and it needs splitting or merging. I, too, work with a legacy codebase that makes heavy use of $params arrays, and I frequently see things like `$params = array_merge($product, $customer); $params['sendEmails'] = true;` and then a bunch of functions whose docblocks say basically "@param array $params No idea what's in this, we just pass it on somewhere else". There is no better name for the $params array because it has no particular responsibility, it's just a bag of data. So I'm unconvinced by the anonymous class -> named class refactoring path (and even more so with some of your further proposals like populating named parameters from an object), because I don't actually want to end up with a SomethingOptions object with 50 unrelated properties. What I want to end up with is a function signature like doSomething(Product $product, Customer $customer, bool $sendEmails). The step in between might look like doSomething(Product $product, array $params) or even doSomething(array $product, array $customer, bool $sendEmails) rather than doSomething(object $params). > rather than giving them only one option for anonymous class initializer, e.g. the array initializer syntax? I'm not a fan of (object)$array, or of stdClass in general, but I think the solution to that is to expand the existing "new class" syntax with a way to capture lexical variables. I understand the desire to make a new syntax that does as much as possible, but I think we have a few different combinations to achieve that: - object initializers & simple anonymous class initializers look the same; named parameters may or may not look similar; complex anonymous classes have to use a different syntax - object initializers are just constructors with named parameters; anonymous class definitions don't look similar, but support both simple and complex cases in one syntax Either way, the whole set of features isn't going to be implemented in one go, so we don't need to work out all the details, just a direction of travel. Regards, -- Rowan Tommins [IMSoP]
