Anyone know any PHP Developers who are looking for employment
-Original Message-
From: Andrés Robinet [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 2:53 PM
To: 'Robert Cummings'; 'Zoltán Németh'
Cc: 'Greg Donald'; php-general@lists.php.net
Subject: RE: [PHP] What's wrong the __autoload()?
> -Original Message-
> From: Robert Cummings [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 12, 2008 1:51 PM
> To: Zoltán Németh
> Cc: Greg Donald; php-general@lists.php.net
> Subject: Re: [PHP] What's wrong the __autoload()?
>
>
> On Wed, 2008-03-12 at 18:21 +0100, Zoltán Németh wrote:
> > 2008. 03. 12, szerda keltezéssel 12.12-kor Greg Donald ezt írta:
> > > On 3/12/08, Zoltán Németh <[EMAIL PROTECTED]> wrote:
> > > > but I strongly think that Ruby as a
> > > > language just plain sucks ;)
> > >
> > > And exactly how many projects do you have under your belt to allow you
> > > to develop this opinion? What's the url to any one of them?
> > >
> > > Unlike you I actually have thousands of lines of Ruby code under my
> > > belt that allows me to properly develop an opinion of Ruby and Rails
> > > and how they both compare to every other programming language and
> > > framework I know and have developed in. Need a URL?
> >
> > ok, I admit I don't have experience with Ruby but I have experience with
> > php. and I don't have experience with Ruby because I read some manuals
> > and example codes and whatnot and I just could not get to like it at
> > all. it's just so strange and different from anything I know (php, c,
> > java) - and I could not find out any good reasons for most of the
> > differences... e.g. how come function definitions are between 'def' and
> > 'end'?
>
> Because they didn't follow convention... *HAHAHA* oh my, I think I just
> pee'd myself.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
>
I think __autoload would make much more sense if it worked like an event
registration feature. Such as:
function myAutoloadCallback($className) {
if ($className == 'ShakeItBaby') {
require_once 'ShakeItBaby.class.php';
return true;
}
return false;
}
.
__autoloadRegisterCallback('myAutoloadCallback');
.
$shaker = new ShakeItBaby();
This way, multiple frameworks and project requirements for autoload wouldn't
clash. If one of the autoload callbacks returns "true" that would be it.
Otherwise the next autoload callback would be called, and so on.
The problem with the current implementation is that if you get some piece of
code that uses __autoload and you are using __autoload too, you'll have to
either patch that piece of code (if the "piece of code" is a framework, things
will get much more complicated when updating to the next version) or patch your
own code, or just make a promise not to use __autoload (my current choice...
just in case) or not to use "pieces of code that use __autoload". Bottom line,
I hate it.
Something similar applies to the set_error_handling function, anyone can
overwrite your error handling and you can overwrite the error handling of
anyone. I hate it also, so I rather check the return value of functions, and/or
use exceptions for custom error handling.
I don't see why autoload and error handling can't be implemented in a
stack-like way, returning false from the callback moves to the next error
handler / autoloader, returning true ends the "handler search" process...
though this is more of a question to be made to the interlals list (b...
can't face their karma yet).
Anyway... the more PHP approaches OOP and gets OOP features, the more it can be
done through design patterns such as the Registry/Singleton/etc... and the more
Exceptions are used for PECL extensions, and this seems the trend for the
future of PHP.
Regards,
Rob(inet)
Andrés Robinet | Lead Developer | BESTPLACE CORPORATION
5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308 |
TEL 954-607-4296 | FAX 954-337-2695 |
Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace |
Web: bestplace.biz | Web: seo-diy.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
