Ferdinand Beyer wrote: > On 18 Feb 2004 at 11:02, Brad Fisher wrote: > > > For one because PHP doesn't allow method overloading. If I have > a method > > A::foo($a), and I want to change the prototype in B to B::foo($x, > $y), then
...snip... > > (like C::A_foo) which then calls A::foo internally? I'd hate to have > to add > > such wrappers in all cases, though I suppose it could work as well. > > Sounds very weird to me. When C overrides a method, the new one > should essentially do the same as the old one. > > In order to emulate method overloading, I think overriding is the > wrong way. What about using a variable amount of arguments: Sure... like I said my previous message, I can live without it in most cases. > > That is potentially true, but if I intentionally coded the objects to > ensure > > compaitibility, then where's the problem? As mentioned above, it > helps with > > getting around the missing method overloading. In my opinion, a > programming > > language should enable the programmer to solve problems in > ways that make > > sense for the situation. One of the great strengths of PHP is that it > allows > > a lot of flexiblity. While it's true that such flexibility can be abused, > it > > can also be put to uses the original designers never anticipated. > > Nevertheless even PHP should have some fundamental rules... > Programmers should try to avoid "dirty" hacks and work arounds > whereever possible. So one should never use "dirty" hacks even though it appears to be the only way to solve a problem? Where would we be if people never did that? Anyway, that's what my original question was about: How can I do what I want without having to resort to dirty hacks? I agree that there should be some limits, but I don't think you should add artificial ones just because you can never imagine a valid reason to do it another way. On the other hand, I also realise one can't have it all ways at once. I have a work-around that works, at the expense of performance. I'd prefer not to have the performance loss, but at least I can live with what I have. I'm not interested in Holy wars... we have too many of those already. I just thought I'd point out a potential drawback to the new restrictions on assigning to $this. > Well, I must confess that I do not know Perl (perhaps I'm to young). > But I said "not available in any OO language" - neither Perl nor PHP > are OO languages in my opinion (like Java, C++) so we should not > use Perl as a role model here :-) I never advocated that. It was just an example. I'm sure I could find others as well. > This is not even a "feature". I think it was a bug which some guys > used for dirty hacks and work arounds (Often the difference between > a bug and a feature is very small). Fortunately this bug has been > fixed in PHP5. Well, it did work in PHP4, and not in PHP5, which makes it a BC issue. Granted in most cases no one will ever know, but when you have code which depends on that bug/feature, then it makes a big difference when it is "fixed". Not that I don't agree with the spirit of fixing it, it's just that if you remove that way of calling methods from ancestor classes, then what other way is there? I'd prefer to have official language support for that. If some people don't like it, they don't have to use it. I don't need to be able to assign to $this if I can call the method I want to call when I want to call it. I know it's there, I know it'll work with my object, I even inherit from the class which implements it, and I know it used to be possible. > -- > Ferdinand Beyer > <[EMAIL PROTECTED]> -Brad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
