>>"Ken Seehof" <kens at sightreader.com> wrote in message >>news:mailman.986858653.28960.python-list at python.org... >>You can always protect against certain bugs by reducing the >>expressiveness and flexibility of a language, but that's not always >>a good idea. For example, by removing the addition operator, we >>can prevent errors such as y = x+3 when we really mean y = x+2. This doesn't make sense. Getting rid of the addition operator does prevent y=x+3 errors but it also prevents what is intended: y=x+2. I am not sure this example demonstrates the point you are trying to make. You are reducing the functionality of the language by removing the addition operator. How am I reducing functionality by not allowing the user to add to the variables contained in the object? I am just asking for an updated class that contains the new variables either by updating the source (which is not always available) or by inheriting and creating a new class. I have not changed the functionality though I may have added some code burden (i.e. requiring you to use a wrapper class). >>Another common fallicy made by people talking about type safety >>is that the Author of a class library or API is always an order of >>magnitude more competent that the user of the class, so if the Author >>of the class didn't think of it, it should not be allowed. I never made this argument. In fact, in C++ you can get around this problem by inheriting from the class into a new class. Could you not do the same in Python (just use a wrapper class)? I am not arguing against inheritance. I just think it is odd behavior that you can arbitrarily add to the object on the fly. This could cause serious bugs especially if one works in a team environment. Suppose I have an object that I add a variable to because I think it makes sense and another programmer also adds a variable because he or she thinks it makes sense and the name happens to be the same but the logic is different. The sample below illustrates: One developer adds to an object: Object.read #which is a boolean which flags when the object has been updated (past tense) and another developer adds Object.read # which is a boolean which flags when an object needs to be updated (as an imperitive) The point is both developers saw that the class definition was inadequate and needed additional variables to address a particular shortcomming which they then added on the fly. Now the intent is the same, determine whether or not object needs updating, but the logic is different. This would be very difficult to debug and could be avoided simply by not allowing the user to add variables on the fly. In addition if you add on the fly, there is no definition for others using the same object. It is just something that exists and there is no way to find out other than by searching through the code looking for instantiation of the variable. Could this type of instantiation ever be documented?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4