Hello all,

I'm wondering what's wrong with the use of __autoload(), since I see that
projects like the Zend Framework don't use it and prefer to require_once
each required file.

Thanks in advance.
--
Gustavo Narea.
http://gustavonarea.net/

Get GNU/Linux! http://www.getgnulinux.org/

> I'm wondering what's wrong with the use of __autoload(), since I see that
> projects like the Zend Framework don't use it and prefer to require_once
> each required file.

Things that happen without you explicitly causing them (ie require() et
al) can lead to confusion.

For example a junior developer who doesn't know of its existence and is
new to a job is less likely to admit ignorance and ask how a class is
being defined when __autoload() is being used.

--
Richard Heyes
Employ me:
http://www.phpguru.org/cv

On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
> > I'm wondering what's wrong with the use of __autoload(), since I see that
> > projects like the Zend Framework don't use it and prefer to require_once
> > each required file.
>
> Things that happen without you explicitly causing them (ie require() et
> al) can lead to confusion.

It's called "convention over configuration" and that's exactly where
good frameworks should be headed.

http://en.wikipedia.org/wiki/Convent..._Configuration

> For example a junior developer who doesn't know of its existence and is
> new to a job is less likely to admit ignorance and ask how a class is
> being defined when __autoload() is being used.

That's a the dumbest reason I've ever heard to not use a given language feature.


--
Greg Donald
http://destiney.com/

On Wed, 2008-03-12 at 10:33 -0500, Greg Donald wrote:
> On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
> > > I'm wondering what's wrong with the use of __autoload(), since I see that
> > > projects like the Zend Framework don't use it and prefer to require_once
> > > each required file.
> >
> > Things that happen without you explicitly causing them (ie require() et
> > al) can lead to confusion.
>
> It's called "convention over configuration" and that's exactly where
> good frameworks should be headed.

But then you'd end up with something like Ruby on Rails... and we all
know about Ruby on Rails *VOMIT*.

Who wants to be stuck on a track when they can soar with the eagles.

> http://en.wikipedia.org/wiki/Convent..._Configuration

Interesting how the article promotes the ideas of both convention and
configuration co-existing so that one doesn't lose versatility. Thus,
one could infer that any good framework would allow both paradigms.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

On 3/12/08, Robert Cummings <robert@interjinn.com> wrote:
> But then you'd end up with something like Ruby on Rails... and we all
> know about Ruby on Rails *VOMIT*.

You clearly don't know much about it or else you wouldn't be bashing
it. Period. Just admit the fact that you're resistant to learn new,
better ways of doing things and move on.

On the other hand, if there's something in Rails you genuinely don't
understand, I'll be happy to assist you with that particular
understanding, off-list or wherever, free of charge.

> Who wants to be stuck on a track when they can soar with the eagles.

I dunno, why not ask the many Rails clone authors? I certainly don't
see any Ruby programmers trying to copy ZF or Symphony.

> > http://en.wikipedia.org/wiki/Convent..._Configuration
>
> Interesting how the article promotes the ideas of both convention and
> configuration co-existing so that one doesn't lose versatility. Thus,
> one could infer that any good framework would allow both paradigms.

Rails supports both naturally. It has configurable environments for
development, testing, and production, all pre-configured for the most
common cases. You can even create your own new environments if you
have something that doesn't fit into dev/test/prod very easily.
Complete versatility in every regard thanks to Ruby's meta-ness.


--
Greg Donald
http://destiney.com/

>> For example a junior developer who doesn't know of its existence and is
>> new to a job is less likely to admit ignorance and ask how a class is
>> being defined when __autoload() is being used.
>
> That's a the dumbest reason I've ever heard to not use a given language feature.

It's a perfectly viable business reason.

--
Richard Heyes
Employ me:
http://www.phpguru.org/cv

On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
> It's a perfectly viable business reason.

No it's not. I guess you need a "business" scenario to wrap your head
around the idiocy.

Here you go:

Imagine at Blizzard one morning, "Hey guys, we're not going to be able
to use function pointers on the new Diablo III like we had planned to
do, the new hires down the hall don't understand them very well so
just don't use them, OK?"


--
Greg Donald
http://destiney.com/

On Wed, Mar 12, 2008 at 10:05 AM, Gustavo Narea <me@gustavonarea.net> wrote:
> Hello all,
>
> I'm wondering what's wrong with the use of __autoload(), since I see that
> projects like the Zend Framework don't use it and prefer to require_once
> each required file.
>
> Thanks in advance.
> --
> Gustavo Narea.
> http://gustavonarea.net/
>
> Get GNU/Linux! http://www.getgnulinux.org/
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Use spl autoload register instead. This way your app and dependent
libraries can have their own autoloaders.

http://us2.php.net/manual/en/functio...d-register.php

>> It's a perfectly viable business reason.
>
> No it's not. I guess you need a "business" scenario to wrap your head
> around the idiocy.
>
> Here you go:
>
> Imagine at Blizzard one morning, "Hey guys, we're not going to be able
> to use function pointers on the new Diablo III like we had planned to
> do, the new hires down the hall don't understand them very well so
> just don't use them, OK?"

That's not quite the situation. Finding good developers isn't easy, so
lots of companies will go for "acceptable" ones, who are less likely to
know of __autoloads existence. Hence, using __autoload is unwise.

--
Richard Heyes
Employ me:
http://www.phpguru.org/cv

On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
> That's not quite the situation. Finding good developers isn't easy, so
> lots of companies will go for "acceptable" ones, who are less likely to
> know of __autoloads existence. Hence, using __autoload is unwise.

A lesser developer should be paid less and should be expected to
produce less but he should not in any way be allowed to refrain from
learning.

How long does it take to understand __autoload() anyway? 5-10
minutes? 15 or 20 if you play with an example for a bit? You're
gonna restrict the entire development team from using a given feature
just because you don't want to invest 20 minutes in getting your
newbie developer up to spead? That's pure idiocy.


--
Greg Donald
http://destiney.com/

2008. 03. 12, szerda keltezéssel 11.12-kor Greg Donald ezt Ãrta:
> On 3/12/08, Robert Cummings <robert@interjinn.com> wrote:
> > But then you'd end up with something like Ruby on Rails... and we all
> > know about Ruby on Rails *VOMIT*.
>
> You clearly don't know much about it or else you wouldn't be bashing
> it. Period. Just admit the fact that you're resistant to learn new,
> better ways of doing things and move on.

hey, we had a conversation about this a while back, and I'm still not
convinced about RoR being 'better'. it has several cool ideas, which
some php frameworks also follow now (and a few that would be cool in php
frameworks but not yet implemented), but I strongly think that Ruby as a
language just plain sucks

greets,
Zoltán Németh

>
> On the other hand, if there's something in Rails you genuinely don't
> understand, I'll be happy to assist you with that particular
> understanding, off-list or wherever, free of charge.
>
> > Who wants to be stuck on a track when they can soar with the eagles.
>
> I dunno, why not ask the many Rails clone authors? I certainly don't
> see any Ruby programmers trying to copy ZF or Symphony.
>
> > > http://en.wikipedia.org/wiki/Convent..._Configuration
> >
> > Interesting how the article promotes the ideas of both convention and
> > configuration co-existing so that one doesn't lose versatility. Thus,
> > one could infer that any good framework would allow both paradigms.
>
> Rails supports both naturally. It has configurable environments for
> development, testing, and production, all pre-configured for the most
> common cases. You can even create your own new environments if you
> have something that doesn't fit into dev/test/prod very easily.
> Complete versatility in every regard thanks to Ruby's meta-ness.
>
>
> --
> Greg Donald
> http://destiney.com/
>

Greg Donald wrote:
> On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
>> That's not quite the situation. Finding good developers isn't easy, so
>> lots of companies will go for "acceptable" ones, who are less likely to
>> know of __autoloads existence. Hence, using __autoload is unwise.
>
> A lesser developer should be paid less and should be expected to
> produce less but he should not in any way be allowed to refrain from
> learning.

I agree. But having worked in the (then) fast paced environment of
online DVD rental, time was not available.

> How long does it take to understand __autoload() anyway? 5-10
> minutes?

I would say as long as it takes to read the manual page, which isn't
that long at all.

> You're
> gonna restrict the entire development team from using a given feature
> just because you don't want to invest 20 minutes in getting your
> newbie developer up to spead? That's pure idiocy.

No it's not. It's not like require_once() is a hassle to type/use
anyhow. Things like editor macros and templates out enormously and
by using them over __auto load you (a business) could save yourself a
lot of time and hence money.

--
Richard Heyes
Employ me:
http://www.phpguru.org/cv

On 3/12/08, Zoltán Németh <znemeth@alterationx.hu> 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?


--
Greg Donald
http://destiney.com/

On Wed, 2008-03-12 at 11:12 -0500, Greg Donald wrote:
> On 3/12/08, Robert Cummings <robert@interjinn.com> wrote:
> > But then you'd end up with something like Ruby on Rails... and we all
> > know about Ruby on Rails *VOMIT*.
>
> You clearly don't know much about it or else you wouldn't be bashing
> it. Period.

Ummm, I've looked into Ruby and RoR. I've tried it out. I've read many
many many articles on it. I JUST DON'T LIKE IT.

> Just admit the fact that you're resistant to learn new,
> better ways of doing things and move on.

Ooooh... a personal attack... what a great way to make me reflect upon
my dislike of RoR. I think the only person around here qualified to
throw around "facts" about me is... you know... ME!

> On the other hand, if there's something in Rails you genuinely don't
> understand, I'll be happy to assist you with that particular
> understanding, off-list or wherever, free of charge.

Oh, there's nothing I don't understand about it. I just don't like it.
Can't a person just not like something anymore? Can't I have my own
opinion anymore? What year is this? 1984?? ... In an alternate universe
that was supposed to be averted?

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

On Wed, 2008-03-12 at 11:26 -0500, Greg Donald wrote:
> On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
> > It's a perfectly viable business reason.
>
> No it's not. I guess you need a "business" scenario to wrap your head
> around the idiocy.
>
> Here you go:
>
> Imagine at Blizzard one morning, "Hey guys, we're not going to be able
> to use function pointers on the new Diablo III like we had planned to
> do, the new hires down the hall don't understand them very well so
> just don't use them, OK?"

This is not a valid comparison. The above is the replacement of one
convention with another convention. It is not a case of circumventing a
convention to achieve a specific, and probably desired outcome.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

On 3/12/08, Richard Heyes <richardh@phpguru.org> wrote:
> No it's not. It's not like require_once() is a hassle to type/use
> anyhow. Things like editor macros and templates out enormously and
> by using them over __auto load you (a business) could save yourself a
> lot of time and hence money.

I'm not defending __autoload() specifically, I don't do much OO PHP
anyway so I couldn't possibly care less about it. My argument is that
asking other developers to not use specific language features simply
because lesser developers may not know them very well is just plain
dumb. I'm sorry you don't get it and I'm done trying to you get
it. Good luck codling your lesser developers. May they never learn
jack on their own.

*sigh*


--
Greg Donald
http://destiney.com/

On 3/12/08, Robert Cummings <robert@interjinn.com> wrote:
> > Imagine at Blizzard one morning, "Hey guys, we're not going to be able
> > to use function pointers on the new Diablo III like we had planned to
> > do, the new hires down the hall don't understand them very well so
> > just don't use them, OK?"
>
> This is not a valid comparison. The above is the replacement of one
> convention with another convention. It is not a case of circumventing a
> convention to achieve a specific, and probably desired outcome.

It's a dead-on, same example, just with a different programming
language and a different language feature.


--
Greg Donald
http://destiney.com/

2008. 03. 12, szerda keltezéssel 12.12-kor Greg Donald ezt Ãrta:
> On 3/12/08, Zoltán Németh <znemeth@alterationx.hu> 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'? I just don't like it and it's a matter of taste, so there is no
need to argue about it more...

however that's not about the framework, I admit that Rails had several
new and useful concepts, and I know that the framework I currently use
took a lot of ideas from there.

greets,
Zoltán Németh

>
>
> --
> Greg Donald
> http://destiney.com/
>

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 <znemeth@alterationx.hu> 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

On 3/12/08, Zoltán Németh <znemeth@alterationx.hu> wrote:
> 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.

That's a lot different from your previous blanket statement of "Ruby
as a language just plain sucks". I hate you less now that I know a
bit more about you, see how that works?

> it's just so strange and different from anything I know (php, c,
> java) -

Ruby has a lot of functional language influence. Once you use it you
really start to like how much shorter your iterative loops are for
example. The first two developers I worked with using Ruby also knew
ML and Scheme. One of them suggested I go study Scheme so I would
appreciate Ruby more. I did so for several weeks and now I do. Ruby
provides everything from the procedural world we're currently used to
seeing in PHP, C, and Java, but it also adds functional style that
makes for some utterly beautiful, compact code.

> and I could not find out any good reasons for most of the
> differences...

And you won't until you use it in practice more than once. But that's
true of most any language. I worked in Python by day for the better
part of last year and man was it fun seeing other ideas for how to do
things.

> e.g. how come function definitions are between 'def' and
> 'end'?

def is shorter than PHP's "function" qualifier? I give up. 'end' is
optionally replacable with '}', as is 'do' and '{' but you probably
didn't ever get to that page in the Ruby book you read.

> I just don't like it and it's a matter of taste,

In my experience "matter of taste" usually equates to "resistance to
learning", but call it what you will.

> so there is no
> need to argue about it more...

There's always reason to argue the features of a given language. For
example you may need to try and convince me at some point that Zombie
is a great language:

http://www.dangermouse.net/esoteric/zombie.html

Or not.

> however that's not about the framework, I admit that Rails had several
> new and useful concepts, and I know that the framework I currently use
> took a lot of ideas from there.

Those other frameworks can never be as powerful as Rails because they
aren't written in something as meta-capable as Ruby. Can you do this
in PHP?

class Foo
end

f = Foo.new

class Foo
Resource.find( :all ).each do |r|
res = r.name.downcase
define_method( "op_cost_#{ res }".to_sym ) do
self.properties.inject( 0 ){ |c,p| c + p.send( "op_cost_#{ res }" ) }
end
end
end

cost = f.op_cost_wheat

No you can't. PHP doesn't support adding methods to classes at
runtime, nor does it support adding methods to instantiated objects of
those classes at runtime. And that's just one example. These sort of
OO advantages exist throughout Ruby.

You don't love these features because you don't know they exist. You
don't know they exist because you haven't given the language more than
a few minutes of your time. Running through some silly little 5
minute Rails scaffolding tutorial will in no way teach you the real
power that exists in Ruby.


--
Greg Donald
http://destiney.com/

2008. 03. 12, szerda keltezéssel 13.27-kor Greg Donald ezt Ãrta:
> On 3/12/08, Zoltán Németh <znemeth@alterationx.hu> wrote:
> > 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.
>
> That's a lot different from your previous blanket statement of "Ruby
> as a language just plain sucks". I hate you less now that I know a
> bit more about you, see how that works?

didn't you notice the smiley at the end of that line? that was not a
serious plain statement but some mocking at you because you made a plain
statement about RoR being better.

>
> > it's just so strange and different from anything I know (php, c,
> > java) -
>
> Ruby has a lot of functional language influence. Once you use it you
> really start to like how much shorter your iterative loops are for
> example. The first two developers I worked with using Ruby also knew
> ML and Scheme. One of them suggested I go study Scheme so I would
> appreciate Ruby more. I did so for several weeks and now I do. Ruby
> provides everything from the procedural world we're currently used to
> seeing in PHP, C, and Java, but it also adds functional style that
> makes for some utterly beautiful, compact code.

'utterly beautiful' is again a matter of taste
of course, I admit that Ruby would provide me all the features I
currently use, it has to, otherwise noone would start using it instead
of their current language. and yes, I see from the examples that it is
shorter. but is shortness/compactness such a great advantage? I'm not at
all sure about that.

>
> > and I could not find out any good reasons for most of the
> > differences...
>
> And you won't until you use it in practice more than once. But that's
> true of most any language. I worked in Python by day for the better
> part of last year and man was it fun seeing other ideas for how to do
> things.

that might be true, but in the last year I've been working on the same
big project, and it seems I will be working on it for this year too, you
know, next versions and such, so at this moment I don't have serious
amount of time to experiment with anything. in fact, I'm also a bit
workaholic and also I'm attending some evening university so I hardly
have time to read a manual completely...

>
> > e.g. how come function definitions are between 'def' and
> > 'end'?
>
> def is shorter than PHP's "function" qualifier? I give up. 'end' is
> optionally replacable with '}', as is 'do' and '{' but you probably
> didn't ever get to that page in the Ruby book you read.

as I said above, I had/have not much time, so my reading might have been
sloppy... and is shortness that important?

>
> > I just don't like it and it's a matter of taste,
>
> In my experience "matter of taste" usually equates to "resistance to
> learning", but call it what you will.

well, there is difference between that. its like if you have a very
limited time frame you can spend on learning, you choose to learn more
of something you like already, no? sure, if I had more time, I would
experiment more with things I don't like or I don't know really.

>
> > so there is no
> > need to argue about it more...
>
> There's always reason to argue the features of a given language. For
> example you may need to try and convince me at some point that Zombie
> is a great language:
>
> http://www.dangermouse.net/esoteric/zombie.html
>
> Or not.



>
> > however that's not about the framework, I admit that Rails had several
> > new and useful concepts, and I know that the framework I currently use
> > took a lot of ideas from there.
>
> Those other frameworks can never be as powerful as Rails because they
> aren't written in something as meta-capable as Ruby. Can you do this
> in PHP?
>
> class Foo
> end
>
> f = Foo.new
>
> class Foo
> Resource.find( :all ).each do |r|
> res = r.name.downcase
> define_method( "op_cost_#{ res }".to_sym ) do
> self.properties.inject( 0 ){ |c,p| c + p.send( "op_cost_#{ res }" ) }
> end
> end
> end
>
> cost = f.op_cost_wheat
>
> No you can't. PHP doesn't support adding methods to classes at
> runtime, nor does it support adding methods to instantiated objects of
> those classes at runtime. And that's just one example. These sort of
> OO advantages exist throughout Ruby.
>
> You don't love these features because you don't know they exist. You
> don't know they exist because you haven't given the language more than
> a few minutes of your time. Running through some silly little 5
> minute Rails scaffolding tutorial will in no way teach you the real
> power that exists in Ruby.

hmm that feature looks interesting, however I can't really think of a
case where I would want to modify the class definition of an
instantiated object.... maybe later, when I'll have some more time I
give Ruby a second run, and we'll see what comes out of that.

greets,
Zoltán Németh

>
>
> --
> Greg Donald
> http://destiney.com/
>

> -----Original Message-----
> From: Robert Cummings [mailto:robert@interjinn.com]
> 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 <znemeth@alterationx.hu> 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 (brrrr... 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: info@bestplace.net | MSN Chat: best@bestplace.net | SKYPE: bestplace | Web: bestplace.biz | Web: seo-diy.com

On 3/12/08, Zoltán Németh <znemeth@alterationx.hu> wrote:
> I can't really think of a
> case where I would want to modify the class definition of an
> instantiated object....

You can't very well think to walk if you don't have legs.


--
Greg Donald
http://destiney.com/

On Wed, 2008-03-12 at 14:09 -0500, Greg Donald wrote:
> On 3/12/08, Zoltán Németh <znemeth@alterationx.hu> wrote:
> > I can't really think of a
> > case where I would want to modify the class definition of an
> > instantiated object....
>
> You can't very well think to walk if you don't have legs.

You make it sound like this stuff is new or something. Lisp and other
functional languages have had it for decades. Even JavaScript has it.
Your analogy is also way off... ask any person without legs if they
think about walking. These features of which you speak, someone thought
of them (walking) long before they were implemented into a language
(legs). But just because you think of walking and implement legs to do
so, doesn't mean you can't think of flying, swimming, teleporting, etc.
None of which require legs.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP