Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Rasmus Lerdorf wrote: Jochem Maas wrote: I understand the point you made below - you have made this argument before and I, for one, accepted it as valid when I first read the discussion on internals - which is why I avoided ranting about that (and changes like it) But you didn't avoid it, you used it as an example to back up your rant. that wasn't me that was Robert in a reply to my rant. And on the OO side your argument gets shaky as well. The whole point of OO is to add a very structured layer on top of your code to make it more consistent and more maintainable than the equivalent procedural code. There is nothing you can do in OO that you can't do with completely freeform procedural code. When you choose to go OO, you choose a set of rules and a certain code structure that by definition is going to be somewhat constrained. The argument over exactly how constrained this should be and where we should loosen things up will continue until the end of time. PPP and Interfaces are all about constraints. They serve no practical purpose whatsoever other than to add constraints. the point I *tried* to make (granted maybe not very well) was that the engine constraints behaviour themselves are not particularly consistent *and* they change too often and in too arbitrary a fashion. ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
hi Rasmus,
I understand the point you made below - you have made this argument before
and I, for one, accepted it as valid when I first read the discussion
on internals - which is why I avoided ranting about that (and changes like it)
But I am wondering what if any your views might be on the original rant (mine)
regarding purism/strictness that [I feel] is creeping into php for no good
(read 'pragmatic') reason?
as an example - I have in the past argued that discontinuing the ability to
define static methods in interfaces was against the grain and was given the
reply 'you don't understand OO fix your code' - in the last couple of weeks
static interface methods were reintroduced to help in a situation highlighted
by Derick R. I have had pretty much the same experience regarding late static
binding - to which (though nothing to do with my pleas) has finally been
capitulated
for inclusion in php6 not inducive to an optimal uptake of php5 which given
the length of time it's been out is rather dismal when compared to the speed at
which php4 was taken up.
if you agree at all with my postulation then maybe you also see some need
to address the issue?
kind regards,
Jochem
Rasmus Lerdorf wrote:
Robert Cummings wrote:
Well there was a segfault, but that's fixed now, now the warning is
thrown because of some purist attitude that says it's incorrect to pass
a literal to a reference expecting parameter... I can see how that's an
issue in C with pointers, or in a strongly type language like Java, but
part of PHP's popularity is that while it shares a lot of functions with
C, it is neither C nor Java, but rather a much simpler system that
generally for all the novices out there works well.
Stuff like this is a bug in your code. It has nothing to do with purism:
function inc_arg($arg) {
$arg++;
}
inc_arg(3);
You have specifically defined your function to modify the argument yet
you pass it something that has no storage and thus there is no way to
use that modification. For the most part I agree that we need to keep
the language as flexible and forgiving as possible, but where we are
able to detect code that obviously doesn't do what the programmer
intended, it is tremendously helpful to get a descriptive error.
As far as functions returning references, you are right that returning a
literal there sometimes makes sense, but this can also hide a bug which
is why this only throws a notice.
You could argue that we could try to look ahead and see what is actually
done with the passed argument to see if it is modified, or that we could
try to figure out whether the returned reference is actually used as
such, but that is technically extremely difficult given the way things
work internally. So given the choice between ignoring extremely
suspicious code like this and throwing an error/warning, I'd rather be
told about it and in the edge cases where I really do want the
equivalent of a NOP in my code, it isn't that hard to force it by adding
a dummy storage variable along with a comment explaining why you need to
do that.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Jochem Maas wrote: I understand the point you made below - you have made this argument before and I, for one, accepted it as valid when I first read the discussion on internals - which is why I avoided ranting about that (and changes like it) But you didn't avoid it, you used it as an example to back up your rant. And on the OO side your argument gets shaky as well. The whole point of OO is to add a very structured layer on top of your code to make it more consistent and more maintainable than the equivalent procedural code. There is nothing you can do in OO that you can't do with completely freeform procedural code. When you choose to go OO, you choose a set of rules and a certain code structure that by definition is going to be somewhat constrained. The argument over exactly how constrained this should be and where we should loosen things up will continue until the end of time. PPP and Interfaces are all about constraints. They serve no practical purpose whatsoever other than to add constraints. And saying that these OO issues is slowing down PHP 5 uptake is a bit of a red herring. We are competing against ourselves. PHP 4 works extremely well. There is a lot of code written for it and it works. I seriously doubt very many people are not upgrading to PHP 5 because of some debatable edge-case OO thing. People are not upgrading to PHP 5 because PHP 4 works just fine for them and they haven't yet discovered things like SimpleXML and some of the other killer features of PHP 5. -Rasmus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
I get this sometimes, it often means I have overlooked something: Fatal error: Access to undeclared static property: AreaAgendaItem::$extraFields EVERYWHERE in php an unset var causes an E_NOTICE, but if you dare to use OO then all of a sudden the OO nuthouse runs out to put a straight jacket on you, and it's getting worse and worse. (not that this example is new) why don't the purists get that we don't need to be told at every step what is correct and what is not?? but merely to be stopped from doing things that are dangerous (as in liable to cause a segfault). eight months ago (roughly) I was told repeatedly that static interface methods were WRONG and so I wouldn't be allowed to user static interface methods anymore (fix my code was the gruff reply) - a few weeks ago static interface methods were included in php5.2(?) as a work around for some other OO deficiency (I can't remember the details but it was Derick Rethans that was suffering from whatever straight jaket had just been introduced). PHP embracing The One and Only OO Paradigm(tm) [a schizoid paradigm liable to change at the drop of a hat] [RANT OFF - flame away boys and girls] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
At 4:01 PM +0200 6/1/06, Jochem Maas wrote: I get this sometimes, it often means I have overlooked something: Fatal error: Access to undeclared static property: AreaAgendaItem::$extraFields EVERYWHERE in php an unset var causes an E_NOTICE, but if you dare to use OO then all of a sudden the OO nuthouse runs out to put a straight jacket on you, and it's getting worse and worse. (not that this example is new) why don't the purists get that we don't need to be told at every step what is correct and what is not?? but merely to be stopped from doing things that are dangerous (as in liable to cause a segfault). eight months ago (roughly) I was told repeatedly that static interface methods were WRONG and so I wouldn't be allowed to user static interface methods anymore (fix my code was the gruff reply) - a few weeks ago static interface methods were included in php5.2(?) as a work around for some other OO deficiency (I can't remember the details but it was Derick Rethans that was suffering from whatever straight jaket had just been introduced). PHP embracing The One and Only OO Paradigm(tm) [a schizoid paradigm liable to change at the drop of a hat] [RANT OFF - flame away boys and girls] Not a flame, but just my take -- dummy-up, you'll sleep better and produce more code. :-) tedd -- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Jochem Maas wrote: I get this sometimes, it often means I have overlooked something: Fatal error: Access to undeclared static property: AreaAgendaItem::$extraFields EVERYWHERE in php an unset var causes an E_NOTICE, but if you dare to use OO then all of a sudden the OO nuthouse runs out to put a straight jacket on you, and it's getting worse and worse. (not that this example is new) why don't the purists get that we don't need to be told at every step what is correct and what is not?? but merely to be stopped from doing things that are dangerous (as in liable to cause a segfault). eight months ago (roughly) I was told repeatedly that static interface methods were WRONG and so I wouldn't be allowed to user static interface methods anymore (fix my code was the gruff reply) - a few weeks ago static interface methods were included in php5.2(?) as a work around for some other OO deficiency (I can't remember the details but it was Derick Rethans that was suffering from whatever straight jaket had just been introduced). PHP embracing The One and Only OO Paradigm(tm) [a schizoid paradigm liable to change at the drop of a hat] [RANT OFF - flame away boys and girls] Do what I do, and don't do OO. ;) -- John C. Nichel IV Programmer/System Admin (ÜberGeek) Dot Com Holdings of Buffalo 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
John Nichel wrote: Do what I do, and don't do OO. ;) In other words, do what works, realizing that 99 percent of the time that you're doing indivdual sites, and ignore dogma? Hmm, what a concept! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
John Meyer wrote: John Nichel wrote: Do what I do, and don't do OO. ;) In other words, do what works, realizing that 99 percent of the time that you're doing indivdual sites, and ignore dogma? Hmm, what a concept! Actually, the company I work for operates multiple sites which all share code. From copying and pasting between sites, to the 'global include' directory I have set up with functions shared by all the sites. No OO. If it ain't broke, don't fix it. (sorry about the direct mail) -- John C. Nichel IV Programmer/System Admin (ÜberGeek) Dot Com Holdings of Buffalo 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
On Thu, 2006-06-01 at 15:01, John Meyer wrote: John Nichel wrote: Do what I do, and don't do OO. ;) In other words, do what works, realizing that 99 percent of the time that you're doing indivdual sites, and ignore dogma? Hmm, what a concept! Other than basic inheritance and the namespace features provided by classes, I don't see much else that is critically useful. There's was a strange push for all kinds of advanced OO features in PHP5 and somehow that got some kind of ball rolling to make things more and more complicated. Other than the pass objects by reference by default feature of PHP5 and better constructor/destructor support... the rest is just tooth decaying candy... and Jochem seems to be getting cavities it seems -- time to floss and brush the crud away ;) One of my biggest peeves about stuff changed that worked but wasn't necessarily purist... not letting values be passed to functions expecting a reference parameter. I mean really, PHP knows it's a literal, so why can't it just make it safe. Ugh. Nope, now we gotta add an extra line of userspace code to first assign the value to a variable to do exactly what PHP could so much faster do for us. Similarly functions returning references. Used to be you could return a null or false value on encountering a problem... but noo, now you have to spank youself and write $retValue = null; return $retValue. *pt*. BTW, I still love PHP :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Robert Cummings wrote: On Thu, 2006-06-01 at 15:01, John Meyer wrote: John Nichel wrote: Do what I do, and don't do OO. ;) there an 'oo baby' joke in there somewhere :-) In other words, do what works, realizing that 99 percent of the time that you're doing indivdual sites, and ignore dogma? Hmm, what a concept! hmm I didn't grok that comment. Other than basic inheritance and the namespace features provided by classes, I don't see much else that is critically useful. There's was a strange push for all kinds of advanced OO features in PHP5 and somehow that got some kind of ball rolling to make things more and more complicated. Other than the pass objects by reference by default feature of PHP5 and better constructor/destructor support... the rest is just tooth decaying candy... and Jochem seems to be getting cavities it seems -- time to floss and brush the crud away ;) like you Rob I have a big OO codebase, only mine is php5 only and not in a state were I'm comfortable publishing it (one needs to know too much about the codebase concepts and firebird DB to make it relevant without documentation that I will probably never have time to write :-/) none the less is stable, robust, powerful and flexible - it cost me about 2 years of near fulltime development and I run a number of well paid projects on it - brushing it away is not an option at this stage in the life of the code, not that I consider it cruddy enough either. at every BC breaking turn in the php5 road (since beta3) I have managed to refactor my codebase without actually changing too much or having break the functionality the codebase offer[s|ed] - such refactoring does cost time though in terms of having to think carefully about how to proceed and the testing involved in making sure things still work as intended ... One of my biggest peeves about stuff changed that worked but wasn't necessarily purist... not letting values be passed to functions expecting a reference parameter. I mean really, PHP knows it's a literal, so why can't it just make it safe. Ugh. Nope, now we gotta add an extra line of userspace code to first assign the value to a variable to do exactly what PHP could so much faster do for us. Similarly functions returning references. Used to be you could return a null or false value on encountering a problem... but noo, now you have to spank youself and write $retValue = null; return $retValue. *pt*. now I understand the annoyance Rob refers to but I can live that that one because I have read enough to understand that there is a segfault issue and although in theory it should be the engine that just 'deals' with it it can't without a lot of developer headache and/or BC breakage and/or performance issues playing up - so its the lesser of 2 evils. besides I often end up doing something like (a few more chars but no extra lines ;-): return ($r = false); my gripe is about the abomination that is 'strictness for the sake of it' which is most evident in the OO code - and not only is it strictness per se but the continual movement of the goals posts (and incremental increase) regarding the rigidity of what is allowed (read 'what is correct') - it's not like some very strict OO stuff was introduced in the beginning, no, in the beginning [of php5] things were more relaxed and even now after 2 years php5 is still treated as a beta product with regard to the way functionality is changed according to the whim of whoever has commit rights (or there abouts). and I understand Johns sentiment about not using OO - but there are complex things you can structure and design (from my personal point of view) which cannot so easily/ transparently be done with purely procedural code. that said I have plenty of reusable function library and pure procedural sites running - I use both depending on suitability. generally I like thinking in OO terms - and it often matches with stuff I do in javascript on the client side in terms of working with objects (yes I know javascript is prototypal iso class-based but that is not the point :-) not that procedural code is completely safe from the purists that are out 'to protect the developer' - remember how flexible array_merge() used to be??? well try stuffing anything other than an array into it these days and you get a big fat E_WARNING. and I am pretty damn sure *that* had nothing to do with fixing a segfault. BTW, I still love PHP :) heh me too :-) Cheers, Rob. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
On Thu, 2006-06-01 at 17:43, Jochem Maas wrote: Robert Cummings wrote: On Thu, 2006-06-01 at 15:01, John Meyer wrote: John Nichel wrote: Do what I do, and don't do OO. ;) there an 'oo baby' joke in there somewhere :-) In other words, do what works, realizing that 99 percent of the time that you're doing indivdual sites, and ignore dogma? Hmm, what a concept! hmm I didn't grok that comment. Other than basic inheritance and the namespace features provided by classes, I don't see much else that is critically useful. There's was a strange push for all kinds of advanced OO features in PHP5 and somehow that got some kind of ball rolling to make things more and more complicated. Other than the pass objects by reference by default feature of PHP5 and better constructor/destructor support... the rest is just tooth decaying candy... and Jochem seems to be getting cavities it seems -- time to floss and brush the crud away ;) like you Rob I have a big OO codebase, only mine is php5 only and not in a state were I'm comfortable publishing it (one needs to know too much about the codebase concepts and firebird DB to make it relevant without documentation that I will probably never have time to write :-/) none the less is stable, robust, powerful and flexible - it cost me about 2 years of near fulltime development and I run a number of well paid projects on it - brushing it away is not an option at this stage in the life of the code, not that I consider it cruddy enough either. *hehehe* Sorry, the crud wasn't referring to your code, but rather to the extras that are causing you grief. There are critical aspects of any OO language that are absolutely necessary in OOD, but then there are also sugary parts that are just nice to have :) IMHO, it's wise to wait until new features completely stabilize before jumping on them. For instance my framework for all intents and purposes requires replacement services to adhere to a specific set of methods when overriding the default server object... in this way an interface is virtual, and never explicit. Some thing I find amusing in retrospect, is that when PHP4 came out I couldn't migrate to it fast enough, PHP3 just couldn't cut it in comparison to PHP4. But looking at PHP5 I feel (and I think others feel similarly) that I can easily wait till PHP6 comes out. Recently I've been rewarded with my patience... PHP5 now accepts the var statement again to declare class properties without generating a warning... if I had gone and updated my code to use public/private I'd have wasted my time :) at every BC breaking turn in the php5 road (since beta3) I have managed to refactor my codebase without actually changing too much or having break the functionality the codebase offer[s|ed] - such refactoring does cost time though in terms of having to think carefully about how to proceed and the testing involved in making sure things still work as intended ... One of my biggest peeves about stuff changed that worked but wasn't necessarily purist... not letting values be passed to functions expecting a reference parameter. I mean really, PHP knows it's a literal, so why can't it just make it safe. Ugh. Nope, now we gotta add an extra line of userspace code to first assign the value to a variable to do exactly what PHP could so much faster do for us. Similarly functions returning references. Used to be you could return a null or false value on encountering a problem... but noo, now you have to spank youself and write $retValue = null; return $retValue. *pt*. now I understand the annoyance Rob refers to but I can live that that one because I have read enough to understand that there is a segfault issue and although in theory it should be the engine that just 'deals' with it it can't without a lot of developer headache and/or BC breakage and/or performance issues playing up - so its the lesser of 2 evils. Well there was a segfault, but that's fixed now, now the warning is thrown because of some purist attitude that says it's incorrect to pass a literal to a reference expecting parameter... I can see how that's an issue in C with pointers, or in a strongly type language like Java, but part of PHP's popularity is that while it shares a lot of functions with C, it is neither C nor Java, but rather a much simpler system that generally for all the novices out there works well. besides I often end up doing something like (a few more chars but no extra lines ;-): return ($r = false); my gripe is about the abomination that is 'strictness for the sake of it' which is most evident in the OO code - and not only is it strictness per se but the continual movement of the goals posts (and incremental increase) regarding the rigidity of what is allowed (read 'what is correct') - it's not like some very strict OO stuff was introduced in the beginning, no, in the beginning [of php5]
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Robert Cummings wrote: On Thu, 2006-06-01 at 17:43, Jochem Maas wrote: ... Other than basic inheritance and the namespace features provided by classes, I don't see much else that is critically useful. There's was a strange push for all kinds of advanced OO features in PHP5 and somehow that got some kind of ball rolling to make things more and more complicated. Other than the pass objects by reference by default feature of PHP5 and better constructor/destructor support... the rest is just tooth decaying candy... and Jochem seems to be getting cavities it seems -- time to floss and brush the crud away ;) like you Rob I have a big OO codebase, only mine is php5 only and not in a state were I'm comfortable publishing it (one needs to know too much about the codebase concepts and firebird DB to make it relevant without documentation that I will probably never have time to write :-/) none the less is stable, robust, powerful and flexible - it cost me about 2 years of near fulltime development and I run a number of well paid projects on it - brushing it away is not an option at this stage in the life of the code, not that I consider it cruddy enough either. *hehehe* Sorry, the crud wasn't referring to your code, but rather to I did get that (well I assumed assumed thats what you meant - I took the opportunity to highlight the practicalities of being stuck in a situation due to commercial constraints for those who might be interested in learning from my 'mistakes'.) ... now I understand the annoyance Rob refers to but I can live that that one because I have read enough to understand that there is a segfault issue and although in theory it should be the engine that just 'deals' with it it can't without a lot of developer headache and/or BC breakage and/or performance issues playing up - so its the lesser of 2 evils. Well there was a segfault, but that's fixed now, now the warning is thrown because of some purist attitude that says it's incorrect to pass a literal to a reference expecting parameter... I can see how that's an issue in C with pointers, or in a strongly type language like Java, but part of PHP's popularity is that while it shares a lot of functions with C, it is neither C nor Java, but rather a much simpler system that generally for all the novices out there works well. ah IC - although I do recall Rasmus talking about performance issues if this problem would have been solved the right way - I may be mistaken - either way the purists one that battle. ... (yes I know javascript is prototypal iso class-based but that is not the point :-) Ahh yes, I do like the elegance of prototypes too. They're a different kind of beast, but a very flexible one. the more I get in it the pretty it gets - javascript doesn't just give you a revolver to shoot yourself with it gives you a Doom3 chainsaw and it's shiny :-) not that procedural code is completely safe from the purists that are out 'to protect the developer' - remember how flexible array_merge() used to be??? well try stuffing anything other than an array into it these days and you get a big fat E_WARNING. and I am pretty damn sure *that* had nothing to do with fixing a segfault. *hehehe* Yeah. Cheers, Rob. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
On Thu, 2006-06-01 at 19:14, Jochem Maas wrote: Robert Cummings wrote: Ahh yes, I do like the elegance of prototypes too. They're a different kind of beast, but a very flexible one. the more I get in it the pretty it gets - javascript doesn't just give you a revolver to shoot yourself with it gives you a Doom3 chainsaw and it's shiny :-) Oh yeah... *rubs the gash in his foot*. I do firmly believe though, that if you have an iota of intelligence, then shooting yourself in the foot will lead to a strong lesson learned :) Protecting idiots from themselves just creates a problem of lots of idiots needing protection from themselves -- that should be a human resources issue, not a language issue IMHO :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Robert Cummings wrote:
Well there was a segfault, but that's fixed now, now the warning is
thrown because of some purist attitude that says it's incorrect to pass
a literal to a reference expecting parameter... I can see how that's an
issue in C with pointers, or in a strongly type language like Java, but
part of PHP's popularity is that while it shares a lot of functions with
C, it is neither C nor Java, but rather a much simpler system that
generally for all the novices out there works well.
Stuff like this is a bug in your code. It has nothing to do with purism:
function inc_arg($arg) {
$arg++;
}
inc_arg(3);
You have specifically defined your function to modify the argument yet
you pass it something that has no storage and thus there is no way to
use that modification. For the most part I agree that we need to keep
the language as flexible and forgiving as possible, but where we are
able to detect code that obviously doesn't do what the programmer
intended, it is tremendously helpful to get a descriptive error.
As far as functions returning references, you are right that returning a
literal there sometimes makes sense, but this can also hide a bug which
is why this only throws a notice.
You could argue that we could try to look ahead and see what is actually
done with the passed argument to see if it is modified, or that we could
try to figure out whether the returned reference is actually used as
such, but that is technically extremely difficult given the way things
work internally. So given the choice between ignoring extremely
suspicious code like this and throwing an error/warning, I'd rather be
told about it and in the edge cases where I really do want the
equivalent of a NOP in my code, it isn't that hard to force it by adding
a dummy storage variable along with a comment explaining why you need to
do that.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] OO purism sucks - this is a rant for anyone who is allergic to that kind of thing...
Robert Cummings wrote: On Thu, 2006-06-01 at 19:14, Jochem Maas wrote: Robert Cummings wrote: Ahh yes, I do like the elegance of prototypes too. They're a different kind of beast, but a very flexible one. the more I get in it the pretty it gets - javascript doesn't just give you a revolver to shoot yourself with it gives you a Doom3 chainsaw and it's shiny :-) Oh yeah... *rubs the gash in his foot*. I do firmly believe though, that if you have an iota of intelligence, then shooting yourself in the foot will lead to a strong lesson learned :) Protecting idiots from themselves just creates a problem of lots of idiots needing protection from themselves -- that should be a human resources issue, not a language issue IMHO :) Cheers, Rob. What was that joke that I heard. While regular programming gives you enough rope to hang yourself, OO lets you design the tree object. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
