Is learning all PHP functions necessary? - php

Is it inevitable that all php functions will be used sooner or later when developing applications using php? Should only the required functions be learned to complete a project or should all functions be briefly understood before working on programs using php?
The List:
PHP Function List
Also is there a benefit to learning deprecated functions from previous releases of php besides legacy applications?
I have worked quite a bit developing applications using the .NET framework (c#) and found it extremely helpful to understand mainly how the majority of classes work before undertaking a project. Before that it seemed like I was constantly looking back and forth between coding and documentation, and not that we should'nt be reading the documentation but that it takes the fun out of coding when you can't go a statement without looking at the documentation.
Now I have made basic applications using PHP, and the majority of it has been the way I just described. Can I get your thoughts on how functions in PHP should be approached?

It is impossible to learn all functions available in the PHP standard library. Impossible I say.
There are a few handful of functions you'll need every day, and you'll discover them rather quickly and learn them by heart simply by using them. Beyond that there are hundreds of specialized functions you'll need every once in a while, depending on the project. You'll probably need to look up their specifics whenever you need them. Beyond that there are thousands upon thousands of functions you'll rarely need, if ever. You'll need to be able to find those when the need arises, but not any sooner.
The best way is to keep the manual close at hand and search it whenever you think "there should be a function for that". You'll do this a lot in the beginning and less often later on.
Feel free to skim the manual for function groups, you may discover that there are functions for stuff you didn't even know you could do. That may be valuable knowledge some day. Do not try to memorize everything in detail though. It won't stick anyway and only bore you to tears.

It should be approached as with any other language - you try to code something, get stuck, look up the docs if you find something related to your problem and use that. Otherwise you extend your research. There is no need to learn everything and anything. Personally, I don't see the point of reading about all functions simply to have read of them. Why should I, if I don't need them? Even though this is not coding directly, YAGNI (you ain't gonna need it) applies here as well. Learn about the functions when the need arises, not simply because you can.

IMHO, you should understand what certain function does rather then how it is doing it.. Obviously there are exceptions of functions that are similar (i.e. str_replace vs preg_replace or print vs echo - mostly string functions) and knowing how they work might give you an insight of performance.
Learning ALL php functions is not really necessary as you will not need them in everyday coding. You'll learn as you go (e.g. you need to manipulate and array; then you go and read all PHP array function and see if any suits the need for your problem. rather then doing it another way around. learning all php functions and start coding)

I can only support th answers given...
It is more or less impossible because there are a lot of functions, and when you have learned all the function there are functions you do not know they exist.
You have no big benefit comparing to the time you need to learn them. All important functions you will use every day and so learn them by using them.
Every day there are new libraries, or new versions of existing and useful libraries, every day some other programmer writes a new function and post this function in one of the millions pages on the web.
When you need some special funciton, you will use the manual, or if it is some exotic function use google. And when there are no solution for you problem, you will code som own funcitons and libraries and use them instead of functions in the manual or other libraries...
So I think that are some of plenty reasons not to learn all php functions...

Of course not.
Only string manipulation ones.
Dunno where did you get that list. It's totally useless. Not list but structured reference is what you really need.
Just take a brief tour on manual sections to picture yourself list of PHP features, so, you'll know where to look on occasion.
Only string manipulation functions deserve closer look, just because PHP itself is mainly string manipulation language.

Related

Is it acceptable to wrap PHP library functions solely to change the names?

I'm going to be starting a fairly large PHP application this summer, on which I'll be the sole developer (so I don't have any coding conventions to conform to aside from my own).
PHP 5.3 is a decent language IMO, despite the stupid namespace token. But one thing that has always bothered me about it is the standard library and its lack of a naming convention.
So I'm curious, would it be seriously bad practice to wrap some of the most common standard library functions in my own functions/classes to make the names a little better? I suppose it could also add or modify some functionality in some cases, although at the moment I don't have any examples (I figure I will find ways to make them OO or make them work a little differently while I am working).
If you saw a PHP developer do this, would you think "Man, this is one shoddy developer?"
Additionally, I don't know much (or anything) about if/how PHP is optimized, and I know that usually PHP performace doesn't matter. But would doing something like this have a noticeable impact on the performance of my application?
You might be the only developer now but will someone else ever pick up this code? If so you really should stick mainly to the standard library names if you're doing nothing more than simply wrapping the call.
I've worked with code where the author has wrapped calls like this and it really does harm the ability to quickly understand the code
If you saw a PHP developer do this, would you think "Man, this is one shoddy developer?"
Well no...but I'd think "Damn...I've got to learn this guys new naming standard which although well-intentioned will take me time"
I assume you are referring not only to naming conventions, but also to the merry mixture of function (needle, haystack) and function(haystack, needle) parameter orders.
I can totally understand the desire to build sane wrappers around these in self-defense. I still rather wouldn't do it, though, simply because it adds a proprietary layer to your project that will make it harder to understand for others. Everybody knows what array_push does, but MyArrayFunctions::push one may have to look up, or even look into to find out what it does.
I tend to stick with the standards, even though they're admittedly crappy in this case. Plus, with a decent IDE that can look up functions and parameters as you type, the problem is already much reduced.
On the other hand, I can't really see any harm in, say, a static class Array that brings all the push(), pop(), array_this() and array_that() into one standard form. I'd say it's up to you, really.
Simple wrappers wont hit your performance, but this might confuse any future developers on the project. As a PHP programmer you slowly come to expect the weird naming conventions.
If you are adding any functionality its great to have consistent conventions. I have worked with a PHP static class that did wrap the native array functions (and add new ones). It was quite convenient to always have the same argument placements.
In my opinion OOP implementations of for example an array are okay, you will wrap them and partially modify functionality, however just renaming functions and shuffling arguments I don't like.
If you really need to do it make sure you comment it with phpdoc so people can see the correct syntax in the autocomplete of their IDE.

Does constantly checking the documentation make you a bad coder?

When writing PHP code for any given project, do you find you can write code off the top of your head? Or do you make multiple round trips to php.net? If it is the later, can you still be considered a good coder. This is a legitimate question as I find I have difficulty always remembering all of the functions that are available to me so I find I use php.net as a crutch. Is there anyway to improve this?
The same as any language (computer or otherwise) - the more you use it, the better you get.
An issue with PHP is the unpredictability of function names and arguments.
Being a good coder doesn't exclusively mean that you know everything off the top of your head. Most of being a good coder is knowing how to approach problems and solve them. I've been writing PHP for 7 years now and regularly find myself consulting the manual. Sure, I don't check it as often as I used to, but with a language as large as PHP (and with as many inconsistencies), it'll always be necessary to check the documentation. As with anything, over time you will remember more and more.
I think that one of the secrets of becoming a great coder is to read a lot of documentation. I have seen far too many people using the same limited tools over and over again, or desperately doing trial and error instead of broaden the perspective by reading documentation. Don't be ashamed of looking things up - be proud that you have the right attitude to be able continously learning things.
Don't judge your ability based on how fluent you are in a specific language or framework. Always keep in mind that the PHP gods would likely flounder if they were told to write something in C#.
If you are able to put out good code in a reasonable amount of time, it really doesn't matter what you use for assistance.
Being a good coder and having a good memory (thankfully) have nothing to with one another.
Now, not having to look up method names and such can be a time saver, and being fast is part of being a good coder. However, that's what IDEs are there for. If you find yourself looking things up really often, get a PHP IDE with good intellisense and context specific help.
My frequent trips to PHP.NET are mainly due to confusion with the other languages I work with. I usually remember the names of the functions in PHP, but need to double-check the order of the parameters. I don't think that makes someone a bad programmer. If your reason for visiting PHP.NET is to remember how to do an if statement on the other hand...
I think that referencing the documentation when you are unsure is a very good practice. Not only can you avoid making silly mistakes you may also discover different ways to go about doing something, potentially saving you a lot of headaches.
I don't think having a perfect recall of everything you have learned in the past is what makes you a good programmer; I think developing the problem solving skills that are necessary is what will enable you to become a good programmer.
My two bits,
Rob
When I was new to PHP, I used to refer to official PHP file (a chm file) a lot but now I don't make much trips to either that file or php.net as i have been using all those functions again and again, remembered automatically with passage of time that is experience. :)
In short:
Practice does the trick.

Should PHP use objects as basic data types?

I recently had an idea to create my own String class to make using PHP's functions easier. Instead of strlen($str) I write $str->length(). Makes it easier to remember parameter orders in certain functions, like substr.
I ran some timing scripts on it and found that it's about 5 times slower than using the regular functions. I haven't tested this in a real app yet, so I don't know how negligible that will be (1ms vs 5ms or 100ms vs 500ms?).
Anyway it struck me that now PHP is now focusing more on OOP, wouldn't it make sense for strings, arrays and other basic types to be object oriented? They could then name the functions better and code would just "feel" nicer. And slowly phase out the old way of doing things. Any pros/cons to this?
You could always document your code and just use the functions that PHP has provided. It is hard to tell whether or not it is going to affect you in the long run. There are many different factors that can influence that. Give it a shot, maybe and if it does not work out switch back to the original way.
Personally, I would just keep my document well documented instead of getting too fancy. If you want to make the push into more OOP your best bet is to look into a Framework.
I wish PHP would make it that simple from the start. The code would look so neat.
I think it would be nice, but it wouldn't be PHP any more...
Sure, $somestring->length() is nice but, on the flipside, you have to $somestring = new String('asdf...') whenever you make a string and then constantly convert Strings to strings and vice versa. You probably end up making things harder to write & maintain in the long run.
I don't really see the PHP language ever changing in this way - it would change too much of the fundamental language. If you want a language that is like this, you're going to have to change languages, rather than hope for the language to change.
I understand why you're doing this, but libraries and abstractions that do nothing else besides "make it easier on the programmer" are a waste of time, in my humble opinion. They're rarely efficient, they're fluff, and they're even kind of pretentious.
PHP has a lot of faults, that is to be certain, but you'll spend a lot of time that could be better spent elsewhere if you try to invent workarounds for them everywhere you go.
Have a look at Stringy. It gives you a ton of useful methods that makes working with especially UTF-encoded strings easier in PHP:
$stringy = S::create('Fòô', 'UTF-8');
count($stringy); // 3

Tool to convert ASP to PHP

I program mostly in PHP and have a site along with other samples in ASP I need to convert over to PHP. Is there some kind of "translator" tool that can either enter lines of code or full slabs that attempts to output a close PHP equivalent?
Otherwise, is there an extensive table that lists comparisons (such as design215.com/toolbox/asp.php)
It isn't perfect, but this will convert most code.
I think this is a poor way to do it. Sure, a quick-reference table helps a little. But really you need to be fluent in both ASP and current PHP best practices, and envision what a good PHP design would be. The naive transliteration will just give you PHP code that thinks it's ASP. A true port will be easier to understand and maintain.
I agree with Abinadi that the tool by Mike kohn here is probably the best available still.
We did a successful conversion for a decent size project and wrote a blog about the process: Converting Classic ASP to PHP
While a standard lookup table with function could work it would be a LOT of work still to clean everything up. ASP to PHP is still probably one of the easier conversions but as mentioned will most likely end up with code that potentially is bad but in a different language.
Mike's tool handles fairly basic single page conversions and a good starting point but was outdated, missing a lot of functions and smarts when used on a bigger project. In saying that, it's still worth trying out even in the current state.
Here's a list of the main points we had to consider:
Not all types have a compatible type, eg dates and booleans
COM Objects can be used but may need heavy refactoring
Variable case sensitivity (tools can help here a lot)
Variable scoping (asp loves globals)
HTML/JS Get and Post case sensitivity (harder to fix with tools)
Object self references, eg PHP classes need $this->variable
If you use lots of let/get/set be prepared for some heavier re-factoring
Of course the list above is just things to lookout for, if you were to create a tool you have to factor in a lot of the basics in parsing/tokenising asp code before even considering the above differences.
Good luck to anyone attempting this conversion project, having done it before we know the feeling.

Has anyone attempted to make PHP's system functions more Object-Oriented?

I'm just curious if any project exists that attempts to group all (or most) of PHP's built-in functions into a more object-oriented class hierarchy. For example, grouping all the string functions into a single String class, etc.
I realize this won't actually solve any problems (unless the modifications took place at the PHP source code level), since all the built-in functions would still be accessible in the global namespace, but it would certainly make usability much easier.
Way too many times. As soon as someone discovers that PHP has OO features they want to wrap everything in classes.
The point to the OO stuff in PHP is so that you can architect your solutions in whichever way you want. But wrapping the existing functions in Objects doesn't yield much payoff.
That being said PHP's core is quite object oriented already. Take a look at SPL.
I think something like this is intergral for PHP to move forward. Being mainly a .Net programmer, I find PHP painful to work in with it's 1 million and 1 global functions. It's nice that PHP 5.3 has namespaces, but it doesn't help things much when their own libraries aren't even object oriented, let alone employ namespaces. I don't mind PHP as a language so much, but their API is terribly disorganized, and it probably needs a complete overhaul. Kind of like what VB went through when it became VB.Net.
To Answer your question, Yes there exists several of libraries that do exactly what you are talking about. As far as which one you want to use is an entirely different question. PHPClasses and pear.org are good places to start looking for such libraries.
Update:
As the others have suggested SPL is a good library and wraps many of built in php functions. However there still are lots of php functions that it does not wrap. Leaving us still without a silver bullet.
In using frameworks such as Cakephp and Zend (others too), I have noticed that they attempt to solve some of these problems by including their own libraries and building basics such as DB connectivity into the frame work. So frameworks may be another solution
I don't agree. Object Oriented Programming is not inherently better than procedural programming. I believe that you should not use OO unless you need polymorphic behavior (inheritance, overriding methods, etc). Using objects as simple containers for code is not worth the overhead. This is particularly true of strings because their used so much (e.g. as array keys). Every application can usually benifit from some polymorphic features but usually at a high level. Would you ever want to extend a String class?
Also, a little history is necessary to understand PHP's odd function naming. PHP is grounded around The Standard C Library and POSIX standard and uses many of the same function names (strstr, getcwd, ldap_open, etc). This is actually a good thing because it minimizes the amount of language binding code, ensures that a full well thought out set of features (just about anything you can do in C you can do in PHP) and these system libraries are highly optimized (e.g. strchr is usually inlined which makes it about 10x faster).

Categories