On Mon, Dec 30, 2013 at 12:59 PM, Massimiliano Tomassoli <kiuhn...@gmail.com > wrote:
> On Monday, December 30, 2013 6:31:52 PM UTC+1, Cedric Greevey wrote: > >> On Mon, Dec 30, 2013 at 12:30 PM, Massimiliano Tomassoli < >> kiuh...@gmail.com> wrote: >> >>> On Sunday, December 29, 2013 11:30:16 PM UTC+1, Cedric Greevey wrote: >>> >>>> On Sun, Dec 29, 2013 at 4:11 PM, Timothy Baldridge >>>> <tbald...@gmail.com>wrote: >>>> >>>>> Not mentioned in Cedric's post are two other important things: >>>>> >>>>> Protocols can be extended to existing types. >>>>> >>>> >>>> These are important for the Expression Problem, but not for the OP's >>>> query as originally stated, which simply asked for the contrast with >>>> overloading. That contrast is dynamic vs. static dispatch. As for C++ being >>>> able to solve the Expression Problem and thus being "equally powerful", >>>> well, both languages are also Turing complete. But which will generally let >>>> you be more expressive, with less ceremony and verbosity? Which has >>>> templates and macros that are unhygienic and a bugbear to work with, and >>>> which has macros that are very safe and clean? >>>> >>> >>> What I was saying was more subtle. If C++ can solve the Expression >>> Problem the same way Clojure does, why do you say that Clojure's solution >>> is acceptable whereas C++ programmers don't accept the same solution for >>> C++? That's simple: external functions are not real methods. So we're >>> accepting Clojure's solution because Clojure doesn't support real methods >>> and objects, but we're rejecting the same solution in C++ because C++ >>> *does* have real methods and objects. Isn't that absurd? >>> >> >> I think you'll need to define what you mean by "real methods and >> objects", and in what way the word "real" is supposed to be establishing a >> contrast. A contrast with what, exactly? >> > > A class must support encapsulation, inheritance and polymorphism. If it > doesn't, then it isn't a class. The same way, a method is a function that > belongs to a class and can be public, private or protected. If a function > is external to an object (i.e. it can't be made private or protected) than > it isn't a method. > I'd submit that your definition is too narrow, since it excludes quite possibly *the* most archetypal of object oriented languages. I speak, of course, of Smalltalk, which the last time I checked had classes whose fields were automatically private and methods automatically public (though you could comment that you didn't intend a method to be called by outside users -- and you can use defn- in clojure, or make "this is private" comments in any language that has comments or sufficiently generous limits on identifiers as to permit calling a bunch of things names like "private_foo"). -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
