On 10/7/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:
>
> > it just so happens i
> > have a good friend with a very strong php background who tells me
> > practically the same thing, ppp isnt that big of a deal.
>
> It isn't.
i disagree.
> i disagree, why,
> > is it because ive had a classical education in oop
>
> What the heck is a classical education in OOP? Are you saying your old
> and therefore smarter? Young and therefor smarter? WTF?
just saying i studied oop in college. i started w/ c++; moved on to java
and then took a brief look
at .net and delphi (very brief :)) anyway coming from those languages to
php4,
well php4 looks minimalistic.
age has nothing to do with it; i provided 4 definitions from 4 books
on oop; they all conicide w/ what ive been saying about encapsualtion;
infact they practically
say encapsulation is data hiding.
i would like to see an example of encapsulation where data hiding isnt
required to conceal the
implementation.
> , because ive worked with
> > a number of languages that dont allow you to create class members
> without
> > specifying an access level?
>
> Many of us have done this. Your point?
php4 is the first language i encountered that didnt offer ppp.
> for those reasons and because ive had the
> > misfortune of working in places that have tightly coupled code. im
> talking
> > about hundreds of thousands of lines of madness. ppp could have saved
> these
> > systems greatly.
>
> Once again, just because someone writes bad programs doesn't make PPP
> the superior choice. A shitty programmer faced with PPP will more than
> likely declare all of their member variables as public and as such will
> have gained nothing.
>
> > Also, don't forget that abstraction, encapsulation, and information
> > > hiding all have a price
> >
> > if youre referring to performance i think the price of not using these
> tools
> > is also worth mention. namely code which is easily subject to tight
> > coupling, which as i said leads to systems that are difficult to
> maintain
> > and extend.
> > personally i value maintainability and extensibility over performance,
> but
> > thats merely a personal preference.
>
> Tell that to an embedded systems programmer.
ok.
embedded systems programmer - i develop web applications w/ php. i use oop
and build systems designed for large audiences and large numbers of
developers.
being able to extend, modify, and maintain the code are more important than
small
performance gains here and there; because i can always call dell for another
1u.
> (tony)
> > > I strongly disagree. It *IS* possible to write perfectly adequate OO
> > programs
> > > using PHP 4. If you cannot then you have been taught some bad habits.
>
> Hear hear.
on the contrary, im trying to emphasize what i have learned to be bad habits
so others
might not use them in the first place. one of which i have mentioned
is allowing direct access to class members. and i was never taught to do
that, because as
i mentioned, i worked with languages that require use of ppp in the past,
and one of the first
things thats covered is marking member variables private, and certain member
functions of
course.
> and what exactly does adequate mean? any oo php4 'program' is inherently
> > weak for the reasons i have sighted, namely the implementation can be
>
> I'm sur eyou meant "cited" above.
yes
> latched onto producing tightly coupled code.
> > dont worry tony, i can construe some pretty decent php4 code myself; i
> wrote
> > a date time package that ive ported to 3 projects including a conversion
> to
> > php5 in one of those. the point is that the other developers i work
> with
> > dont have a clue about object oriented concepts which in my experience
> > constitutes the vast majority of php developers. the even bigger point,
> on
> > the topic of this thread is that php4 is out the door, so there is yet
> > another possibly more important reason not to waste time learning oop
> > studying php4.
>
> Once again, if you suck at programming you suck at programming. Those
> sucky programmers are probably going to declare all their member vars
> public, aren't going to understand encapsulation, probably will have
> terrible class hierarchies, etc. You can't make a good programmer by
> holding their hand.
again; all the books ive ever read on oop, show class member variables being
marked private.
also, they emphasize protecting certain methods as well. php4 doesnt offer
ppp, so it opens
the door to bad habits.
you can however protect your underlying codebase from misuse. how practical
is it
to get a company that consists entirely of excellent programmers?
> ive studied oop for years and worked with a number of oop languages; many
> of
> > the bad habits i had at one point or another have been removed. guess
> what
> > the first one was, not letting client code access member variables
> directly
> > :)
>
> I've worked with many languages too. I found my code getting better
> while using C. I learned to properly prefix function names, collect them
> together in the same file, use structures instead of 20 parameter
> functions, etc. Lessons are learned wherever you spend your time.
>
> > if you dont mind brittle oop code, php4 will suffice. if you want to
> tap
> > into real object oriented features, many of which i consider fundamental
> > (such as ppp [to name just one]) go for php5. truthfully i still think
> > there are some features missing; interface hierarchies being the main
> one,
> > perhaps well get lucky in php6...
>
> Nothing brittle at all about PHP4 code. I can completely screw up any
> PHP5 code you send my way too.
>
ok;
without modifying this class, set the value of $someInt to a value greater
than
100 or less than 0.
class TryToViolateEncapsulation {
private $someInt = 0;
public function getSomeInt() {
return $this->someInt;
}
public function setSomeInt($someInt) {
$success = false; // assume failure
$someInt = (int) $someInt;
if($this->isValid($someInt)) {
$this->someInt = $someInt;
$success = true;
}
return $success;
}
private function isValid($someInt) {
$isValid = true;
if($someInt < 0 || $someInt > 100) {
$isValid = false;
}
return $isValid;
}
}
-nathan
