On 2021-06-22 5:34 p.m., Brendan Barnwell wrote:
On 2021-06-22 13:09, Soni L. wrote:
Think about it like this, extension methods give you the ability to make imported functions that look like this:
look like this instead:
That's all there is to them. They're just a lie to change how you read/write the code. Some languages have an whole operator that has a similar function, where something like bar->foo(baz) is sugar for foo(bar, baz). The OP doesn't specify any particular mechanism for extension methods, so e.g. making the dot operator be implemented by a local function in the module, which delegates to the current attribute lookup mechanism by default, would be perfectly acceptable. It's like deprecating the existing dot operator and introducing a completely different one that has nothing to do with attribute lookup!
Okay, if that's the case, then I just think it's a bad idea. :-)
We already have a definition for what bar.foo does, and it's totally under the control of the bar object (via the __getattr__/__getattribute__ mechanism). The idea that other things would be able to hook in there does not appeal to me at all.
I don't really understand why you would want such a thing, to be honest. I feel it would make code way more difficult to reason about, as it would break locality constraints every which way. Now every time you see`bar.foo` you would have to think about all kinds of other modules that may be hooking in and adding their own complications. What's the point?
Mostly the whole benefit of the dot notation is that it specifies a locally constrained relationship between the object and the attribute: you know that bar.foo does what bar decides, and no one else gets any say (unless bar asks for their opinion, e.g. by consulting global variables or whatever). If we want to write foo(bar, baz). . . well, we can just do that! What you're describing would just make existing attribute usages harder to understand while only "adding" something we can already do quite straightforwardly.
Imagine a similar proposal for other syntax. Suppose that in any module I could define a function called operator_add and then other modules could "import" this "extension" so that every use of the + operator would somehow hook into this operator_add function. So now every time you do 2 + 2 you might be invoking some extension behavior. In my view that is unambiguously a road to madness, and as far as I can tell the extension mechanism you're proposing is equally ill-advised.
Imagine if Python didn't have an + operator, but instead an + *infix function*.
Thus, every module would automatically include the global
def infix +(left, right): ...
And indeed, you could say we already have this. Except currently you can't define your own local infix +. But what if you *could*?
What if you could just,
# file1.py def infix +(left, right): return left << right x = 4 + 4
# file2.py def infix +(left, right): return left ** right x = 4 + 4
# file3.py import file1 import file2 print(file1.x) # 64 print(file2.x) # 256 print(4 + 4) # 8
How does this break locality?
Same idea with the dot operator, really.
(Some languages don't have operators, but only functions. They let you do just this.)