• Mikey (unregistered)

    /* Frist function ** ** Just for consistency and ** ease of maintenance, let's declare our own function **/ function frist() {

    // Initialise output variable $output = "frist";

    // output the output echo $output; }

  • GotCred (unregistered)

    Frist - and not SPAM

  • (cs)

    Did he reimplement PHP in the end?

  • Myth (unregistered)

    Frist?

    Akismet thinks this is spam. It probably is.

  • Myth (unregistered) in reply to Myth
    Myth:
    Frist?

    Akismet thinks this is spam. It probably is.

    Damn you Akismet. Three other comments while I battled you.

  • Ben Jammin (unregistered)

    You're a phony

    Askimet is a phony too.

  • Anon (unregistered)

    That's... somewhat pointless but not totally stupid.

    PHP is a notorious mess, and he's trying to build an abstraction layer on top of it. To improve the tool, really. It's the same thing framework developers are trying to do, just on a much smaller scale.

  • XXXXX (unregistered)

    I had a coworker who wanted to wrap everything. Our company has a set of common shared libraries for common functions. My coworker thought we should wrapper any calls to the company's common libraries from our project in our project's own utility functions. That way, if our company's internal software (our project) was ever moved to another company, it would be easy to swap in a different library.

  • Manadar (unregistered)

    And in the end it turns out they actually needed a variant of base64. The new programmer only has to edit those two functions with the correct implementation.

    That's sometimes how those things work out. If you suspect your implementation of base64 is not what PHP offers, please please please, do something like this. Even if that means your implementation of base64 is not base64.

  • Ronan (unregistered)

    He should have made it generic.

    function call_php_function($function, $parameter){ //Initialisation of return value $return_value = '';

    //Call of the php function $return_value = $function($parameter);

    //let's return te result return $return_value; }

    of course, you'd have to do that multiple times to account for the number of parameters for different php function. function call_php_function_1_parameter($function, $parameter) function call_php_function_2_parameters($function, $parameter1, $parameter2) etc...

  • Jeff (unregistered)

    Looks like he wrapped the function to make it easier to fix if php updates end up changing the name or the method of calling it. Seems pretty standard to me. #ifdefs do this ALL THE TIME in C/C++ code to handle differences in compiler and architecture.

  • HatWieldingManiac (unregistered)

    It's a good start but not enough - what if his interface changes? Sure, he says it's for ease of maintenance but you can't trust other people.

    Thus my solution to this WTF:

    <?php /* Base 64 Encoding function ** ** For even more consistency and ** ease of maintenance, let's declare ** a wrapper around our base64Encode. ** ** Allows for partial refactoring and other ** enhancements if needed in the future. **/ function base64EncodeWrapper($plain) { // Initialise output variable $output = ""; // Do encoding $output = base64Encode($plain); // Return the result return $output; } /* Base 64 decoding function ** ** For even more consistency and ** ease of maintenance, let's declare ** a wrapper around our base64Encode. ** ** Allows for partial refactoring and other ** enhancements if needed in the future. **/ function base64DecodeWrapper($scrambled) { // Initialise output variable $output = ""; // Do encoding $output = base64Decode($scrambled); // Return the result return $output; } ?>
  • MB (unregistered)

    This is not a WTF, if this is what a WTF looks like for you, then you are lucky, a true WTF would be him implementing his own base64decode / encode, each time, everywhere, incorrectly...

  • Ec (unregistered)

    So wrapped the native function in a CamelCase name. Sounds sensible to me. And he even commented it with sort of that explanation!

  • steve (unregistered)

    seems like a great way to fix deprecated methods in the future....

  • (cs)

    I can respect the intent to apply some consistency to the calling conventions for PHP's internal functions: some are underline_separated, some are camelCased, some lead with the subject, some with the verb, and no two functions that take haystack and needle parameters take them in the same order.

    These new function definitions still aren't very good, though. The code's needlessly explicit in a way that makes me believe the coder doesn't understand how 'return' works, and the comments are completely useless.

  • Tractor (unregistered) in reply to Anon
    Anon:
    That's... somewhat pointless but not totally stupid.

    PHP is a notorious mess, and he's trying to build an abstraction layer on top of it. To improve the tool, really. It's the same thing framework developers are trying to do, just on a much smaller scale.

    Agreed, this is actually quite a sane thing to do. It keeps the function names consistent, god knows the PHP developers didn't.

  • foo (unregistered) in reply to veggen
    veggen:
    Did he reimplement PHP in the end?
    #!/bin/sh

    PHP interpreter
    

    PHP runs natively but just for consistency and
    

    ease of maintenance, let's declare our own script
    

    callPHP ()
{
    

    Initialise output variable
    

    exit_status=42
    

    Call PHP
    

    php "$@"
    

    Get the result
    

    exit_status=$?
    

    Return the result
    

    return $exit_status
}
    

    Initialise output variable
    

    return_status=42
    

    Call PHP calling function
    

    callPHP "$@"
    

    Get the result
    

    return_status=$?
    

    Return the result
    

    exit $return_status
  • corroded (unregistered) in reply to steve
    steve:
    seems like a great way to fix deprecated methods in the future....

    Bingo. I've seen a sysadmin trawling through code to fix PHP removing a method that was used throughout the system. Now, admittedly he shouldn't have upgraded PHP without checking better... but having a wrapper for the function would have meant a single change rather than searching the entire code base for the method.

  • (cs) in reply to Tractor
    Tractor:
    Anon:
    That's... somewhat pointless but not totally stupid.

    PHP is a notorious mess, and he's trying to build an abstraction layer on top of it. To improve the tool, really. It's the same thing framework developers are trying to do, just on a much smaller scale.

    Agreed, this is actually quite a sane thing to do. It keeps the function names consistent, god knows the PHP developers didn't.

    And you know a language is really bad when even the trolls about it raise good points.

  • (cs)

    I applaud this guy for not using any magic functions.

  • Anon (unregistered) in reply to GotCred
    GotCred:
    Frist - and not SPAM

    Wrong and wrong again.

  • foo (unregistered) in reply to corroded
    corroded:
    steve:
    seems like a great way to fix deprecated methods in the future....

    Bingo. I've seen a sysadmin trawling through code to fix PHP removing a method that was used throughout the system. Now, admittedly he shouldn't have upgraded PHP without checking better... but having a wrapper for the function would have meant a single change rather than searching the entire code base for the method.

    By the logic, why not wrap everything, functions, variables, constants, files, networks, character sets, just everything. Anything might change some day, after all, and spending some effort to adjust later is certainly worse that spending 10 times the effort now. Fuck performance, Moore's Law will take care of that, right?

  • Anon (unregistered) in reply to PedanticCurmudgeon

    I resent that. I've never raised a good point in my life.

  • (cs)

    Clean code, new shoes And I don't know where I am goin' to.

    Standard functions wrapped tight,
    I dont need a reason why

    They leave running just as fast as they can. Cause every manager's crazy bout a sharp dressed man.

  • Not Bob (unregistered) in reply to Ronan
    of course, you'd have to do that multiple times to account for the number of parameters for different php function. function call_php_function_1_parameter($function, $parameter) function call_php_function_2_parameters($function, $parameter1, $parameter2) etc...
    That's not nearly difficult enough to debug. Why not use call_user_func_array? Then you can implement all PHP classes with a single class: 
    <?php
class allPHP{
    public function __call($name,$args){
	return call_user_func_array($name,$args);
    }
}
?>
  • gizmore (unregistered) in reply to Not Bob
    Not Bob:
    of course, you'd have to do that multiple times to account for the number of parameters for different php function. function call_php_function_1_parameter($function, $parameter) function call_php_function_2_parameters($function, $parameter1, $parameter2) etc...
    That's not nearly difficult enough to debug. Why not use call_user_func_array? Then you can implement all PHP classes with a single class: 
    <?php
class allPHP{
    public function __call($name,$args){
	return call_user_func_array($name,$args);
    }
}
?>

    You should at least break backwards compatibility with PHP4 by using type hinting. We have to move on!

    Similis: A mixture of an illness and a smiling doctor.

  • corroded (unregistered) in reply to Ronan
    Ronan:
    He should have made it generic.

    function call_php_function($function, $parameter){ //Initialisation of return value $return_value = '';

    //Call of the php function $return_value = $function($parameter);

    //let's return te result return $return_value; }

    of course, you'd have to do that multiple times to account for the number of parameters for different php function. function call_php_function_1_parameter($function, $parameter) function call_php_function_2_parameters($function, $parameter1, $parameter2) etc...

    Tsk, that's not enterprisey enough... and you can do it without duplicating function calls.

    function evil($function) { $args = func_get_args(); unset($args[0]); //removes function name

    foreach($args as $k => $a) {
    $var = 'var_'.$k;
    $$var = $a;
    $par[] = '$' . $var;
}

$list = implode("'",$par);
return eval($function.'('.$list.');');

    }

    echo evil('echo','lies'); //lies echo evil('echo',3+3); //6 echo evil('echo','3+3'); //3+3

    I apologise in advance for the current vomit coming out of your face.

  • fritters (unregistered) in reply to Ronan
    Ronan:
    He should have made it generic.

    function call_php_function($function, $parameter){ //Initialisation of return value $return_value = '';

    //Call of the php function $return_value = $function($parameter);

    //let's return te result return $return_value; }

    No. The better way is to set up a mapping using an Excel spreadsheet, then generate an XML configuration file.

    Then your code just needs to parse the XML file and follow the translations. This way if you ever need to change them or add more, you don't even have to make code changes!

    It's brillant!

  • iToad (unregistered) in reply to corroded
    Tsk, that's not enterprisey enough...

    Do not speak aloud of enterprisey PHP. By doing so, you could accidentally call up that which you cannot put back down. Some elder horrors must be left to slumber undisturbed.

  • my little phony (unregistered) in reply to foo
    foo:
    By the logic, why not wrap everything, functions, variables, constants, files, networks, character sets, just everything. Anything might change some day, after all, and spending some effort to adjust later is certainly worse that spending 10 times the effort now. Fuck performance, Moore's Law will take care of that, right?

    So, you've basically just described Java.

  • (cs) in reply to Anon
    Anon:
    I resent that. I've never raised a good point in my life.
    ...until now. For what it's worth, it's not really your fault. You didn't name the PHP functions, right?
  • Dr Doom (unregistered)

    In any other programming language this would definitely be a WTF but seen as it's PHP he's actually adding value by standardising the naming convention.

    <?wtf echo "the real WTF is PHP"; ?>
  • Tasty (unregistered) in reply to my little phony
    my little phony:
    foo:
    By the logic, why not wrap everything, functions, variables, constants, files, networks, character sets, just everything. Anything might change some day, after all, and spending some effort to adjust later is certainly worse that spending 10 times the effort now. Fuck performance, Moore's Law will take care of that, right?

    So, you've basically just described Java.

    Java, and C++ before it, are compiled languages so that performance can be optimized. Modern compilers can fold the wrappers as in-line code, and C++ has a qualifier for that.

    Also, Moore's Law is far less important than properly using the CPU's instruction set. Computers will change speed, materials and architecture that interpreters and compilers have to suit.

  • Daniil S. (unregistered)

    Seriously, this is the very first time on WTF that everyone is actually agreeing with the perp. The world has gone mad!!!

  • FragFrog (unregistered) in reply to Ronan
    Ronan:
    of course, you'd have to do that multiple times to account for the number of parameters for different php function. function call_php_function_1_parameter($function, $parameter) function call_php_function_2_parameters($function, $parameter1, $parameter2) etc...
    At the risk of taking a troll serious: fun_get_args allows you to create functions which take a variable number of parameters. I would generally advice against using it (having a function which behaves differently depanding on how many arguments you give it, is a sure way to make any consecutive developer blow his brains out), but there are a few situations where it can really make things easer.

    Ontopic: while I hate to admit it, PHP's own naming conventions are non-existent at best, and deliberately confusing at worst. I do not condone writing code for the sake of writing code either, but this is not necessarily a bad idea. I have seen far, far worse PHP.

  • Yoshord (unregistered)

    Even if the wrapper function is neccessary, the number of lines isn't. It could surely be shortened to 

    function base64Encode($plain) {
return base64_encode($plain);
}

  • Richard (unregistered) in reply to FragFrog

    Just what PHP needs: Perl like functions.

  • Nagesh-saki (unregistered) in reply to Daniil S.
    Daniil S.:
    Seriously, this is the very first time on WTF that everyone is actually agreeing with the perp. The world has gone mad!!!

    Nah, just the first time all commenters are trolls. BTW, I agree with the perp.

  • frits (unregistered)

    Seriously guys, what software dev isn't a phony?

  • Jonathan (unregistered)

    $meToo++;

    Seriously, whose kneecaps do I break for DEPRECATING split()? I'm a little surprised that Rasmus made it out of Penguicon with all his extremities a couple of years back. Anyone starting a new project in PHP in this day and age is either drunk or mismanaged.

  • bart (unregistered) in reply to MB

    Agreed.

    I am often shocked at those that are quick to judge.

  • (cs) in reply to Jonathan
    Jonathan:
    $meToo++;

    Seriously, whose kneecaps do I break for DEPRECATING split()? I'm a little surprised that Rasmus made it out of Penguicon with all his extremities a couple of years back. Anyone starting a new project in PHP in this day and age is either drunk or mismanaged.

    Direct string manipulation is so 1990s. Everyone knows the extra level of indirection added by using regular expressions adds more value.

  • foo (unregistered) in reply to Yoshord
    Yoshord:
    Even if the wrapper function is neccessary, the number of lines isn't. It could surely be shortened to 
    function base64Encode($plain) {
    return base64_encode($plain);
}
    Haven't you read the coding standards?

    • Everything must be wrapped (also wrappers, if possible)

    • Every variable must be initialized (even if the first thing you do with it is set it)

    • Never do two things in one line/statement (not even a function call and return)

    • Every line must be commented (even if self-explanatory)

    And that's just the start. The other 42000 rules get really absurd.

    (Yeah, would be more funny if it weren't so common.)

  • Nagesh-saki (unregistered)

    There is no programming problem that can't be solved by adding another level of indirection, except of course, too many levels of indirection.

  • Anonymous (unregistered) in reply to Jeff
    Jeff:
    Looks like he wrapped the function to make it easier to fix if php updates end up changing the name or the method of calling it. Seems pretty standard to me. #ifdefs do this ALL THE TIME in C/C++ code to handle differences in compiler and architecture.
    This excuse doesn't add up when you notice the insistence in not just wrapping the function call and instead add a variable and assignments and lame stuff.

    Worse, because in php, you can make "just-in-case wrappers" by just doing:

    base64Encode = base64_encode

    Not like making wrappers for each php function before it gets changed is quite unnecessary. Regardless of the mess fanboys call php to be.

  • (cs) in reply to Jonathan
    Jonathan:
    $meToo++;

    Seriously, whose kneecaps do I break for DEPRECATING split()? I'm a little surprised that Rasmus made it out of Penguicon with all his extremities a couple of years back. Anyone starting a new project in PHP in this day and age is either drunk or mismanaged.

    Shit! Didn't know this. Haven't touched PHP with a pole since version 3 and believe me, I'm not turning back.

    Anyway, if anyone thinks this is a good idea, it's because we're talking about PHP here people. In any other sane language you wouldn't have to worry about lossing base64... shit, Java have had Vector deprecated for 20 years but you can still use it.

  • Jim (unregistered) in reply to Nagesh-saki
    Nagesh-saki:
    There is no programming problem that can't be solved by adding another level of indirection, except of course, too many levels of indirection.

    I'm pretty sure if you create enough indirection, you summon Cthulu, or create a black hole, in which case you've solved every problem on Earth.

  • (cs) in reply to frits
    frits:
    Jonathan:
    $meToo++;

    Seriously, whose kneecaps do I break for DEPRECATING split()? I'm a little surprised that Rasmus made it out of Penguicon with all his extremities a couple of years back. Anyone starting a new project in PHP in this day and age is either drunk or mismanaged.

    Direct string manipulation is so 1990s. Everyone knows the extra level of indirection added by using regular expressions adds more value.

    What's that old chestnut? Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.

  • derk (unregistered)

    somebody has some $plain-in' to do!

Leave a comment on “The Phony”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article