$e->getMessage()?well they're back.. and throwing exceptions over non-exceptional cases is so 2002 How do pass those exceptions to the user interface to be shown as error messages? just wondering
IDE dictates a lot of what we as programmers strive for, unfrotunately. A counter argument, would be, a good IDE with refactoring tools would make adding/removing arguments from a method sigature a single operation as well, but it's because PHP is difficult to refactor (being a dynamic language) that forces us to get creative, such as using associatve parameters.Personally, I don't use autodocs. I don't see much value in it, I document what needs documenting myself (ie, everything that isn't completely self explanatory). Documentation generated just from method definition is not very useful in my opinion (and any good IDE can do that by the way)
Dynamic programming is awesome, I love it compared to more static programming such as C/C++ however I am also a fan of explicit coding, it's makes everything more clear and easier to understand.
I think we face an interesting dilema as programmers who must:
1. Write code for themselves so it's easier for us to maintain
2. Write code for others to easily understand and learn
Two very different crowds, two different challenges.
Ideally we find a solution that meets both crowds half way.
I agree.I'm not talking about one specific field. When updating often you are only updating a partial list of fields (for example, just the username and email). The array approach accepts a partial list of parameters the same as the full list, with the same interface as the create method. Much simpler to implement, maintain and modify.
First I would ask, why I need a variable number of arguments? To me, that sounds like a design issue. My views are usually composed of several smaller views, each of those sub-forms (for lack of a better word) are usually mapped one to one with a model method. Updating credential details, personal details, etc.How do you handle a variable number of arguments to update using your approach? do you create mock null variables to pass for the parameters that aren't available, or do you use error suppression? either solution sounds pretty bad
If their amalgamted into a single form, I would simple multiple model methods in one save operation, alternatively, I might have multiple forms on oe physical page and submit to each individually. Nothing is so monolithic to require lengthly variable parameter lists.
If someone updates their credentials, they POST a form with:
1. Username/Alias
2. Password
3. Password reset
4. Email
4 fields, two of which are optional, in which case they would be passed to the model as empty/null
Code: Select all
updateCredentialDetails($_POST['user'], $_POST['pass1'], $_POST['pass2'], $_POST['email']);I hated that about MFC and C++ -- very common practice to have overloaded methods in addition to default arguments, it made working with the API very difficult.
Cheers,
Alex