""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message news:7dd2dc0b0710090750n7e5d59dy822a4f565a5b040b@xxxxxxxxxxxxxxxxx > On 10/9/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> You are confusing member variables with local variables. Member variables >> are part of the object's data which need to be made available to the >> outside >> world. Local variables are internal to the function, and do not need to >> be >> made available to the outside world. Local variables are part of the >> implementation, member varables are not. > > > no im not confusing anything; > local variables are within the scope of the function; therefore they are > part of the function > implementation. > instance variables are part of the scope of a class instance, therefore > they > are part of its > implementation. > > "Implementation" means the act of changing data, therefore it means the > code >> and not the data itself. > > > code is nothing w/o data to manipulate; what is an algorithm w/o data to > manipulate; it simply would not exist. I disagree. The dictionary definition of "implementation" is "an activity or process". The fact that an implementation works with data does not make that data part of that implementation. Data is free standing and can be maniplated by several different implementations, and an implementation can work with with any set of data. So implementation, or the activity/process, means nothing more than the code, with the data being separate and independent. > <snip> >> >> > it is also about client code not being able to view and manipulate the >> > implementation. >> > if client code can access data that the implementation (as you define >> > it >> > [not consisting of data]) >> > uses, or relys upon, then the outcome of the implementation can be >> > altered by client code. >> >> Then surely if a programmer fucks things up in such a fashion it would >> become apparent during unit testing? Then the culprit can be soundly >> whipped until he learns NOT to fuck up. > > or better yet; protect the implementation so he wouldnt have to be > whipped > in the first place. A bad programmer will ALWAYS find new and obscure ways to fuck up. Isn't it the abuse of inheritance which spawned the idea of object composition as a replacement for inheritace? >> that is a violation of encapsulation, >> >> I disagree.Encapsulation is the act of placing the data, and the >> operations >> which act upon that data, in the same object. A violation of >> encapsulation >> is therefore to put the data and its operations in more than one object. >> Encapsulation has absolutely nothing to do with how those objects are >> used >> (or abused). >> >> > The fundamental concepts of OOP consist of nothing more than >> > encapsulation, inheritance and polymorphism. Data hiding, interfaces >> > and all that other fancy stuff are irrelevant. >> > >> > youre missing out on like the last decade or so of oop. >> >> I am sticking to the fundamentals and deliberately ignoring all the crap >> which has been added on by everybody and his dog. > > hmm; the rest of the oop community seems to be flocking to the crap. The fact that others flock like mindless sheep to the latest fad or fancy just shows how gullible they are. >> >>> im not going to take the >> >>> time to try and explain the power of the interface construct. imho, >> >>> you have a long way to >> >>> go before you can grasp the power of the mechanism. >> >> >> >> I have never seen any gain from using interfaces in PHP, only pain, >> >> therefore I refuse to use them. Yet what functinality I am losing? >> >> None >> >> whatsoever. >> > >> > not every system will benefit from interfaces. >> > it sounds like you dont fully understand the use of them; and i wont >> > say >> > its immediately obvious. >> >> If it is not obvious in the way that interfaces can provide benefits then >> they are useless as far as I am concerned. I have never seen ANY >> documentation which shows ANY benefits from using interfaces, so I simply >> do not see the point in using them. >> >> > as i said they offer an additional polymorphic mechanism >> > one that php4 doesnt supply. >> >> I can achieve all the polymorphism I need WITHOUT using interfaces, so I >> do not see the point in using them. > > > like i said not every system will benefit. > >> >if you want a great example of how they are used and when extension is >> >not >> > desirable (because the behavior is passed along) read the first chapter >> > of heads first design patterns. >> >> I refuse to read any more books on design patterns. In my opinion they >> are >> abused, over-used and over-rated. Just because one or two design patterns >> use interfaces does not mean that interfaces are the best thing since >> sliced >> bread. > > > it would be nice if you saw just one example why they are sometimes better > than inheritance and therefore useful. I have bought and read several books on design patterns without being impressed. I have seen countless examples of how particular design patterns can be implemented, and I am even more unimpressed. Unless you can explain, simply and with simple examples, of things that can ONLY be achieved through the use of interfaces then I will continue to say tha they are a waste of time. >> >>> in summary, i still maintain, based upon the contents of this post >> >>> and >> >>> the many previous posts that sitting down and trying to learn oop >> >>> with php4 is a waste of time. >> >> >> >> I strongly disagee. It *IS* possible to write perfectly adequate OO >> >> programs >> >> using PHP 4. If you cannot then you have been taught some bad habits. >> > >> > >> > actually, im trying to illustrate bad habits so they may be avoided by >> > other developers. >> > >> > That is just your opinion. My opinion is totally different. >> > >> > >> > thats why i gave an alternate critique based upon your definition of >> > encapsulation. *My* definition of encapsulation is *the* definition of encapsulation as it was originally intended. The fact that other smart arse numbskulls have corrupted it with their own stupid embellishments is something which I choose to ignore. >> > also, i should mention its occurred to me that the abstract class >> > mechanism in php5 is superior to your mechanism in php4. >> > if a method marked as abstract in php5 is not overridden by client >> > code, >> > an error is raised at >> > compile time, and the class is not allowed to be utilized. >> >> This still does not get away from the fact hat it is still possible to >> create an absract class in PHP 4 without having to use the keyword >> "abstract" in the class definition. The PHP 5 implementation may be >> superior, but it is still possible in PHP 4 (if you are a competent >> programmer, that is) > > > but you admit, the php5 construct is better and therefore strengthen my > initial argument, which was, if php5 is better and php4 is deprecated; why > bother > w/ php4. Your statement was that it would be absolutely pointless trying to learn OOP with PHP 4 which implies that it is not possible to write object oriented programs wth PHP 4 at all. That is absolute crap as PHP 4 provides ALL the basic necessities for OOP, which are encapsulation, inheritance and polyorphism. One must learn the basics before attemping to use any advanced features, but quite frankly I have found the additional features within PHP 5 to be totally irrelevant. I have written a large application in PHP 4 which runs exactly the same with PHP 5, and I have yet to find anything that I need to do that can only be done using PHP 5. >> > btw, interface hierarchies are like class hierarchies; one interface >> > can >> > extend another. >> >> So what? One class can extend another. The "extends" keyword does not >> rely >> on interfaces. > > > if you read that one chapter i recommended you will see; acquiring the > behavior of the parent is not always desirable. Then why inherit from the parent in the first place? Or why not create a method in the subclass which overrides the method in the superclass, thus changing the behaviour to what you prefer? I certainly don't need interfaces to do that. -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
