On 07/08/12 06:19, Steven D'Aprano wrote:
On Mon, 06 Aug 2012 09:55:24 +0100, lipska the kat wrote:
On 06/08/12 01:22, Steven D'Aprano wrote:
On Sun, 05 Aug 2012 20:46:23 +0100, lipska the kat wrote:
[snip]
The clue is in the name 'Object Oriented' ... anything else is (or
should be) implementation detail.
So your argument is that any programming which is "oriented" (meaning
what?) towards "objects" (which are...?) is OOP, and everything else is
"implementation detail".
Well now I'm enlightened. That certainly clears that up for me.
Glad I could help :-)
[snip]
As you go on to explain:
A class variable is static and can be
accessed without instantiation an instance variable is accessed via an
instance
which are semantic differences, differences in meaning and function.
Yes but when we TALK about these things a String variable is a String
variable is a String variable. The words 'Class variable' and 'instance
variable' are 'abstractions'. It saves us saying,
'this is a variable that can only be accessed from an instance and may
hold values of the type Integer or String or Weak Reference ... (and so
on ad nauseum) ... but only of one type unless you count runtime
polymorphism in which case the runtime type may be different from the
compile time type ... etc etc'
or 'this is a variable that can be accessed without instantiating a
class (see above)'
If you don't like the term abstraction then perhaps we can agree on
something else.
Since a "string variable" is a variable holding a string, and a "float
variable" is a variable holding a float, an instance variable should be
a variable holding an instance, and a class variable should be a
variable holding a class.
See above
Class variable and instance variable are higher level abstractions.
Of what? Of variables?
Exactly, now you're getting the hang of it
[snip]
Simply put, the choice of terminology is crap --
possibly but it's the best we've got.
But what *really* gets me is not the existence of poor terminology. I
couldn't care less what terminology Java programmers use among
themselves.
I'd be most grateful if you could park the whole 'This person is a 'Java
developer so must be a moron thing' it's getting a bit wearing.
As I said in a previous post, Java has indeed been good to me but my
brain IS capable of dealing with more than one language.
What gets me is that the ubiquity of them means that
substandard terminology spreads into other languages, like dryrot.
Yea well welcome to the world of spin, if you can't fight it then learn
to roll with it.
The ONLY concept that you should never try to encapsulate is/are human
beings or their aliases.
snip
Is this some sort of mystical "humans aren't objects, they're
SPECIAL!!!" rubbish? Because it sure sounds like it.
[snip]
Well now this is a personal thing born of bitter experience. In my
experience, when you have an entity called 'Person' or some such in your
Class model it soon becomes what we 'in the trade' call a 'God Object'
The name should be self explanatory but hold tight, here comes some more
jargon.
Objects can have a 'has a' relationship with other Objects or an 'is a'
relationship with other objects
The 'has a' relationship means that an Object 'owns' another object, the
'is a' relationship means that an Object 'is of a particular type'
Of course in an 'Object Oriented' language such as Java an Object
reference can have a different type at runtime than it does at compile
time. In Python too.
Anyway, this Person thing soon ends up with a 'has a' relationship with
everything in sight. a Person 'has a[n]' Address, a Person 'has a[n]'
account, a Person 'has a' Doughnut etc etc etc
Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a
Person 'is a' security risk, well you get the idea.
Of course this is a problem with the actual design process itself and
yes, the identification of the 'nouns in the language of the domain' is
an important part of the process. Sorry, but it just works when it's
done properly, I know it works as I used this technique to turn around
this 'Person as God' design from a failing money pit into a working
system that delivered (almost) on time. The very first thing I did was
to exorcise Person from the design.
I've already managed to write meaningful code but I haven't invented a
single class yet.
And why do you think this is a problem?
A problem? I wasn't ware that I'd stated it was a problem it just
You said "BUT [emphasis added] I haven't invented a single class yet",
which implies that this is a bad thing
[snip]
No it implies that I noticed it was possible to do meaningful work in
Python without writing a class.
Well this HAS been fun, I look forward to your reply but at the moment I
have to go and pick some runner beans as it's been a fantastic year for
beans and the freezer awaits.
lipska
--
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
--
http://mail.python.org/mailman/listinfo/python-list
