If you use methods that have two different kinds of syntax for method calls, one of which does not involve an object when it normally would, then "that means if you are parsing the language, you must provide a mechanism for doing both". Or you could just differentiate between methods and free functions.Originally Posted by MK27
For clarification, why can you write this?
Why is it that you can call verifydir without the syntax of foo.verifydir(pathsub), where foo is some class or object name?Code:if verifydir(pathsub) list[artist].dirpath = pathsub if list.has_key?(artist)
My understanding here is that verifydir is a free function. It is not bound to any class or object, but operates on an object. Yet, this is the same for C++ as well. If you contend that there is a uniform syntax, then it holds true that C++ has a uniform syntax for free functions and member functions.
Yes, that is a correct application of the principle.Originally Posted by MK27
Yes, once you add in support for inheritance and polymorphism. You have stumbled upon the fact that it is possible to simulate OOP in certain languages that lack native OOP support.Originally Posted by MK27
He also had the benefit of the existing literature, including certain object oriented programming languages, at the time, but yes: the output of the first C++ compiler was C programs.Originally Posted by MK27
Mind being more charitable to those who debate with you? I have never once accused you of being stupid, even though I can argue from authority, given that programming languages is one of the topics that I focussed on in my university studies.Originally Posted by MK27