M
mystilleef
Bruno said:doh
Let's talk about psychorigid mindset...
Thanks, I'm insane.
To allow attribute syntax when you really have computation behind. Which
1/ let you start with the simplest case (a simple attribute) and change
your mind latter
2/ offer the possibility to use an attribute syntax (instead of a method
call syntax) when it seems more natural.
Right, and what I'm I trying to do again?
You can do just the same in Java or C++.
OMG!
I'm deadly serious and definitively not joking. There's no cure for
idiocy, and there's definitively nothing like an idiot-proof system.
Sure, but calling users idiots for as result of your laziness or poor
design or lack of robustness is equally idiotic.
IOW : you're unable to find any valid reason to use the second solution
instead of the first (of course : there's none), but refuse to admit it.
Hey, I didn't write that code. You did! You deal with it. My input on
__your__ code at this point is irrelevant.
You are not controlling *anything*
r = Robust()
r._Robust__is_active = True
*sighs*
You keep coming up with these unrealistic and impractically delusional
theories to make yourself feel happy. Sure Python lets your do that,
but that's an implementation detail almost all Python developers could
give a damn about. How many times do I have to tell you I don't care
for latent semantic implementation details of Python? Anybody who does
what you just did should be laughed at derisively and ignored. But I
don't have time to deal with fantasy and unreleastic theories.
As I told you, there's no cure for idiocy.
And what if you want to change 'buffer_is_active' to 'is_active' ?
But I don't want to. I wanna change implementation not interface.
Lol. cf above. And, may I repeat : you're getting the "my/3rd part"
stuff the wrong way. If someone uses your code in it's app, then it's
*her* system, and *your* code is the '3rd part'. Whether someone wants
to do idiotic things with your code that will result in a crash is none
of *your* concern. Just like if someone buy a hammer and bangs his head
with, it's not the concern of the guy who made the hammer.
That's just silly. If a third party plugin is crashing your app, guess
who's gonna get the emails and bug reports? That's right you! And that
is after hours of trying to reproduce the bug on your system
unsuccessfully because you don't have the bloody plug-in installed and
they user doesn't know a random plug-in he downloaded is the root of
the problem. Welcome to reality.
So you see receiving a bug report as a form of ridicule ?
Yes, it can be.
Now FWIW, I have lot of python apps in production, very few bug reports
[1], and none of them being the result of the problem you seems to fear
that much.
Good for you! I'm sure you are brilliant programmer.
[1] The very first release of one of them is in production for more than
6 monthes now, is daily used by a dozen non-computer-savy users, and not
a *single* bug report - actually, the only return we had is "it's
perfect, it works like a charm, and we have some other stuff for you guys"
My users are not just end users they are also developers. Again, I'm
glad you are seeing success in __your__ projects.
In my example (which was not intended as a "solution to a problem"),
is_active is clearly part of the API. So your argument is moot.
OTOH, if I need to control access to is_active, I can easily change it's
implementation - ie by using a property (or any custom descriptor). So
my "solution to the problem" is functionally equivalent to yours, and
requires much less code - which contributes to making it more robust.
Your example actually requires more code, is looks complex and it's
ugly (no offense, my opinion).
Oh yes, I can :
- too much exposure to B&D languages
- lack of ability to criticize "what's in the Book"
- confusion between state/behaviour concepts and the (mostly inexisting
in most hi-level languages) data/function dichotomy
- control-freak mindset
Lets stick to the arguments please. No need to attack me.
You're wasting your time because you refuse to escape from your "what's
in the book" mindest and insist on writing Java in Python. I had the
same problem when I came from Java to Python, then I had the "aha"
moment where I realized I was overdoing it, writing uselessly
complicated code to do simple things that would just have worked without
all this mumbo/jumbo control freak stuff. But it seems you prefer to
stick to your masochistic approach for no other reason than
misunderstood concepts, so we can't help you here.
Fantastically, I have never used Java for any public project. I don't
understand how you reach your faulty assumptions. You don't know my
background with any language so quit this "Java is the reason you think
like this" banter.
Lol. I actually did *un*learn the hard way.
Mystilleef, I've started programing 17 years ago, and have done it
professionnaly for almost 10 years now. I do not pretend to be a good
programmer, but please believe that I do know my job. I've read the Book
too, I've tried applying it blindly, then I used my brain. Once you
understand the real reasons behind a "rule", you also understand when
and how to apply or not apply it.
What book are we talking about again? I made these rules from my
experience writing programs in Python, not from any book. There's only
so much books can do when it comes to designing robust software in
practice. But for a lot of people over here who claim they've been
programming for X number of years, some of them certainly do need to
hit the books again. I don't believe I spent an inordinate amount of
time explaining state and behavior or the benefits or techniques for
reducing coupling or why anyone would need accessors, among other
things.
The problem is that you definitively *failed* to understand how to use
them (or actually how to *not* use them when not needed).
Sure, if it makes you feel better.