2,803 reputation
1022
bio website
location
age
visits member for 4 years, 2 months
seen 2 hours ago

16h
comment Are all magic numbers created the same?
At this point (24, 1024 etc) it sort of becomes a matter of preference I guess.. I'd still prefer a constant (not a #define btw) like numberOfHoursPerDay instead of just 24.
Dec
12
answered VCS - Better way to change location than pushing to branch?
Dec
10
comment Is there ever a reason to use an array when lists are available?
+1, often I have some operation for a couple of objects of the same type which are not in a collection. It's easy, short and clear to write foreach( var x in new []{ a, b, c ) ) DoStuff( x ) or new []{ a, b, c ).Select( ... ) etc
Dec
9
awarded  Enlightened
Dec
9
comment Allow iteration of an internal vector without leaking the implementation
+1, this is a pretty nice and safe implementation
Dec
9
comment Allow iteration of an internal vector without leaking the implementation
@BЈовић by not exposing the complete vector - hiding does not necessarily mean the implementation has to be literally hidden from a header and put in the source file: if it's private client cannot access it anyway
Dec
9
awarded  Nice Answer
Dec
8
comment Class design - should methods call other methods?
It's not really 'abstracting' the DB, that's one step further, I rather meant things even as simple as using a string constant instead of blatantly copy/pasting the complete query string so that when you have to change the string you have to do it in one place only (though in this case I'd just make a single function which executes the query and allows iteration over all resulting elements or so) - for the exeption handling: I don't really have sources for that, I also don't know php at all :]
Dec
8
comment Class design - should methods call other methods?
I mean both: your query strings, executing the query, catching the exception, formatting the exception log message
Dec
8
comment Class design - should methods call other methods?
Not really related to your question, but one thing this code could really benefit from is minimizing the amount of repetition aka not using copy/past coding aka adhering to the DRY pinciple: there are about 5 lines in each function which are exactly the same. That just screams for refactoring into one single method. On which then you can apply the question again :]
Dec
6
comment Allow iteration of an internal vector without leaking the implementation
note: though this certainly works and is accepted it's worth taking note of rwong's comments to the question: adding an extra wrapper/proxy around vector's iterators here would make clients independent of the actual underlying iterator
Dec
6
comment Allow iteration of an internal vector without leaking the implementation
@rwong good points indeed - I reckon my solution is maybe too simplistic. Yet, for 1) I'm probaby used to using auto unless it's not possible, a mechanism which makes one way less dependent of actual iterator type and 2) that is a design decision made and hence has to be documented anyway - sure using vector is dangerous because it's iterators can be invalidated but it's not like that makes vector unusable. Though depending on the exact usage which the OP doesn't mention set/list/... might indeed be a better choice here.
Dec
6
answered Allow iteration of an internal vector without leaking the implementation
Dec
6
comment Allow iteration of an internal vector without leaking the implementation
What @DocBrown says is likely the appropriate solution - in practice this means you give your AddressBook class a begin() and end() method (plus const overloads and eventually also cbegin/cend) which simply return the vector's begin() and end(). By doing so your class will also be usable by all most std algorythms.
Nov
28
comment What is the point of making a syntactic distinction between standard and user-defined types?
In the end you could call it a form of Hungarian Notation as well (i.e. embedding info about type/usage in a name), which is usually frowned upon. Hence: good question.
Nov
26
comment Coupling in OOP Contracts: Many simple values of few complex objects as arguments?
all the handles available means less change, and less to worry about you'd think so, but this tight coupling (i.e. everything knowing about everything) easily leads to situations where person A changes a bit here, B changes a bit there and so on and before you know it nothing can be changed anymore without affecting another's work. And you have a lot to worry about. I'm working on such a piece of crap at this very moment, which is why I'm wandering around on the net instead of working. It's just not fun anymore.
Nov
17
accepted Store an object's name in the object or externally?
Nov
17
answered try/catch open/closed principle violation
Nov
7
comment Store an object's name in the object or externally?
We normally don't use RTTI, but does this give a unique name for every instance of the class?
Nov
6
comment Store an object's name in the object or externally?
+1 for the proxy idea, didn't think of that