3 ms·
I really enjoy reading these articles comparing different implementations in different languages. I wish we had more of that on HN. Concerning the article, cal
by d0m 16y ago
I really enjoy reading these articles comparing different implementations in different languages. I wish we had more of that on HN.
Concerning the article, call me grumpy if you want, I like better when there is no mass overloading even thought it's more verbose. From my maintenance experience working on various project, I always cry when after 3 hours of searching I find that "+" is overloaded and that's where the bug was hidden.
Also, for this particular implementation, we could simply use a builder.
SearchBuilder sb;
sb.equal(Search.Name, "..");
sb.equals(Search.AGE, ..);
Search s = new Search(sb);
Even thought it's more verbose, we clearly see that we configure the builder as we want, and then, we create the search object. A good side effect of that is that we get an immutable Search object. Also, we could use the "fluent" interface on the builder.
Another verbose approach might be using lots of Objects..
Search s;
s.add_contraint(SearchEqual(Search.Name, "bob"));
This way, it make it easier to add constraint without modifying the Search class.
- jacquesm 16y agoOverloading basic operators is the road to hell. Yes, you can do wonderful and elegant things but when it goes wrong your whole mechanism for analysing what you look it is screwed up because the more experience you have in a language the more you tend to be on autopilot for stuff like that. 'test your assumptions' suddenly expands to include checking if basic language operators still do what you expect them to do. and v2 = vec_add(v1,v3); really isn't that much better than v2 = v1 + v3; I know this is not a popular opinion but that's how I've always felt about it and those that complain about how difficult languages like c++ care usually painted themselves in a corner by excessive use of such features.