php-general Digest 25 Dec 2007 09:36:43 -0000 Issue 5199
php-general Digest 25 Dec 2007 09:36:43 - Issue 5199
Topics (messages 266258 through 266268):
Re: Opinion about the using $GLOBALS directly
266258 by: Sancar Saran
266259 by: Robert Cummings
Re: building PHP5.2.5 on Mac OS X Leopard (anyone know how to build a just an
extension)
266260 by: Jochem Maas
loadHTML()
266261 by: M5
266262 by: Casey
266263 by: Casey
266264 by: M5
Simple RegEx question
266265 by: M5
266266 by: Casey
266267 by: Casey
266268 by: Jochem Maas
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
--
---BeginMessage---
Hello Tedd,
Here my opinoins
First of all, I ask this question to is there any technical dead end for using
$GLOBALS directly.
It seems not.
And I believe other arguments was closely connected to coding style.
I'm self learner, I learn evrything about computers, programming (that means
PHP) and English by myself. Because of this time to time I found my self into
very alien position for others.
On Monday 24 December 2007 19:13:07 tedd wrote:
At 4:18 PM +0200 12/19/07, Sancar Saran wrote:
that said, avoid globals like the plague - sometimes you may come up
with
a situation where using a global is really necessary - such situations
should be the exception rather than the rule, often if your thinking of
using a global there is another way of doing it. jmho
And this is why I'm asking here, WHY I should avoid globals like plague ?
Every one says bad. Alright, but no one says WHY ?
Hi:
I'm a little late to this thread (been busy), but this is why I
rarely use globals and have not used them in php.
One of the fundamentals of programming I've learned is to reduce
problem/solution to their most basic form. Simply, you see a problem
and you solve it by dividing the problem it into smaller parts and
then writing code to solve the small parts. Eventually, all the small
solutions come together to solve the larger problem.
Absolutely. I learn this from very hard way. (rewriting the code :))
Certainly, and it seems even logical, that you can use a global
variable to communicate between the different parts and everything
should work -- IF -- that's all there was to it. But, if you have to
debug the code OR if you want to use a portion of that solution to
solve a different problem, then you can have difficulties. For
example:
[1] If you have to debug the code, there's not a really good way to
look at a function and see if a variable in it is a global or not --
therein lies a problem, you don't readily know.
In other languages I adopted a naming convention that used g as the
first letter of a Global variable, like gThisIsMyGolbalVariable --
that way at least I knew the variable was global. But, even then I
didn't know where the global was defined or where it might be changed
-- it was just an unknown in my function that I had to consider.
$GLOBALS['myVariable'] directly solves the problem.
[2] If you want to reused a portion of the code, then you have to
also accommodate the global. This makes transporting your code from
one application to another problematic because you never know IF your
function replies on a global or not. If you never use globals, then
that's never a problem.
If is there any possibility to use the function with some other variables I
use it to.
So, my advice is to not use globals, but rather make the functions
independent from globals. That way you troubleshoot them easier and
can cut/paste them into other solutions without having to worry if
some part of that function relies on something who knows where.
That's my reasons why I avoid globals.
Cheers,
tedd
--
---
http://sperling.com http://ancientstones.com http://earthstones.com
Here Some basic list for my $GLOBALS usage.
$GLOBALS['db'] = my Adodb object
$GLOBALS['mc'] = my Memcached object
$GLOBALS['l'] = my Language keys
$GLOBALS['d'] = my debug pool.
$GLOBALS['c'] = my config array.
And someting like that.
A very basic function for pooling debugs.
function addDebug($_sDebugVal) {
$GLOBALS['d']['_DMSG'][] = $_sDebugVal;
}
usage addDebug($MyVar); or addDebug(print_r($arrayFoo,true));
end of page
getDebug() {
return $GLOBALS['l']['_debug_messages_'].br/pre.implode(\n.
$GLOBALS['d']['_DMSG'])./pre;
}
Regards
Sancar
---End Message---
---BeginMessage---
On Mon, 2007-12-24 at 12:13 -0500, tedd wrote:
At 4:18 PM +0200 12/19/07, Sancar Saran wrote:
that said, avoid globals like the plague - sometimes you may come up with
a situation where using a global is really necessary - such situations
should be the exception rather than the rule, often if your thinking of
using a
php-general Digest 26 Dec 2007 05:04:19 -0000 Issue 5200
php-general Digest 26 Dec 2007 05:04:19 - Issue 5200
Topics (messages 266269 through 266270):
Re: loadHTML()
266269 by: Jochem Maas
Sayonara PHP
266270 by: Martin Alterisio
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
--
---BeginMessage---
M5 schreef:
OK, I already knew that making it valid doesn't change the result. But
the question remains, how to parse the HTML as it arrives (which I have
no control over anyway), besides doing a str_replace on br and
inserting a token, which I later replace (which I shouldn't have to,
right?)
for creating valid xHTMl you can run the input through tidy
(http://php.net/tidy)
does echo $table-saveHTML() show the BR tags?
also try:
?php
foreach($table-getElementsByTagName(div) as $div) {
var_dump($div-hasAttributes(), $div-hasChildNodes());
echo htmlentities($div-C14N()); // undocumented, found in manual, no
idea if it works
}
...Rene
On 24-Dec-07, at 7:19 PM, Casey wrote:
Actually, never mind. It does not have to be valid to work.
On Dec 24, 2007, at 6:15 PM, Casey [EMAIL PROTECTED] wrote:
That's because it's not proper XHTML: br should be br /.
On Dec 24, 2007, at 6:03 PM, M5 [EMAIL PROTECTED] wrote:
Just getting into DOMDocument()... I'm loading an HTML page and
trying to extract certain bits of text. Just one problem: loadHTML()
seems to ignore orphan tags like 'br'. For example, in the
following HTML:
div class=textSome text is here. br New line. br Another new
line. /div
div class=textSome text is here. br New line. br Another new
line. /div
div class=textSome text is here. br New line. br Another new
line. /div
If I run the above HTML through:
$nodes = $table-getElementsByTagName(*);
I only get three nodes that I can iterate through (div). What I
want to do is split/explode the three lines within each div, but
when I look at the nodeValue of each node, it only shows something
like Some text is here. New line. Another new line.
Any ideas?
...Rene
--
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
---End Message---
---BeginMessage---
Please let me do a little explanation of the title first. Japanese is an
interesting language where context is vital to the meaning of a word.
Sayonara usually means a simple good bye, but within a different context
can mean we'll probably never meet again.
To understand this mail you'll have to know that I was just another user of
PHP, an user that was probably too eager. I wanted to get more involved with
the development of PHP as I do believe in all the philosophy of open-source.
In the end I found my attempts ended in frustration, but, nevertheless, I
learned a lot in just a few months. I don't want this mail to be one where I
get to display all my frustration, instead I want to leave here all my
findings, the things I researched, the few things I managed to actually
code, and mostly the ideas that someone else might find useful.
To those who may want to involve in the php internals
For those in the generals list that may ever try to venture in the internals
of PHP, remember that you have to back your point of view with a patch. So,
sit down, remember the old days in college using the c compiler, and code
like a cowboy before trying to promote anything in the internals. It's the
status quo of the PHP development community, as I did learn too late.
Namespaces: function imports
Here is the patch to add function imports to 5.3. To be consistent constants
imports have to be added too:
http://martinalterisio.com.ar/php5.3/use.function.v2b.patch
If you don't know what imports are, they are just a way to refer to a longer
name with a shorter name. For example:
?php
class MyRowset extends Zend::Db::Table::Rowset::Abstract {
...
or with imports:
?php
use Zend::Db::Table::Rowset::Abstract as Rowset;
class MyRowset extends Rowset {
...
The use statement behavior currently supports only class names aliasing.
Functions and constants have to referred with full name, although these too
can be namespaced.
Import statement is broken, why, how can be fixed
While doing the previous patch I realized that the use statement is broken.
It should generate and error when you try to override an existing name. But
the use statement is handled at compile, where it's unknown if a name will
be overridden or not. What happens is that the error might be triggered
depending on the conditions and order of compilation. If you have an opcode
cache, this error may not appear until the cache is invalidated.
On a suggestion by Dmitry, which I
Re: [PHP] Simple RegEx question
M5 schreef:
I'm learning regular expressions, and trying to figure out what's
possible and what's not.
pretty much anything as far as string parsing goes.
Any ideas of how to create a preg_match
expression to parse following three lines:
yes. given your intention to learn regexps why not try to come
up with one? if you get stuck show us what you have so far ...
you don't learn to eat with cutlery by being spoonfed.
if you want to parse the whole string in one go you'll want to use
preg_match_all() otherwise use preg_match and iterate over each line ..
foreach(explode(\n, $data) as $line) {
$matches = array();
if (preg_match($line, $regexp, $matches)) {
/* do something */
}
}
Calgary, AB T2A6C1
Toronto, ON T4M 0B0
Saint John, NBE2L 4L1
...such that it splits each line into City, Province and Postalcode
(irrespective of occasional white space), e.g.:
Array
(
[city]= Calgary,
[prov]= AB,
[postal]= T2A 6C1
)
Array
(
[city]= Toronto,
[prov]= ON,
[postal]= T4M 0B0
)
Array
(
[city]= Saint John,
[prov]= NB,
[postal]= E2L 4L1
)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] loadHTML()
M5 schreef:
OK, I already knew that making it valid doesn't change the result. But
the question remains, how to parse the HTML as it arrives (which I have
no control over anyway), besides doing a str_replace on br and
inserting a token, which I later replace (which I shouldn't have to,
right?)
for creating valid xHTMl you can run the input through tidy
(http://php.net/tidy)
does echo $table-saveHTML() show the BR tags?
also try:
?php
foreach($table-getElementsByTagName(div) as $div) {
var_dump($div-hasAttributes(), $div-hasChildNodes());
echo htmlentities($div-C14N()); // undocumented, found in manual, no
idea if it works
}
...Rene
On 24-Dec-07, at 7:19 PM, Casey wrote:
Actually, never mind. It does not have to be valid to work.
On Dec 24, 2007, at 6:15 PM, Casey [EMAIL PROTECTED] wrote:
That's because it's not proper XHTML: br should be br /.
On Dec 24, 2007, at 6:03 PM, M5 [EMAIL PROTECTED] wrote:
Just getting into DOMDocument()... I'm loading an HTML page and
trying to extract certain bits of text. Just one problem: loadHTML()
seems to ignore orphan tags like 'br'. For example, in the
following HTML:
div class=textSome text is here. br New line. br Another new
line. /div
div class=textSome text is here. br New line. br Another new
line. /div
div class=textSome text is here. br New line. br Another new
line. /div
If I run the above HTML through:
$nodes = $table-getElementsByTagName(*);
I only get three nodes that I can iterate through (div). What I
want to do is split/explode the three lines within each div, but
when I look at the nodeValue of each node, it only shows something
like Some text is here. New line. Another new line.
Any ideas?
...Rene
--
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
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Sayonara PHP
Please let me do a little explanation of the title first. Japanese is an
interesting language where context is vital to the meaning of a word.
Sayonara usually means a simple good bye, but within a different context
can mean we'll probably never meet again.
To understand this mail you'll have to know that I was just another user of
PHP, an user that was probably too eager. I wanted to get more involved with
the development of PHP as I do believe in all the philosophy of open-source.
In the end I found my attempts ended in frustration, but, nevertheless, I
learned a lot in just a few months. I don't want this mail to be one where I
get to display all my frustration, instead I want to leave here all my
findings, the things I researched, the few things I managed to actually
code, and mostly the ideas that someone else might find useful.
To those who may want to involve in the php internals
For those in the generals list that may ever try to venture in the internals
of PHP, remember that you have to back your point of view with a patch. So,
sit down, remember the old days in college using the c compiler, and code
like a cowboy before trying to promote anything in the internals. It's the
status quo of the PHP development community, as I did learn too late.
Namespaces: function imports
Here is the patch to add function imports to 5.3. To be consistent constants
imports have to be added too:
http://martinalterisio.com.ar/php5.3/use.function.v2b.patch
If you don't know what imports are, they are just a way to refer to a longer
name with a shorter name. For example:
?php
class MyRowset extends Zend::Db::Table::Rowset::Abstract {
...
or with imports:
?php
use Zend::Db::Table::Rowset::Abstract as Rowset;
class MyRowset extends Rowset {
...
The use statement behavior currently supports only class names aliasing.
Functions and constants have to referred with full name, although these too
can be namespaced.
Import statement is broken, why, how can be fixed
While doing the previous patch I realized that the use statement is broken.
It should generate and error when you try to override an existing name. But
the use statement is handled at compile, where it's unknown if a name will
be overridden or not. What happens is that the error might be triggered
depending on the conditions and order of compilation. If you have an opcode
cache, this error may not appear until the cache is invalidated.
On a suggestion by Dmitry, which I really don't know if he knew about this
issue with use or not, but, anyway, his idea solved this issue, I made this
patch:
http://martinalterisio.com.ar/php5.3/file.scope.use.patch
With this the use statement is checked only against the names used in the
current file (or namespace if using multiple namespaces per file). Since the
imports only affect the current file, this is more sensible, and the issue
mentioned before disappears.
Name clash and ambiguity issue introduced by namespaces
There's another pending issue with namespaces, there's a name clash that
currently goes undetected, and makes static methods partially unavailable.
This is due to the fact that using :: as namespace separator generates
ambiguity. foo::bar() can refer to the static method bar in class foo, or to
the function bar in the namespace foo. This is an issue to php library
developers. Someone can inject a namespaced function which overrides your
static method.
One possible solution I approached was to prevent the name clash altogether,
but I found this approach inappropriate for 2 reasons: the performance
impact is too big; is not consistent with how other name clashes are handled
in php (classes and functions may have the same name).
Another approach, which I believe is the correct one but never got the
chance to implement in a patch, is to change the order of name resolution,
search first the static method and then the namespaced function, and if the
user wants to refer to the function he can import the function. This way
both remain accessible although the user has to solve the ambiguity. Also
this reduces the impact of adding namespaces on legacy code, since there's
an impact to all static method calls (because first the namespaced function
is searched).
Reducing impact on performance introduced by namespaces
I found out that although the philosophy behind the namespaces
implementation is to do as much as possible in compile time, but much is
pushed to the executor. Those could be solved on compile time. Much can be
optimized changing the name resolution rules. If these become more explicit,
the compiler can discern which is the actual name that's referred to. As of
now, it can be optimized using imports and explicit names, which are used as
alternative notation. In other words, the normal use of namespaces is not
optimal.
There's still one name resolution that seems inevitable that it will fall to
the executor: the ambiguity mentioned earlier between
