Tag Info

New answers tagged

1

"Update or create if doesn't exist" can be considered a single operation: upsert. The real thing to be concerned about when it comes to "doing multiple things" (also known as the Single Responsibility Principle: a class should only have 1 reason to change) is what's managing the interaction between the DB and programming objects. Whatever it is should be ...


4

Definitely 2 methods. If you have 2 methods, you can stack and arrange them, thus reuse them either in different sequence or even separate from each other. If you have 1 method with both functionalities, you can only use it for whatever you designed to use it, hence no code reuse. Also, these are different functionalities, thus they are better off being ...


0

I try to follow the following: For externally-called code, do as much explicit error handling as possible, to provide the best experience for the caller and highest level of protection for your own code against inbound data that might partially succeed in unintended ways. For private calls, I'd explicitly handle bad data if it was possible for that data to ...


2

As of PHP5, type hinting is a thing. The most important distinctions are the following: You cannot type hint scalar/numerical, string, Resource, or Trait data. You can force parameters that are objects, arrays, or anonymous functions. You can type hint using interface names, class names, object keyword, array keyword, or callable keyword (for anonymous ...


8

I'm going to build some public public PHP packages. Public as in "Open Source", "public to the whole world"? Then do yourself a favor and do as much validation as you can as long as you do not suffer serious performance problems. Even when you provide some documentation saying "this function does not handle left out parameters", expect a lot of people ...


1

There's no standard, this is entirely up to you. If you are going to implement type checks, keep in mind that you'll only need them for scalar values. PHP supports type hinting for arrays and objects. Also, there probably isn't a reason to throw an exception on every type mismatch. Consider this function: function getById($id) { // Get item from db ...


2

In .NET the naming is different although the result is exactly same. Instead of: tomorrow = LocalDateTime.plusDays(1); there is: tomorrow = DateTime.Now.AddDays(1); This only means that differences between understanding of "plus" and "add" ended up as matter of personal opinion. Cheer up, you're not alone, at least you can choose the language which ...


-1

This is probably an artifact of Java using .Method for all methods, both those that modify the object and those that don't. Imagine a language which also has a object=>method syntax, which would give method a copy of the object to work on. Now in such a language, startDate=>plusDays(5) is clearly unambiguous. It takes the original date, and creates a ...


51

The only reason I can think of is that dates are immutable objects, so by calling plusDays you're not adding days to the original object but creating a new one with new properties, but that's very vary subtle. This is exactly the reason. Imagine you had some kind of api for manipulating ranges of dates for scheduling purposes. It might expose methods ...



Top 50 recent answers are included