3 ms·

What about things like CLOS where you have multi-methods and dispatching is done based on the type of all arguments?

mistrial9 3y ago
combine a type system with dispatch logic, using abstractions .. it is very clear for some engineering applications and/or tinkertoys. Many people can get the basic ideas with thirty minutes of introduction.
narag 3y ago
I haven't used it, so not sure if it fits the pattern, but the question for me is: is it useful, time-saving, more usable? does it make the task more clear for the programmer that uses it?
- jghn 3y ago
  It depends. It is a fundamentally different branch of the OOP family tree than what most people are used to seeing. Enough so that I've seen people declare it to *not be OOP*. So if you stumble across the model having only seen the style of OOP popularized by C++ and later Java, no. You will probably *not* find it to be liberating. The idea is that you have classes which model state. And then you have generics that model functionality. And you define methods which provide an implementation of the generic for a class. But it's more flexible than what you see in Java because such a method can be easily added after the fact as it's not intrinsically part of the class' definition. If you're familiar at all with Typeclasses in Haskell & Scala, personally I find those to be similar enough to get the gist. Likewise Dylan and R's S4 objects are modeled after CLOS' structure.
whartung 3y ago
Runtime, multi-method dispatch is probably the singular thing that stands out as "missing" from other systems. I don't miss it a lot, but there have certainly been times when I have. I also enjoyed the ability to not be locked into the rigor of a class structure when it comes to methods. Since CLOS is function based, it's trivial to add functions to a class that you don't even have the source code to. There have been many times working with a 3rd party or system library where I've had that "if only I had this little method" moment that would make my life easier. I'd rather have that capability and fight, say, namespace issues for the "Well what if everyone added their own 'upshiftFirstLetter' method to the String class" problems on an ad hoc basis. Part of this, of course, stems from the locked down nature of the scope of classes. Not having access to internal structures and state. I'd rather take those risks of leveraging internal state knowledge not supported by the original designer vs the alternatives of sometimes having to throw out the baby with the bathwater.

combine a type system with dispatch logic, using abstractions .. it is very clear for some engineering applications and/or tinkertoys. Many people can get the basic ideas with thirty minutes of introduction.

narag 3y ago

I haven't used it, so not sure if it fits the pattern, but the question for me is: is it useful, time-saving, more usable? does it make the task more clear for the programmer that uses it?

jghn 3y ago
It depends. It is a fundamentally different branch of the OOP family tree than what most people are used to seeing. Enough so that I've seen people declare it to *not be OOP*. So if you stumble across the model having only seen the style of OOP popularized by C++ and later Java, no. You will probably *not* find it to be liberating. The idea is that you have classes which model state. And then you have generics that model functionality. And you define methods which provide an implementation of the generic for a class. But it's more flexible than what you see in Java because such a method can be easily added after the fact as it's not intrinsically part of the class' definition. If you're familiar at all with Typeclasses in Haskell & Scala, personally I find those to be similar enough to get the gist. Likewise Dylan and R's S4 objects are modeled after CLOS' structure.

whartung 3y ago

Runtime, multi-method dispatch is probably the singular thing that stands out as "missing" from other systems. I don't miss it a lot, but there have certainly been times when I have. I also enjoyed the ability to not be locked into the rigor of a class structure when it comes to methods. Since CLOS is function based, it's trivial to add functions to a class that you don't even have the source code to. There have been many times working with a 3rd party or system library where I've had that "if only I had this little method" moment that would make my life easier. I'd rather have that capability and fight, say, namespace issues for the "Well what if everyone added their own 'upshiftFirstLetter' method to the String class" problems on an ad hoc basis. Part of this, of course, stems from the locked down nature of the scope of classes. Not having access to internal structures and state. I'd rather take those risks of leveraging internal state knowledge not supported by the original designer vs the alternatives of sometimes having to throw out the baby with the bathwater.