Comment on PHP::Debug

Craig Constantine (http://pear.php
.net/user/cconstantine) has commented on the proposal
for PHP:ebug.

Comment:

we use something similar which also allows us to put all the
debug/trace
output into a file. when we init the tracing objects we tell
them where to
write. So we can have tracing files per logged in user, per
remote IP or
whatever we like. When systems go to production we can leave
this enabled
for a few months having it log to dated directories and
such. If any bugs
or problems appear in the live product, we can go look at
the debug/trace
info for the afflicted customer session. Very very useful
for forensic
analysis.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=260


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Loïc Vernet (http://pear.php.net/use
r/c0il) has commented on the proposal for PHP:ebug.

Comment:

The 2 existings renderers are mainly to debug "on the
fly", but i agree a
log feature with a new renderer would be usefull too.
Moreover i have
several users that already asked me for it in the past. For
sure, it will
be the next thing i'll do for this package.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=260


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Christian Weiske (http://pear.php.net/
user/cweiske) has commented on the proposal for PHP:ebug.

Comment:

Nice idea. Here are a few comments:
- __toString needs an uppercase S
- Please put every class in an own file, e.g.
PHP_Debug_Line
- Only use private if really needed. Protected
methods/variables can be
used from inheriting classes.
- Do not use global constants but class constants. This
avoids cluttering
global namespace
- "class PHP_Debug_Renderer_HTML_Div_Config" is in
the wrong file. PEAR CS
tell you that underscores need to be replaced with slashes,
while you put
it into PHP/Debug/Renderer/HTML_Div_Config.php
- If you use visiblity modifiers (public, protected,
private), use them
everywhere
- "since  30 march 2007" normally tells you which
version, not which date

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=260


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 12 Apr 2007 10:24:45 -0000, Christian Weiske
<cweiskephp.net> wrote:
> - Only use private if really needed. Protected
methods/variables can be
> used from inheriting classes.

I have read this so many times now. Was there any discussion
on that
or some decision? What you are stating can be a reason
against
protected methods/variables too. So, why is everyone
advocating
protected?

Regards,
Stefan

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Stefan,

>> - Only use private if really needed. Protected
methods/variables can be
>> used from inheriting classes.
> 
> I have read this so many times now. Was there any
discussion on that
> or some decision? What you are stating can be a reason
against
> protected methods/variables too. So, why is everyone
advocating
> protected?

First: Visibility operators have their use and should be
used whenever
possible. They make clear which methods are meant for users
to use, and
which ones are purely an implementation detail and not meant
for public
service.

So to come to your question:
If you make all your class variables and methods (that shall
not be used
from outside) private, you basically disallow any classes
that extend
your own class to make use of the inner workings of your
class.
Since classes extending another class often only fix some
details or add
functionality, it is very unwise to not let them use the
workhorses of
your class. Thus, functionality that already exists in the
original
class cannot be used in the extending class and needs to be
re-implemented, just because the author did not have in mind
that his
class may be extended.

So general advise is the following:
- If the class method/variable is to be used from outside,
make it public
- If it is to be used from inside the class only, make it
protected
- If the method is mission critical and/or will stop working
when only
the slightest detail is changed, or it is very very very
clear that the
functionality can be /only/ implemented this way (and/or
another way
would be dangerous), make it private.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

Christian Weiske wrote:

> So general advise is the following:
> - If the class method/variable is to be used from
outside, make it public
> - If it is to be used from inside the class only, make
it protected
> - If the method is mission critical and/or will stop
working when only
> the slightest detail is changed, or it is very very
very clear that the
> functionality can be /only/ implemented this way
(and/or another way
> would be dangerous), make it private.

I think Stefan's question was more what should you do as
"default" for 
things where you have not had time to think through the
implications? 
Basically with "protected" you are being
"friendly" to extending, but it 
also means that you now have committed to a certain API.
Since we do not 
allow BC breaks in the same major version number, the
default should 
probably be "private", although authors are very
much encouraged to work 
on making as much "protected" as possible (and
certainly anything that 
is necessary).

I think the real problem is to ensure that everybody ensures
the 
implications of the choice.

regards,
Lukas

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Lukas,

> Basically with "protected" you are being
"friendly" to extending, but it
> also means that you now have committed to a certain
API. Since we do not
> allow BC breaks in the same major version number, the
default should
> probably be "private", although authors are
very much encouraged to work
> on making as much "protected" as possible
(and certainly anything that
> is necessary).

Is api stability for "external" users that just
use the class, or is it
also meant for the inner workings -> protected methods?

If the first, then we'd need two api stability levels.

But: Maybe I cannot make a method private since I use it in
my package
in an extending class. What then? If I re-release the
package, I will
make sure that all classes work together, after changes in
inner
workings or re-organization. But I cannot gurantee this for
other
projects that extend my class. The public api is still
stable, but
extending classes will break.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

Loïc Vernet (http://pear.php.net/use
r/c0il) has commented on the proposal for PHP:ebug.

Comment:

- __toString methods updated with an uppercase S
- PHP_DebugLine class has now its own file (as all classes
now)
- reviewed visiblity modifiers for all methods and
attributes
- all global constants switched to class constants
- corrected class naming and directory structure for
renderers
- corrected since doctags
- corrected globally file naming
- package, links & demo updated

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=260


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Loïc Vernet (http://pear.php.net/use
r/c0il) has edited the proposal for PHP:ebug.

Change comment:

- __toString methods updated with an uppercase S
- PHP_DebugLine class has now its own file (as all classes
now)
- reviewed visiblity modifiers for all methods and
attributes
- all global constants switched to class constants
- corrected class naming and directory structure for
renderers
- corrected since doctags
- corrected globally file naming
- package, links and demo updated

Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=260


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Till Klampaeckel (http://pear.php.net/u
ser/lagged) has commented on the proposal for PHP:ebug.

Comment:

I am not sure how applicable this is here, but since there
are
extensions like DBG and xcache and others, would you be able
to make
use of those "backends" if they are
running/installed/available?

So for example, DBG has a profiler, maybe it would be a good
addition
to make your class use DBG's profiling if available.

So I guess I am proposing a general driver-architecture for
your
package. Not sure if I am asking too much! 

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=260


-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php