6 ms·

If you think of classes as namespaces and not objects (which is what they are half the time), it becomes a bit saner. Pragmatism makes the world work. You can

by RyanZAG 13y ago

If you think of classes as namespaces and not objects (which is what they are half the time), it becomes a bit saner. Pragmatism makes the world work. You can still write functional code in OO. Heck if it makes you feel better, you can just make a macro to rename 'namespace' to 'class' and then you can write code like namespace Utils { function thingy() {...} } Namespaces are generally an improvement over globally defined functions as it lets you mix and match libraries without having to worry that you included the right header files, etc. Again, pragmatism.

dsego 13y ago
Agreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data types, records, code modules, contracts, callback containers, etc. It's hard to grasp disparate concepts when you keep calling them the same name. Even harder to construct and explain more advanced stuff layered on top, such as various design patterns that actually make those objects useful.
- RyanZAG 13y ago
  You can make good arguments in either direction - either having a single generic type (a class) that fits all of these concepts, or having specific types for each of those concepts. Having just a generic type gives the language some useful simplicity as the single 'class' container can fulfill all of those needs yet not need the user to remember all the caveats of each specific type as the 'class' concept is generic enough to fit to almost anything. Having specific types is very good for teaching the different concepts at a higher level as well as documenting what is intended for future readers of the code (as long as they also understand all of the concepts involved). Convention over configuration, really. I personally prefer the more generic types as they don't try to lock you in to the authors specific biases and requirements - that's what frameworks are for.
- hernan604 13y ago
  Classes do too much if you dont have Roles. When you have Roles, you can build a class with Roles. like lego. Then you can have specific roles and build a class with Roles. If your OO doesnt support Classes, Roles, Types and method modifieds and functional programming, its outdated. Seems like your outdated OO needs a metaclass system, up-to-date like Moose from perl.
  - memracom 13y ago
    Just about any OO system can do this using interfaces, abstract base classes, mixins, traits etc. Yes it is a good way to approach design rather than building unique behavior from scratch over and over. But you don't need to go anywhere near PERL to accomplish this.
- pointernil 13y ago
  Agree. I find it quite interesting how the concept of classes resp. objects has been adapted and moved away from what they really were let's say in Smalltalk (message processing entities) ... and I think this "progress" was not for better regarding the clarity of the concept. I think this progress has to do with "type systems" and additionally with the very powerful tools c++ f.e. added to the tool box. The more powerful the toolbox the harder it is to truly grasp it, it seams which steepens the learning curve considerably unless only the very rudimentary "features" of oop are used, as it happens mostly in commercial 9-5 software development.
  - tezka 13y ago
    Have you programmed in Smalltalk? Classes tend to do a lot more (well everything that can be done) compared to C++. Smalltalk has a clean design for the core parts so these hang together pretty well. Nonetheless, inheritance hierarchies are deep and there are many fat classes. So small size in itself is usually not a virtue, clarity in role is on the other hand.
Morgawr 13y ago
Most modern languages (aka post-C) already have namespaces, why would anyone need to use classes as namespaces? You can just have functions that operate on set of data, keep it tight and clean, no need for classes if you don't need oop. Imo forcing classes in a non-oop paradigm is just clumsy and, well, unnecessary. When you have a hammer... etc etc
- ams6110 13y ago
  javascript
- bad_user 13y ago
  Namespaces in Java, C++, C#, or whatever else is in this family, are simply too dumb. Their sole purpose is to avoid name clashes. But what if namespaces were values that you could pass around? What if a namespace could be abstract, much like an interface, defining abstract functions and even abstract types? What if you could override the "import" statements a particular module uses? > no need for classes if you don't need oop It really depends on what you mean when you say "classes". When I think of classes, I think of subtyping, as in, if type B is a subtype of type A (B <: A), then it means a value of type B can be used in any expression that demands a value of type A (i.e. the substitution rule). SML has a pretty cool module system that allows for what I say above. But SML modules are special. The cool thing about OOP, when implemented right, is that you don't need special language semantics for special things, as every value can be some sort of object and every type or module can be some sort of class. You know, in a turtles all the way down kind of thing. See this presentation about the Cake pattern, in Scala: https://www.youtube.com/watch?v=yLbdw06tKPQ https://www.youtube.com/watch?v=yLbdw06tKPQ
  - Jormundir 13y ago
    You're basically asking what if a namespace were a class. > Namespaces in Java, C++, C#, or whatever else is in this family, are simply too dumb. Their sole purpose is to avoid name clashes. That statement is just completely ridiculous. Classes are for inheritance, abstraction and polymorphism. You're saying you think of classes as inheritance and polymorphism without encapsulation, but encapsulation is the key trait for decoupling. It's been awhile since I worked with SML, but if I recall, the modules you say are cool and special, are cool and special because they give you the three important traits of OOP.
icambron 13y ago
I think you're conflating languages that strongly support OO with OO itself. OO is a paradigm, a way of organizing your program. Using classes (meaning, as a language primitive) as namespaces and not as, well, classes is specifically avoiding OO programming. That's fine and, like you said, perfectly pragmatic, but it's not writing "functional code in OO". It's just repurposing language primitives that were designed for OO .
- dasil003 13y ago
  I agree with your specific response here, but I think it's worth pointing out that it is in fact possible to mix OO and FP (ruby is particularly suited for it). You can design systems around classes which are treated as value objects, immutable once initialized, and thus maintain the core tenets of OO and FP in a single program. I guess the definitions of FP and OO are fuzzy enough that someone will probably come and tell me why this isn't a true Functional architecture, but so far I haven't seen anything close though to a consensus on what the strict requirements of FP really are such that it would preclude any form of binding data and methods. Specific languages are one thing, but when talking about programming paradigms in general I see them as forming a hugely overlapping Venn diagram.
  - icambron 13y ago
    Yes, I fully agree with that.
mortyseinfeld 13y ago
Agreed, and in my primary language, C#, these days I would rather just write static classes with static methods and pass in other static methods instead of messing around with interfaces all the time. I write ASP.NET MVC so I don't use state for the most part. Ok, so I don't do that with controllers for obvious reasons, but my business logic and utilities I try to.
- V-2 13y ago
  "I write ASP.NET MVC so I don't use state for the most part." Nor unit tests I assume
  - mortyseinfeld 13y ago
    Care to explain?
    - V-2 13y ago
      The use of statics makes mocking and testing very difficult. A few thoughts on the subject: http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/ http://misko.hevery.com/2008/12/15/static-methods-are-death-... If you use static classes for business logic, you typically end up with a tightly coupled system in which managing class dependencies is a pain. I think that "messing around with interfaces all the time" is worth the fuss in the long run.

by RyanZAG 13y ago

dsego 13y ago

Agreed. I think the problem with OOP (at least in most common implementations) is that objects (and/or classes) just do too much. They serve as complex data types, records, code modules, contracts, callback containers, etc. It's hard to grasp disparate concepts when you keep calling them the same name. Even harder to construct and explain more advanced stuff layered on top, such as various design patterns that actually make those objects useful.

RyanZAG 13y ago
You can make good arguments in either direction - either having a single generic type (a class) that fits all of these concepts, or having specific types for each of those concepts. Having just a generic type gives the language some useful simplicity as the single 'class' container can fulfill all of those needs yet not need the user to remember all the caveats of each specific type as the 'class' concept is generic enough to fit to almost anything. Having specific types is very good for teaching the different concepts at a higher level as well as documenting what is intended for future readers of the code (as long as they also understand all of the concepts involved). Convention over configuration, really. I personally prefer the more generic types as they don't try to lock you in to the authors specific biases and requirements - that's what frameworks are for.
hernan604 13y ago
Classes do too much if you dont have Roles. When you have Roles, you can build a class with Roles. like lego. Then you can have specific roles and build a class with Roles. If your OO doesnt support Classes, Roles, Types and method modifieds and functional programming, its outdated. Seems like your outdated OO needs a metaclass system, up-to-date like Moose from perl.
- memracom 13y ago
  Just about any OO system can do this using interfaces, abstract base classes, mixins, traits etc. Yes it is a good way to approach design rather than building unique behavior from scratch over and over. But you don't need to go anywhere near PERL to accomplish this.
pointernil 13y ago
Agree. I find it quite interesting how the concept of classes resp. objects has been adapted and moved away from what they really were let's say in Smalltalk (message processing entities) ... and I think this "progress" was not for better regarding the clarity of the concept. I think this progress has to do with "type systems" and additionally with the very powerful tools c++ f.e. added to the tool box. The more powerful the toolbox the harder it is to truly grasp it, it seams which steepens the learning curve considerably unless only the very rudimentary "features" of oop are used, as it happens mostly in commercial 9-5 software development.
- tezka 13y ago
  Have you programmed in Smalltalk? Classes tend to do a lot more (well everything that can be done) compared to C++. Smalltalk has a clean design for the core parts so these hang together pretty well. Nonetheless, inheritance hierarchies are deep and there are many fat classes. So small size in itself is usually not a virtue, clarity in role is on the other hand.

Morgawr 13y ago

Most modern languages (aka post-C) already have namespaces, why would anyone need to use classes as namespaces? You can just have functions that operate on set of data, keep it tight and clean, no need for classes if you don't need oop. Imo forcing classes in a non-oop paradigm is just clumsy and, well, unnecessary. When you have a hammer... etc etc

ams6110 13y ago
javascript
bad_user 13y ago
Namespaces in Java, C++, C#, or whatever else is in this family, are simply too dumb. Their sole purpose is to avoid name clashes. But what if namespaces were values that you could pass around? What if a namespace could be abstract, much like an interface, defining abstract functions and even abstract types? What if you could override the "import" statements a particular module uses? > no need for classes if you don't need oop It really depends on what you mean when you say "classes". When I think of classes, I think of subtyping, as in, if type B is a subtype of type A (B <: A), then it means a value of type B can be used in any expression that demands a value of type A (i.e. the substitution rule). SML has a pretty cool module system that allows for what I say above. But SML modules are special. The cool thing about OOP, when implemented right, is that you don't need special language semantics for special things, as every value can be some sort of object and every type or module can be some sort of class. You know, in a turtles all the way down kind of thing. See this presentation about the Cake pattern, in Scala: https://www.youtube.com/watch?v=yLbdw06tKPQ https://www.youtube.com/watch?v=yLbdw06tKPQ
- Jormundir 13y ago
  You're basically asking what if a namespace were a class. > Namespaces in Java, C++, C#, or whatever else is in this family, are simply too dumb. Their sole purpose is to avoid name clashes. That statement is just completely ridiculous. Classes are for inheritance, abstraction and polymorphism. You're saying you think of classes as inheritance and polymorphism without encapsulation, but encapsulation is the key trait for decoupling. It's been awhile since I worked with SML, but if I recall, the modules you say are cool and special, are cool and special because they give you the three important traits of OOP.

icambron 13y ago

I think you're conflating languages that strongly support OO with OO itself. OO is a paradigm, a way of organizing your program. Using classes (meaning, as a language primitive) as namespaces and not as, well, classes is specifically avoiding OO programming. That's fine and, like you said, perfectly pragmatic, but it's not writing "functional code in OO". It's just repurposing language primitives that were designed for OO .

dasil003 13y ago
I agree with your specific response here, but I think it's worth pointing out that it is in fact possible to mix OO and FP (ruby is particularly suited for it). You can design systems around classes which are treated as value objects, immutable once initialized, and thus maintain the core tenets of OO and FP in a single program. I guess the definitions of FP and OO are fuzzy enough that someone will probably come and tell me why this isn't a true Functional architecture, but so far I haven't seen anything close though to a consensus on what the strict requirements of FP really are such that it would preclude any form of binding data and methods. Specific languages are one thing, but when talking about programming paradigms in general I see them as forming a hugely overlapping Venn diagram.
- icambron 13y ago
  Yes, I fully agree with that.

mortyseinfeld 13y ago

Agreed, and in my primary language, C#, these days I would rather just write static classes with static methods and pass in other static methods instead of messing around with interfaces all the time. I write ASP.NET MVC so I don't use state for the most part. Ok, so I don't do that with controllers for obvious reasons, but my business logic and utilities I try to.

V-2 13y ago
"I write ASP.NET MVC so I don't use state for the most part." Nor unit tests I assume
- mortyseinfeld 13y ago
  Care to explain?
  - V-2 13y ago
    The use of statics makes mocking and testing very difficult. A few thoughts on the subject: http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/ http://misko.hevery.com/2008/12/15/static-methods-are-death-... If you use static classes for business logic, you typically end up with a tightly coupled system in which managing class dependencies is a pain. I think that "messing around with interfaces all the time" is worth the fuss in the long run.