3 ms·

I think user IDs should be passed around as ints. It's efficient and simple. If you've got critical code that might lock someone out (or worse), you're much bet

by osrec 9y ago

I think user IDs should be passed around as ints. It's efficient and simple. If you've got critical code that might lock someone out (or worse), you're much better off spending time testing it to ensure it works, rather than building in inefficient paradigms into your data model. For argument's sake, imagine if your data model also stores the sender's current manager per message. You could by mistake do this as well (a little slip of the finger when using code completion): ban_senders_of_messages(messages) { for (i = 0; i < messages.size(); ++i) { ban_account(message[i].sendersManager); } } The only way to catch that is to test, and because the manager and sender will have similar data types, it will compile/execute just fine. The point is, this is probably a more likely error than the one mentioned in the article, and needs manual inspection and testing to correct. If you're carrying out that process anyway, the added inefficiency of a more elaborate data type just for user IDs seems redundant.

tom_ 9y ago
Why not define a new data type for each type of ID? Simple and effective. And there's no inefficiency; these things aren't created and destroyed all the time! They're just retrieved from other objects and then passed around. In languages that support value types, you'll typically make them integer size, so the cost is likely to be the same as passing an integer. In languages that support reference types only, you're just passing around a pointer anyway.
- osrec 9y ago
  But in my example, surely the data type for a manager's ID will still be the same as that of the user, so I'm not sure it really solves the problem entirely.
  - mic47 9y ago
    Then maybe you should have manager's IDs done as separate type too?
    - osrec 9y ago
      But they're all users, where one user can be set as a manager for another. Why would you have a separate type for each?!
      - tom_ 9y ago
        But your example implies you shouldn't be allowed to get them mixed up? If manager IDs and user IDs truly are the same type of thing, then there's a limited amount the type system can do for you in this respect. Maybe you'll have to stop at this point and just accept that you'll have to exercise a certain degree of care. But there's a big gap between stopping there, in my view, and what you appear to be advocating: deciding that since manager IDs and user IDs are the same thing then you might as well give up entirely and just decide that they may as well be the same thing as ints while you're at it.
        osrec 9y ago
        Not quite. If I was to truly critique the example, the problem lies mainly with the ban function, which appears to allow ints to be passed in as arguments. If we have static typing available to us (the example in the article doesn't seem to), then yes, I agree we should ensure that only the relevant type should be allowed as the argument. But still, problems can lurk in the shadows, for example, you could initialise a User type with a message ID by mistake, or even an iterating int, much like the example in the article. I'm not trying to be difficult or unnecessarily contrarian, but my experience tells me that you can put a whole bunch of safeguards into your code, but nothing beats testing at catching bugs, and sometimes, the safeguards are not worth the efficiency hit. Worse still, the safeguards can at times provide a false sense of security.
        tom_ 9y ago
        It shouldn't be an excuse to dispense with testing altogether, but static typing is certainly superior to testing for certain classes of bug. The compile-time checks prove certain types of defect simply don't exist, which is the kind of guarantee no amount of testing can give you in that respect for any useful program. As for the initialisation problem, it's true that it can't be structs all the way down, and at some point you will have to create one of these objects, probably from a primitive with a non-meaningful type such as int, or string. But my experience is that IDs and the like tend to be created in a small number of places, and then reused, copied and passed around. Far easier to find and check all the places where one is created than all the places where one is used!

by osrec 9y ago

tom_ 9y ago

Why not define a new data type for each type of ID? Simple and effective. And there's no inefficiency; these things aren't created and destroyed all the time! They're just retrieved from other objects and then passed around. In languages that support value types, you'll typically make them integer size, so the cost is likely to be the same as passing an integer. In languages that support reference types only, you're just passing around a pointer anyway.

osrec 9y ago
But in my example, surely the data type for a manager's ID will still be the same as that of the user, so I'm not sure it really solves the problem entirely.
- mic47 9y ago
  Then maybe you should have manager's IDs done as separate type too?
  - osrec 9y ago
    But they're all users, where one user can be set as a manager for another. Why would you have a separate type for each?!
    - tom_ 9y ago
      But your example implies you shouldn't be allowed to get them mixed up? If manager IDs and user IDs truly are the same type of thing, then there's a limited amount the type system can do for you in this respect. Maybe you'll have to stop at this point and just accept that you'll have to exercise a certain degree of care. But there's a big gap between stopping there, in my view, and what you appear to be advocating: deciding that since manager IDs and user IDs are the same thing then you might as well give up entirely and just decide that they may as well be the same thing as ints while you're at it.
      - osrec 9y ago
        Not quite. If I was to truly critique the example, the problem lies mainly with the ban function, which appears to allow ints to be passed in as arguments. If we have static typing available to us (the example in the article doesn't seem to), then yes, I agree we should ensure that only the relevant type should be allowed as the argument. But still, problems can lurk in the shadows, for example, you could initialise a User type with a message ID by mistake, or even an iterating int, much like the example in the article. I'm not trying to be difficult or unnecessarily contrarian, but my experience tells me that you can put a whole bunch of safeguards into your code, but nothing beats testing at catching bugs, and sometimes, the safeguards are not worth the efficiency hit. Worse still, the safeguards can at times provide a false sense of security.
        tom_ 9y ago
        It shouldn't be an excuse to dispense with testing altogether, but static typing is certainly superior to testing for certain classes of bug. The compile-time checks prove certain types of defect simply don't exist, which is the kind of guarantee no amount of testing can give you in that respect for any useful program. As for the initialisation problem, it's true that it can't be structs all the way down, and at some point you will have to create one of these objects, probably from a primitive with a non-meaningful type such as int, or string. But my experience is that IDs and the like tend to be created in a small number of places, and then reused, copied and passed around. Far easier to find and check all the places where one is created than all the places where one is used!