4 ms·
I don't see much difference between a duck-typed language in which callables with capitalized name are just expected to produce objects which obey a certain duc
by limmeau 16y ago
I don't see much difference between a duck-typed language in which callables with capitalized name are just expected to produce objects which obey a certain duck type, and a prototype language.
The problem to which super is a (general and tricky) solution is the consequences of multiple class inheritance rather than class inheritance. A single-inheritance super could be realized in a less tricky way.
- cturner 16y ago> I don't see much difference [..] Agree, there's not much. But I have some scenarios in mind where I prefer the prototype approach. 1) Inline classes A pattern I sometimes use involves creating an object to maintain state before a for loop. Example scenario: parsing characters as they come in over a network line. Say the data has qutation blocks that create nesting situtaion. You want to support both ' and " blocks. It's a simple situation. You want an object that will store some kind of mode for what scope you're in at the moment, and you'll be accumulating the structure you're parsing. [1] You might want the object to have a render(self) method as well, to dump the data once you've parsed it. In io you can just say "Make me an object that does this". In python you declare a class, and then instantiate an instance of it. It's needless to create the class - there is absolutely only one time that I'm going to build this thing. [2] You could create a syntax that worked like python, but had a syntax that addressed this without technically being a prototype language. 2) Adding functions to existing objects In python there is ugliness involved in tapping a new function onto an existing object. Python's a bit confusing here partly because of the way self works. When I encounter this in python I usually do a lambda trick to make the function a member of the object, and then I'll have some method on the object that will refer to it. The equivalent in io is more straightforward. > A single-inheritance super could be realized in a less > tricky way. True. I have and will never use multiple inheritance in python and would prefer the simple syntax that would be made possible with single inheritance. I remain interested in this broader issue of - is class-based inheritance a good thing at all? == [1] In python you have to use a structure for this, because once you're in the 'for' loop, it won't let you rebind variables outside the scope of the for loop, only modify them. I haven't played with 'inline' yet. [2] You could also use a dictionary, but I think that's a bit more verbose. An object is just what I want in these situations.
- limmeau 16y ago1) Good example for a one-off object implementation; however, creating a one-off class and then an instance is just one more line. 2) Actually, I don't mind if adding methods to other developers' objects is hard; it always seemed to me like a dirty hack.
- steveklabnik 16y agoIn ruby, #2 is as simple as num = 42 def num.to_whatever "whatever" end num.to_whatever # => 42 41.to_whatever # => NoMethodError I agree with my sibling, though. It might be better that this is harder in Python. It's a bad idea, generally.
- masklinn 16y ago> In io you can just say "Make me an object that does this". In python you declare a class, and then instantiate an instance of it. It's needless to create the class - there is absolutely only one time that I'm going to build this thing. [2] You can create classes inline via `type`, and Python 2.6 has named tuples which are basically record types. You could also create a one-off class onto which you'd graft attributes as needed: >>> class Object(object): pass … >>> a1 = Object() >>> a1.a = 3 >>> a1.b = 'foo' >>> a2 = Object() >>> a2.stuff = 42 you can even use `copy.copy` (or `copy.deepcopy`) on these to have something prototypey: >>> a3 = copy.copy(a2) >>> a2.stuff 42 >>> a3.stuff 42 >>> a3.stuff = 43 >>> a2.stuff 42 >>> a3.stuff 43 > You could also use a dictionary, but I think that's a bit more verbose. By about 4 characters per key access. > In python there is ugliness involved in tapping a new function onto an existing object. […] When I encounter this in python I usually do a lambda trick to make the function a member of the object What lambda trick? Why not just create a (bound) instance method from your function and graft that onto your object? Granted it's not going to be as sexy as doing so in IO, but it takes all of one line: >>> def foo(self): print 'Instance method of', self … >>> # naïve version, not going to work as it doesn't bind the function to the instance, it just sets a function as a member of the object >>> a3.foo = foo >>> a3.foo() Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: foo() takes exactly 1 argument (0 given) >>> a3.foo = types.MethodType(foo, a3, Object) >>> a3.foo() Instance method of <__main__.Object object at 0x1004cdf50> > I have and will never use multiple inheritance in python and would prefer the simple syntax that would be made possible with single inheritance. If you use single inheritance always, you can just get rid of `super` altogether: just call the relevant method on your superclass. > [1] In python you have to use a structure for this, because once you're in the 'for' loop, it won't let you rebind variables outside the scope of the for loop, only modify them. I hope I misunderstand what you mean, because what I'm reading here is downright wrong: Python only has function-level scoping (and a special scope for listcomps, but that's a different issue) so any binding you create or modify within a for loop (or a `with` statement, or an `if` or whatever else you may think of) will be visible from outside the block: >>> a Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'a' is not defined >>> for i in range(1): ... a = i ... >>> a 0 And of course, you can rebind existing variables just fine: >>> for i in range(2): ... a = i ... >>> a 1 did I miss something?