"Larry Garfield" <larry@xxxxxxxxxxxxxxxx> wrote in message news:200710092010.28208.larry@xxxxxxxxxxxxxxxxxxx > On Tuesday 09 October 2007, Tony Marston wrote: > >> 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. > > Classic OOP (C++/PHP/Java, etc.) is, really, an extension on top of > procedural > programming. Nothing that you do with objects couldn't be done without > them. > They are equally expressive. > > OOP is just syntactic sugar to make writing certain logical structures > easier > (less code, more readable code, code that's harder, but not impossible, > for > someone else to break, etc.). There is absolutely nothing that can ONLY > be > achieved through, for instance, interfaces. It's just that interfaces > make > it a hell of a lot easier to solve certain problems than doing everything > with non-dynamic functions. > > Anything you can do with functions you can also do with GOTO statements. > functions are just syntactic sugar to make writing logical structures > easier. > Until you can explain, with examples, some problem that can ONLY be solved > through the use of functions I will continue to say that they are a waste > of > time. > > Anything that you can do in PHP you could also do in assembler. PHP is > just > syntactic sugar to make writing logical structures easier. Until you can > explain, with examples, some problem that can ONLY be solved through the > use > of PHP I will continue to say that it is a waste of time. > > Yes, I am making fun of you for a piss-stupid Luddite argument. :-) But you still cannot provide a convincing argument for using interfaces. The fact that you CAN use interfaces does not mean that you MUST use interfaces. I manage to get by without them. >> *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. Encapsulation does not REQUIRE data to be hidden. It is an option, therefore I have the right to exercse the option of ignoring it. > *My* definition of dark green is *the* definition as it was originally > intended. The fact that other smart-ass numbskulls have corrupted it with > their own stupid saturation embellishments is something which I choose to > ignore. > > (Yes, I am making fun of you again.) What a pathetic example. >> > 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. > > Here's a better reason to not bother learning PHP 4-style OOP. You have > less > than a year until running PHP 4 at all is considered an unsupported > security > risk. Don't waste your time, since PHP 5 OOP IS different, because > reference > handling changed drastically which means what is "fast and easy" in PHP 4 > OOP > and what is "fast and easy" in PHP 5 OOP is hugely different. That still does not hide the fact that PHP 4's OOP style is still perfactly valid. As for the new features in PHP 5, I shall only use them when they can provide demonstrable benefits, and not just "because they are there". >> > 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. > > Because I want to syntactically guarantee the existence of certain methods > so > that I can reliably call functionality on them. But if you have defined a method in a class then the method exists. You do not need a separate interface to make that method accessible. That is my whole point - interfaces are optional, not mandatory, and I have never found agood reason to use them. > Call-and-pray is an > unreliable methodology. Yes, that is syntactic sugar. See above. If you try to call an object method which did not exist you would soon know about it, interface or not. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > Can we stop with the pissing contest now? > > -- > Larry Garfield AIM: LOLG42 > larry@xxxxxxxxxxxxxxxx ICQ: 6817012 > > "If nature has made any one thing less susceptible than all others of > exclusive property, it is the action of the thinking power called an idea, > which an individual may exclusively possess as long as he keeps it to > himself; but the moment it is divulged, it forces itself into the > possession > of every one, and the receiver cannot dispossess himself of it." -- > Thomas > Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
