Re: wacky object idea

Zeev Suraski wrote: > <warning> > This post contains explicit material. Don't display to children under 3 > years of age. > </warning> > > At 02:09 30/08/2000, Francis Smit wrote: > >What is the WTF factor?? > > "What The Fuck" factor. As in, how likely is the end user to stare at his > screen and say in a pissed off tone 'What the fuck is going on?!' when he > bumps into this particular feature. > > >only if misused and who picks up libraries that abuse the language? > > What we're saying is basically that overloaded operators are > 'seductive'. They encourage you to misuse them. I would have to disagree, > > > >yes but this is an abuse I have never seen this sort of thing in C++ > >if one codes like that most people will choose not to know you, I > >sure would since there is no clear relationship between division > >and string splitting. > > Often, logical functions seem to map into operators. However, different > people map them onto different operators, if at all. In this case, once > explained, it makes perfect sense that dividing the string to substrings > based on a certain delimiter would use the division operator, and that's > what the developer thought to himself when he programmed this class. As > you saw, it's not necessarily trivial to figure it out, though. > > >Negative if one only uses sane overloads, (or as in the case of inserters > >"<<" ones which are well know alternate meanings), then no clarity is > >lost. The development of new alternate meanings is of course a little > >ticklish but, there are some sane rules that can be derived the above > >example is fairly unlikely to take of as it involves not only the overloading > >of the operator / as an operator but the conceptual over loading of a well > >known mathematical operator, the operator << how ever is much simpler, > >"<<" is not exactly an every day symbol as it is, so that the conceptual > >overloading of it as both a shift and a insert operator, is much easier to > >swallow, in mathematics (my first love) almost any symbol can be > >conceptually overloaded, if PHP is going to be a sissy on these issues > >then I can only say it's a pity, PHP shows much promise but I can always > >look for something with a more practical and realistic out look, or create > >it myself, that's the beauty of living in a free open source universe. > > PHP isn't a math language (we need a template for 'PHP isn't a <YOUR > FAVOURITE LANGUAGE TYPE HERE> language'). The limited positive power of > operator overloading won't show in PHP, and there's much more to lose than > to gain (people *WILL* misuse it, more often than using it properly, as > there are very limited good usages for it, and people very often use 'cool' > features, whether they need them or not). Well I guess there's no changing your mind, my commitment to PHP is thus much lessened, > > In my opinion, the ability to fork isn't one of the nicer things about open > source, it's actually one of the worst things about it. But obviously, by > definition, everyone can decide for themselves. > and thats why it's beautiful no one can force me or you to go there way of course this has some draw backs but thats life. > > In my opinion, I think that now that PHP is a well-established language, we > need to move off the state-of-mind that looks for more and more features to > add to the language level. When was the last time something was added to > the language level of Perl? Or even of C++ for that matter? It's time to > try and stop making revolutionary changes in every miniversion. PHP got to > where it is because people like it, we arrived at something that works and > that's good. Changing it all the time risks losing that. I haven't been arguing for the add hock addition of new features when ever, it takes someones fancy, I just hate libraries that do oscence and ugly things, just because the language doesn't let them do things in a natural way, but there it is I don't agree with you and you don't agree with me, and arguing will probably change nothing. Bye for now any way. -- Francis Smit Knowledge By Design/OzTel Suite 201, 683 George st Sydney 2000 NSW http://www.kbd.com.au mailto:francis@kbd.com.au Tel: +61 2 9212 1399 Fax: +61 2 9212 5727 ___________________________________ m$: How can we stuff you up today?