51–60 of 217 posts
Mandatory function arguments: function foo($arg1,$arg2) { return; } foo('bar'); Warning: Missing argument 2 for foo() Lame. But omitting arg2 is allowed if you give it a default value: function foo($arg1,$arg2=FALSE) { return; } Blah. Instead I'd rather make arg2 truly optional just by testing if it's defined.
Earlier quoted context omitted.
compact() + extract() is the closest you get. $foo = 123; $bar = getSomeBar(); myFunction(compact('foo', 'bar')); function myFunction($kwargs) { $foo = SOME_DEFAULT_VALUE; extract($kwargs); if ($foo > 5) { ... } } If you want to `sanitize' which arguments can be passed that way, use extract(array_intersect_key($allowed, $kwargs)); ((EDIT: or use EXTR_IF_EXISTS)). Nb., extract() works on any associative array, you don…
Why would this be any better than just passing in a map of the parameters as the sole parameter? myFunction($parms=array()) { ... } $parms = array('foo' => 'bar', 'baz' => 'yaz'); test($parms);
Oh, and there's even that EXTR_IF_EXISTS -- so my silly idea to sanitize with array_intersect_keys() was totally unneeded. Make it
$foo = 123;
$bar = getSomeBar();
$coot = 'boot';
myFunc(compact('foo', 'bar', 'coot'));
function myFunc($kwargs) {
$foo = 1;
$bar = 'xyz';
extract($kwargs, EXTR_IF_EXISTS); /* sanitization: $coot will NOT get extracted
because the function doesn't expect / support that argument */
...
}Mandatory function arguments: function foo($arg1,$arg2) { return; } foo('bar'); Warning: Missing argument 2 for foo() Lame. But omitting arg2 is allowed if you give it a default value: function foo($arg1,$arg2=FALSE) { return; } Blah. Instead I'd rather make arg2 truly optional just by testing if it's defined.
Mandatory function arguments: function foo($arg1,$arg2) { return; } foo('bar'); Warning: Missing argument 2 for foo() Lame. But omitting arg2 is allowed if you give it a default value: function foo($arg1,$arg2=FALSE) { return; } Blah. Instead I'd rather make arg2 truly optional just by testing if it's defined.
If I don't require args: function foo($arg1=null, $arg2=null) {return;} foo(); // return no error
This is great for me, when I am writing an API and have some args that are required and others that are optional.
I'd love to see similar lists for other languages. I've been coding in MATLAB as of late, for instance, and rediscovered my hatred for the fact that you can't index the output of a function without assigning to a temporary variable. For instance, `foo(args)(:)` causes an error. You have to use `X = foo(args); X(:)` instead. That makes me just as sad as some of these PHP sadnesses.
The parser emits weird error messages because it is a very simple yacc grammar. (And because they turn off yacc's "produce better error messages" mode.) If you want good error messages, it's going to cost you -- just read perl's toke.c if you don't believe me. Good error messages cost a lot.
What makes me sad is that people will defend this horrible language to the death, regardless of how many problems there are with it. I don't get it; we know how bad PHP is, so why do people fight so hard? Oh, and to demonstrate: "PHP has no native Unicode type, no native Unicode handling, and cannot treat Unicode strings as strings." This true statement, composed of three observations about deficiencies in the langua…
Seems logical to me. These defenders are presumably professional PHP developers. They're presumably supporting their families by coding PHP. The more widely-spread the language is, the more it's used for new projects, the more lucrative and interesting their work will be.
And here you are, making a fuss, and many of these people may know ONLY PHP. And you're trying to argue that their most valuable skill should be put on the trash heap.
That's why THEY fight so hard: They're feeding themselves with the language.
Now, why do YOU fight so hard against them?
Earlier quoted context omitted.
> making the switch in if() be a boolean only What exactly is the alternative? If there's any problem here it's automatic coercion.
in statically typed languages like Java, C#, Scala and C++ people are always screwing this up most languages have some screwed-uppedness about collections, both intrinsic to the language and that gets introduced by people who make APIs that aren't well designed. for instance, arrays and Lists are often not quite perfectly uniform (and it's often a thoughtless arbitrary choice if people decide to return you one or the…
Either the types that are returned are scala collections, or they're java collections. If you want to treat java collections like scala collections you can always `import JavaConversions._` and huzzah, shallow conversions and collection uniformity.
Finally, if something has the possibility of being null, you can use the option construct, e.g.
if (Option(someListThatMightBeNull).getOrElse(List()).isEmpty) { ... }
Option(someListThatMightBeNull) match {
case Some(list) => // do something...
case None => // do something else...
}
There's a lot of valid points there, but "#33 Cannot override private methods with a subclass" is the right behavior. That's exactly what private is for, and it's important to know that such names are non-colliding and you can rely on their implementation. Use protected for overridable methods. You shouldn't mock or directly test private methods in unit tests — they're not part of the interface!
Come to think of it... public/protected/private is a dumb idea in C++ and Java, too.