8 ms·

I think classical-inheritance subclassing is itself harmful. Subclassing creates less flexible software than other approaches, and creates a need for lots of bo

by cturner 16y ago

I think classical-inheritance subclassing is itself harmful. Subclassing creates less flexible software than other approaches, and creates a need for lots of boilerplate. This issue - super in python - drives many new python programmers crazy. However, I suspect most seasoned devs never think about it. These days I never subclass or feel like I want to. Occasionally I'll use 'duck' typing where I would have subclassed in the past but I find that I rarely even need that. The desire to use classes like this sets off an alarm in my head that I'm making my code too complicated. You do a lot of subclassing in Java. Java steers you there because it's so onerous to use dictionaries and arrays/lists/tuples. The syntax for these structures is simpler in python, and so they're more commonly-used. Subclassing is particularly important for creating frameworks in java. You build your world with packages, class hierarchies and 'bean' style objects. Whereas in python you tend to abstract by module - sets of statics, functions and lightweight structures. I believe python would be stronger still had it had removed subclassing altogether, and instead taken the prototype approach. In prototype languages there's no such thing as a class. Everything is cloned off an original master object. Functions and properties are tapped into the clone. Iolanguage has many of these advantages but is far slower, lacks the reach of python's standard library and (I think) also lacks python's awesome list-comprehension syntax. Someone with better articulation than me could generate blog traffic for themselves by creating a pithy post about the difference in style between java and python, and why subclassing is unpythonic. Then we could link to it when these issues come up.

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 ago
    1) 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 ago
stcredzero 16y ago
Iolanguage has many of these advantages but is far slower, lacks the reach of python's standard library and (I think) also lacks python's awesome list-comprehension syntax. Lua is prototype based. It's also quite fast. What if we ported the Python standard library and added list-comprehension?
- deleted 16y ago
  [deleted]
  - stcredzero 16y ago
    Well, there's already Lunatic Python, so any Python libraries you lack can just be called from a hosted Python VM instance. Also, I think It's possible to add comprehension-like syntax to Lua already.

by cturner 16y ago

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 ago
  1) 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 ago

stcredzero 16y ago

Iolanguage has many of these advantages but is far slower, lacks the reach of python's standard library and (I think) also lacks python's awesome list-comprehension syntax. Lua is prototype based. It's also quite fast. What if we ported the Python standard library and added list-comprehension?

deleted 16y ago
[deleted]
- stcredzero 16y ago
  Well, there's already Lunatic Python, so any Python libraries you lack can just be called from a hosted Python VM instance. Also, I think It's possible to add comprehension-like syntax to Lua already.