3 ms·
how is that not what Python already is: >>> class Foo(object): ... def __init__(self): ... self.x = 1 ... self.y = 2 ..
by zzzeek 14y ago
how is that not what Python already is:
>>> class Foo(object):
... def __init__(self):
... self.x = 1
... self.y = 2
... def bar(self):
... return self.x + self.y
...
>>> Foo().bar()
3
>>> f = Foo()
>>> Foo.bar(f)
3
>>>
- Tuna-Fish 14y agoBut you cannot do it the other way, eg: def foo(bar, baz): print bar.baz + baz f = Foo() f.foo(3) # error
- zzzeek 14y agoClaiming "f.foo" should work when "foo" is a freestanding function strikes me as nonsensical, as the "." operator is a namespace operator, suggesting names that are within the namespace of "Foo". Though Postgresql supports this pattern (http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFUNC-SQL-COMPOSITE-FUNCTIONS http://www.postgresql.org/docs/9.2/static/xfunc-sql.html#XFU...). I think it's awkward there too, and has the caveat "it's unwise to give a function that takes a single composite-type argument the same name as any of the fields of that composite type." - basically it breaks namespacing.
- swift 14y agoIn static languages this really isn't a big deal, since you can dispatch based on type. Things definitely get more awkward if you can do things like define new types at runtime, though.