On 5/3/2016 10:22 PM, Ryan Pallas wrote: > I have to disagree, I haven't seen an example of rewriting the original > example from the RFC in a more expressive AND readable way. Yes, you can > use lots of intermediate variables, but this makes the code HARDER to read > QUICKLY which is entirely the point of a syntatic sugar addition like this. > Syntactic sugar makes a language sweeter, and more palatable. Like cane > sugar makes your cookies taste good, but doesn't make them more nutritious. >
Opinions you know but I am still waiting for that example. On 5/3/2016 10:22 PM, Ryan Pallas wrote: > This breaks dependency injection, and makes testing harder. You now depend > on an array of data which is accessed internally, and can only minimally > control it's contents in a testing environment. > Why do you need dependency injection in the most outer point of your application? This should be tested with your acceptance/integration tests and nothing else. How many unit tests have you written for your Symfony app kernel lately? A rather extreme example of such a /most outer/ but you know how it is with constructed examples: http://www.yegor256.com/2014/10/03/di-containers-are-evil.html#the-right-way On 5/3/2016 10:22 PM, Ryan Pallas wrote: > Again, how do I dependency inject a config during testing to make sure I > build the dic correctly? I'm assuming you're using a bunch of temporary > properties? Also you just made adding a step significantly harder, what if > from building the app, I need to build another layer build for the router, > for |> I add ONE line of code, for yours I edit the build function in the > right location, and change the build router function to load from a > different property, and build another boilerplate function to build this > new thing, and add another property to hold this new thing... WHOA that's a > lot more steps, and a MUCH higher risk of a mistake! > Again, this is the most outer place of everything. I mean, all frameworks and applications were and are able to solve these issues easily, nicely, and testable. Just because my /proposed/ solution to an example that is constructed in the first place is not as nice as those solutions does not make the examples better. :P On 5/3/2016 10:22 PM, Ryan Pallas wrote: > Again, you're solution is to use OOP, but the pipe operator's purpose is to > make procedural code cleaner. Not one of your solutions maintained a > procedural interface, and therefore is not an argument against the |> > operator. The purpose of this operator is syntactic sugar, which "is syntax > within a programming language that is designed to make things easier to > read or to express. It makes the language "sweeter" for human use: things > can be expressed more clearly, more concisely, or in an alternative style > *that > some may prefer*."[1] (emphasis mine). Its not designed to solve a problem > of how can I do this thing, but how can I write this thing such that my > team might be able to understand it better. > > Yes, you can rewrite these examples in an entirely different way, but now > you're not comparing apples to even other fruit (procedural vs OO is not > the same). The point of this is to take a very common pattern (nesting many > procedural calls) and make it easier to read and manage later. > foreach (scandir($arg) as $path) { if ($path !== '.' && $path !== '..') { $ret[] = getFileArg($arg . DIRECTORY_SEPARATOR . $path); } } What can I say ... -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
