I mean, we still need things like encapsulation, and modularisation - but do that have to go hand-in-hand with OO practise? Aren't there other ways of achieving these things?
The way general concepts sometimes get folded into OO philosophy, in such a way that they are seen as being defined there reminds me of all those TDD arguments that reduce to arguments about regression testing - you can regression test without TDD, just as you can pursue the four-pillars without OO.
Problem is, you can't learn without making your own mistakes, and how can I know what advantages OO bring, without really trying anything else? At this stage, OO is so mature that any other methodologies would come short from sheer lack of popularity. As such, I can't see the forest for the trees - I can't put OO in context, and contrast it with non-OO easily, without all counter-examples being toy examples.
A such, maybe my scepticism is really a yearning for experience outside my bubble. It's healthy to be aversive to a biased perspective, and natural for any truth-seeking, objective professional to want to step outside their experience (if it's too predominated in one particular aspect) to learn more about the things they might be missing, and get a more holistic grasp of the things they know;
You don't realise you can hear the sound of you own breathing until you enter a quiet room; You don't perceive your own thoughts until you stop and try to be mindful of them; you don't properly understand the concepts/forms given to you, unless you know what else they could have been, and why they aren't that;
This often will require knowledge of their history, the constraints and influences that shaped them, and as such the meaning, philosophy and design decisions baked into their final form - often the forms they where not created (and why that was) is often needed to be known.
BTW - I know this stream (first post here) is a bit ranty, starting from a single thought on JS, and leading to a very general thought - intend to clean this up at a later date. For now, I'll publish or perish!
class someclass: someattr = "foo" def somemethod(self): #self.y = self.y self.__class__.someattr = "bar" print self.someattr someclass().somemethod()
interesting how that commented-out line makes a difference - I just learned a quirk of the python scoping rules.
Here's another one :
f1 = lambda : 1 f2 = lambda : 2 closure = lambda *x: x foo, bar = closure(f1, f2) f2 = lambda : 3 baz, = closure(f2) # another way to do above closure2 = lambda *x: x if len(x)>1 else x baz = closure2(f2) f1 = lambda : 4 f2 = lambda : 5 print foo(), bar(), baz() # 1 2 3
Interesting how lambdas can make closures.
This also works with regular functions (def); It's the parameters that become lexically bound.
Anyone know how to define self-contained python function (but not a generator) that returns different values each time it is called ?
def somefunc() // define here somefunc() # 1 somefunc() # 2 somefunc() # 3 ...
I guess we'd just need to store state somehow.
I don't think functions can rebind their variables (pass-by-value, not reference), so that's out.
Could a function that can redefine itself directly (acting on the function object)?
def clos(): def func(): func.val += 1 return func.val func.val = 0 return func foo = clos() print foo(),foo(),foo() # 1 2 3
Some other ideas; using global variable :
def redef(): global func f = (lambda x: x)(func) func = lambda : f()+1 return 1 func = redef print func(),func(),func() # 1 2 3
defined as bound method on class instance :
class Foo: def bar(self): return 0 def baz(self): bar = (lambda x:x)(self.bar) self.bar = lambda : bar()+1 return self.bar() foo = Foo() print foo.baz(),foo.baz(),foo.baz() # 1 2 3
And as a static class method :
class Foo: x=0 @classmethod def baz(cls): cls.x += 1 return cls.x foo = (lambda x:x)(Foo) class Foo: pass print foo.baz(),foo.baz(),foo.baz() # 1 2 3
Mutable (list) to store state (fudged to be able to use lambda...) :
foo = (lambda z: lambda :z.append(z+1)==None and z.pop(0))() print foo(),foo(),foo() # 1 2 3
Any other ideas?
I think in terms of building career and skillset, it's important to recognise the difference between being busy, and being productive...
Note to self: next time I move, order some moving boxes.