5 ms·

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

by 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.
  - bad_user 13y ago
    > You're saying you think of classes as inheritance and polymorphism without encapsulation I don't know whatever gave you that idea, but it's quite the opposite, unless we have completely different definitions for what encapsulation is.
  - chongli 13y ago
    but encapsulation is the key trait for decoupling. Abstraction is the key trait for decoupling, not encapsulation. Encapsulation couples behaviour and state together.
    - Jormundir 13y ago
      Can you give an example? My thought is you can make a bunch of well abstracted objects, but still have a very tightly coupled system. If one class is free to use the internals of another, it's free to tightly couple itself to another class, regardless of the abstractions involved. I see where you're coming from though, and I think decoupling is a combination of abstraction and encapsulation, not one or the other exclusively.
      - chongli 13y ago
        If one class is free to use the internals of another, it's free to tightly couple itself to another class, regardless of the abstractions involved. If one class is free to use the internals of another then it is not a sound abstraction by definition. I see where you're coming from though, and I think decoupling is a combination of abstraction and encapsulation, not one or the other exclusively. Your view of abstraction is too limited. Abstraction need not involve classes or objects at all. Abstractions may also be built with modules/namespaces, parametric polymorphism (aka generics) and other forms of ad-hoc polymorphism (such as type classes). All that is required to achieve abstraction is a function or data type which hides its implementation details in a way that allows it to be interchanged freely with other functions or data types that match its interface. Encapsulation is only one way to achieve such hiding.
        13y ago

by Morgawr 13y ago

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.
- bad_user 13y ago
  > You're saying you think of classes as inheritance and polymorphism without encapsulation I don't know whatever gave you that idea, but it's quite the opposite, unless we have completely different definitions for what encapsulation is.
- chongli 13y ago
  but encapsulation is the key trait for decoupling. Abstraction is the key trait for decoupling, not encapsulation. Encapsulation couples behaviour and state together.
  - Jormundir 13y ago
    Can you give an example? My thought is you can make a bunch of well abstracted objects, but still have a very tightly coupled system. If one class is free to use the internals of another, it's free to tightly couple itself to another class, regardless of the abstractions involved. I see where you're coming from though, and I think decoupling is a combination of abstraction and encapsulation, not one or the other exclusively.
    - chongli 13y ago
      If one class is free to use the internals of another, it's free to tightly couple itself to another class, regardless of the abstractions involved. If one class is free to use the internals of another then it is not a sound abstraction by definition. I see where you're coming from though, and I think decoupling is a combination of abstraction and encapsulation, not one or the other exclusively. Your view of abstraction is too limited. Abstraction need not involve classes or objects at all. Abstractions may also be built with modules/namespaces, parametric polymorphism (aka generics) and other forms of ad-hoc polymorphism (such as type classes). All that is required to achieve abstraction is a function or data type which hides its implementation details in a way that allows it to be interchanged freely with other functions or data types that match its interface. Encapsulation is only one way to achieve such hiding.
      - 13y ago