4 ms·

Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languag

Are you after monkey patching, where you can add new methods outside of the class definition? That's not really a standard feature of all object orient languages - Java doesn't do that, for instance. Python integers are definitely objects: (3).real # returns 3 (3).imag # returns 0 Python's lexer/parser made different choices than Ruby's, so the parens are needed here.

brudgers 8y ago
In no particular order + Java doesn't promise "everything is an object." It has Base Types. + Python doesn't make a semantic promise that "everything is an object." Code for (3).fizzbuzz => "fizz" probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer. At the bottom, '3' is defined in terms of Types (i.e. "Built-in Types") not as an Object. + Ruby's semantic promise that "everything is an object" means: class Fixnum def fizzbuzz() if self % 15 == 0 "fizzbuzz" end if self % 3 == 0 "fizz" end if self % 5 == 0 "buzz" end return self end end And "3" behaves just like any other object. The "everything is an object" promise means that behavior as an object is a cross-cutting concern (or an aspect).
- civility 8y ago
  I'm not sure if you think you're correcting me, but it sounds like you think you've got it all figured out. Java calls them "primitive types", btw.
  - brudgers 8y ago
    I was clarifying the difference between "everything is an object" as technically true and "everything is an object" as a commitment to semantic consistency. Probably because I'm still figuring out these ideas.
- ubernostrum 8y ago
  probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals". You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!
  - brudgers 8y ago
    Python doesn't make me mad. It's frustrating because it's design never makes any sense to me. __init_subclass__ is a perfect example. Not at the level of what __init_subclass__ does. But that instead of implementing private methods, there's are rules around double underscore methods and double underscore methods have different behavior (name mangling). They don't actually make the method private, the actual name is not the name in the source, and the name is not anonomized. I can see a rationale for making some methods private. I can see a rationale for making no methods private. Python doesn't make methods private and then deliberately makes it hard to reap the benefits of this design decision. Instead of implementing the design intent of private methods, what gets implemented are impediments to utilizing the absence of private methods.
    - ubernostrum 8y ago
      Mangling of double-underscore names isn't there to provide access control like in Java or C++. Mangling of double-underscore names is explicitly documented as existing "to avoid name clashes of names with names defined by subclasses". The use case there is a parent class defines a method called, say, "foo". Other methods of the parent call self.foo(). Then a subclass overrides foo() but changes the signature (say, by adding a new non-optional argument), and doesn't override the other methods that call self.foo(). Without name mangling or something like it, this breaks. If the parent class either names the method "__foo" or aliases a copy of the parent class' implementation to "__foo", and calls self.__foo(), name mangling ensures those calls will find the right (as in, compatible) implementation of the method based on where the call came from. That's it. That's the one and only use case for invoking name mangling in Python, and it's a thing that generally you shouldn't be doing anyway. Name mangling also isn't invoked for leading + trailing double underscore -- a "__foo__()" method would not get mangled.

brudgers 8y ago

In no particular order + Java doesn't promise "everything is an object." It has Base Types. + Python doesn't make a semantic promise that "everything is an object." Code for (3).fizzbuzz => "fizz" probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer. At the bottom, '3' is defined in terms of Types (i.e. "Built-in Types") not as an Object. + Ruby's semantic promise that "everything is an object" means: class Fixnum def fizzbuzz() if self % 15 == 0 "fizzbuzz" end if self % 3 == 0 "fizz" end if self % 5 == 0 "buzz" end return self end end And "3" behaves just like any other object. The "everything is an object" promise means that behavior as an object is a cross-cutting concern (or an aspect).

civility 8y ago
I'm not sure if you think you're correcting me, but it sounds like you think you've got it all figured out. Java calls them "primitive types", btw.
- brudgers 8y ago
  I was clarifying the difference between "everything is an object" as technically true and "everything is an object" as a commitment to semantic consistency. Probably because I'm still figuring out these ideas.
ubernostrum 8y ago
probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals". You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!
- brudgers 8y ago
  Python doesn't make me mad. It's frustrating because it's design never makes any sense to me. __init_subclass__ is a perfect example. Not at the level of what __init_subclass__ does. But that instead of implementing private methods, there's are rules around double underscore methods and double underscore methods have different behavior (name mangling). They don't actually make the method private, the actual name is not the name in the source, and the name is not anonomized. I can see a rationale for making some methods private. I can see a rationale for making no methods private. Python doesn't make methods private and then deliberately makes it hard to reap the benefits of this design decision. Instead of implementing the design intent of private methods, what gets implemented are impediments to utilizing the absence of private methods.
  - ubernostrum 8y ago
    Mangling of double-underscore names isn't there to provide access control like in Java or C++. Mangling of double-underscore names is explicitly documented as existing "to avoid name clashes of names with names defined by subclasses". The use case there is a parent class defines a method called, say, "foo". Other methods of the parent call self.foo(). Then a subclass overrides foo() but changes the signature (say, by adding a new non-optional argument), and doesn't override the other methods that call self.foo(). Without name mangling or something like it, this breaks. If the parent class either names the method "__foo" or aliases a copy of the parent class' implementation to "__foo", and calls self.__foo(), name mangling ensures those calls will find the right (as in, compatible) implementation of the method based on where the call came from. That's it. That's the one and only use case for invoking name mangling in Python, and it's a thing that generally you shouldn't be doing anyway. Name mangling also isn't invoked for leading + trailing double underscore -- a "__foo__()" method would not get mangled.