On Sun, Aug 18, 2002 at 09:26:45PM +0300, Zeev Suraski wrote:
> At 21:15 18/08/2002, Thies C. Arntzen wrote:
> >On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote:
> >> At 20:54 18/08/2002, Thies C. Arntzen wrote:
> >> > BTW: the code we're talking about is neither magic nor very
> >> > complex. andi, sorry i you felt me stepping on your feet;-)
> >>
> >> And yet you took it from ZE2 a couple of months after it was written, as
> >> opposed to two years ago when ZE1 was already out? Come on, Thies,
> >> sometimes knowing which algorithm to use and where to put the two lines
> >of
> >> code is the complexity, as it is in this case.
> >
> > i am working on a zend-extension that needs to know the real
> > current backtrace. you wrote the ze-extension interface, and
> > you should know that it's *very*, *very* hard to find the
> > real callstack from within an extension (all extensions i'm
> > aware of have do it wrong).
>
> It may sound like a product pitch but it really isn't - did you take a look
> at the way the Zend Studio displays stack traces? AFAIK, it's absolutely
> accurate, and it doesn't do any magic. I'm not aware of any problems
> getting the stack trace right with the extension interface. I can even
> help you with that.
look at the opcodes for:
a(b(c()));
function a() {}
function b() {}
function c() {}
and tell me which function is called from which scope. unless
you know something i dont youll see
a()
b()
c()
which is wrong as the correct call-order is
c()
b()
a()
>
> > after fiddling with it for a while i looked at the stuff andi
> > did and found that it can be apllied mostly (there _is_ one
> > difference) to ZE1, what's wrong with that? do i want credits
> > for it? NO. do i think this feature will help me and others?
> > YES.
>
> I didn't think you wanted credit for it, that's obviously not the
> issue. The two issues I did mention, coupled with the fact that Andi is
> the one who wrote the code in the first place, are the issue, IMHO.
>
> > you told me that you didn't even look into the patch. so -no-
> > you have no technical reason except if you think i'm stupid.
>
> Uhm no. Touching a delicate portion of execute() is dangerous no matter
> what. If it's for adding a new feature, then in my humble opinion, it is
> not worth it at this point.
we have soo many ppls currently working again on -HEAD and
we'll have a full QA cycle before 4.3. i don't think this
feature will cost us anything that can't be paid for with a
single dime.
>
> > "your" political reason has no standing in my opinion.
>
> To each his own.
>
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ you can do that in
> > closed-source, commercial software. trying to do that in
> > opensource will drive people away from you...
>
> As it did with PHP 4? Commercial software and opensource software have
> lots of things in common, and encouraging people to migrate to the newest
> version is one of those things. If you don't, you get into a support
> nightmare. It's as simple as that.
>
> >
> >> it. I did that in lots of features in PHP 4, and frankly, I think it's
> >> very lucky that I did, as the transition from PHP 3 to 4 was VERY
> >> successful. Imagine if we still had to fix PHP 3 bugs on a daily basis.
> >
> > i do remember countless hours that i put into the transition
> > from PHP 3 to PHP 4 during that time i became a member of the
> > "PHP Group" - but what has that to do with debug_backtrace()?
>
> Nothing specific, it has to do with new features. I added lots of new
> features that could be backported to PHP 3, when PHP 3 was a hell of a lot
> more popular than 4, when 4 was really just a beta. Forget my code. The
> session module could be ported back to PHP 3 with almost no changes, why
> wasn't it done? And you know, session functionality is something useful to
> literally everyone, and is much more important than a backtrace.
you're comparing bytes and apples here. PHP4 and PHP3 were
sooo different. and i recall that you have backported the new
memory zend memory-manager to php3, didn't you?
>
> If you want it so much and need it so much and are so furious about it,
> then whatever, backport it. Let it be noted that I firmly object, and that
> Andi objected as well (not sure how firmly :) Let it be also noted that I
> will firmly object to further backports of new features in the future.
i think this might be the only feature that justifies
backporting as:
a) the backport is minimal (and already done)
b) the feature is very useful for anyone that develops with
php (which is our primary audience)
tc
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
