3 ms·

I think what you're talking about for type-safety, not necessarily OOP. C supports types, but is not completely type-safe. It will tell the developer that they

I think what you're talking about for type-safety, not necessarily OOP. C supports types, but is not completely type-safe. It will tell the developer that they shouldn't be doing something, but won't enforce it. The argument above is that most developers write object-oriented code in procedural languages. They have a set of functions that perform actions on a specific type of data structure. To encapsulate functionality and keep the codebase clean, all reads and writes to these data structures should go through these functions. This pattern is ubiquitous in well-written C code. OOP itself simply provides a standard framework and syntactic sugar to make this type of code more consistent and clear. EDIT: Here's a real-world example: (came up for the first search of hash.c) http://www.ks.uiuc.edu/Research/vmd/doxygen/hash_8c-source.html http://www.ks.uiuc.edu/Research/vmd/doxygen/hash_8c-source.h...

encoderer 16y ago
No, not entirely. A strongly typed language will help this a little -- at least I can know i have, say, an array of strings. Suppose i have 2 properties in my class, 'start_date' and 'end_date'. They are private and have setters. In a method that uses those 2 properties, I can trust that they are of the right type, that start_date is < end_date, that they represent a reasonable range based on my logic defined in the setters. All of this can be taken for granted. In this procedural example, imagine some sort of hash or struct or associative array (whatever you want to call it in your given language) is supplied with those 2 keys. The procedure cannot trust that the inputs are valid. It has to check everything. If you can rely on type safety, congrats, that's one less check. But there are plenty of others.
- rbranson 16y ago
  So you create a typedef struct of date_range to store the start_date and end_date and use a set of date_range_* functions to manipulate that struct. Most OOP languages allow direct access to even private variables if the developer really wants to, so the guarantees are pretty weak. C++, Java, C#, Ruby, Python... all of those allow indirect access to "private" methods and variables. You must still rely on other developers to do the right thing and not screw things up.
  - encoderer 16y ago
    I think the argument that a developer can access and write-to private methods bypassing setters so therefore encapsulation is broken is pretty weak IMO. On one hand you have an option where you have to trust the developer will chain the appropriate method calls to build an unrelated data structure that gets passed-in to your target method. On the other, you have the possibility that a developer will knowingly and willing subvert the encapsulation by writing directly to private variables while ignoring the business logic that's being enforced in the setters. Do you mind me asking... what exactly are you arguing there? In the first example it's easier to do it wrong than it is to do it right. In the second example it's easier to do it right than it is to do it wrong -- in fact you have to specifically write to protected members to break it. How are we still discussing this?
    - rbranson 16y ago
      I believe your conclusion is rooted in a lack of experience in writing C code. You seem to think that developers are going to go out of their way to allocate and initialize the struct manually. In almost every codebase I've worked in, struct types always have an allocation/initializer function, so I look for that first, and generally find a set of other functions that are used to work on that struct type, organized into a single .c file usually named something similar to that struct type. It is a convention, not syntactic sugar. In C++ or C#, you have syntactic sugar that makes it more difficult to violate the rule, but does not actually enforce anything.
    - encoderer 16y ago
      Rbranson: Well if you personally want to use a procedural language for OO development, that would explain a lot about this conversation. Anyway, good talk. Appreciate the back and forth. I wouldn't hire somebody with a mindset like yours but I certainly like chatting on HN.

encoderer 16y ago

No, not entirely. A strongly typed language will help this a little -- at least I can know i have, say, an array of strings. Suppose i have 2 properties in my class, 'start_date' and 'end_date'. They are private and have setters. In a method that uses those 2 properties, I can trust that they are of the right type, that start_date is < end_date, that they represent a reasonable range based on my logic defined in the setters. All of this can be taken for granted. In this procedural example, imagine some sort of hash or struct or associative array (whatever you want to call it in your given language) is supplied with those 2 keys. The procedure cannot trust that the inputs are valid. It has to check everything. If you can rely on type safety, congrats, that's one less check. But there are plenty of others.

rbranson 16y ago
So you create a typedef struct of date_range to store the start_date and end_date and use a set of date_range_* functions to manipulate that struct. Most OOP languages allow direct access to even private variables if the developer really wants to, so the guarantees are pretty weak. C++, Java, C#, Ruby, Python... all of those allow indirect access to "private" methods and variables. You must still rely on other developers to do the right thing and not screw things up.
- encoderer 16y ago
  I think the argument that a developer can access and write-to private methods bypassing setters so therefore encapsulation is broken is pretty weak IMO. On one hand you have an option where you have to trust the developer will chain the appropriate method calls to build an unrelated data structure that gets passed-in to your target method. On the other, you have the possibility that a developer will knowingly and willing subvert the encapsulation by writing directly to private variables while ignoring the business logic that's being enforced in the setters. Do you mind me asking... what exactly are you arguing there? In the first example it's easier to do it wrong than it is to do it right. In the second example it's easier to do it right than it is to do it wrong -- in fact you have to specifically write to protected members to break it. How are we still discussing this?
  - rbranson 16y ago
    I believe your conclusion is rooted in a lack of experience in writing C code. You seem to think that developers are going to go out of their way to allocate and initialize the struct manually. In almost every codebase I've worked in, struct types always have an allocation/initializer function, so I look for that first, and generally find a set of other functions that are used to work on that struct type, organized into a single .c file usually named something similar to that struct type. It is a convention, not syntactic sugar. In C++ or C#, you have syntactic sugar that makes it more difficult to violate the rule, but does not actually enforce anything.
  - encoderer 16y ago
    Rbranson: Well if you personally want to use a procedural language for OO development, that would explain a lot about this conversation. Anyway, good talk. Appreciate the back and forth. I wouldn't hire somebody with a mindset like yours but I certainly like chatting on HN.