php-general Digest 20 Jan 2010 03:17:03 -0000 Issue 6547
Topics (messages 301217 through 301234):
Re: Object Oriented Programming question
301217 by: Bob McConnell
301218 by: Floyd Resler
301219 by: Ashley Sheridan
301220 by: Paul M Foster
301222 by: Ashley Sheridan
301223 by: Paul M Foster
301225 by: Robert Cummings
301227 by: Paul M Foster
Re: Cookies & sessions
301221 by: Paul M Foster
301224 by: Adam Richardson
301234 by: clancy_1.cybec.com.au
Re: Zend debugger doesn't work
301226 by: Jochem Maas
Iterating ASTs with SPL in PHP-5.3.1
301228 by: Aspra Flavius Adrian
Re: Casting objects.
301229 by: Carlos Medina
Re: order by ASC
301230 by: Daevid Vincent
301231 by: Ashley Sheridan
301232 by: Daevid Vincent
301233 by: Ashley Sheridan
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]
----------------------------------------------------------------------
--- Begin Message ---
From: Ben Stones
> I've been learning about object oriented programming for the past few
weeks
> and I've understood it pretty well, but I have one question. Usually
with
> PHP scripts I make, all the functionality for a specific page is in
the
> actual PHP file, and I'd use PHP functions in a separate directory
which
> would be included in whichever PHP file needs specific functions I
have
> created. The functions would be for the specific things in my script,
such
> as validation checks, functionality that will be used/repeated a lot
> throughout my script, etc. What I don't understand about OOP is what
its
> primary purpose is for. Do I use OOP for all the functionality of my
> application, in separate directories, and include these specific class
files
> and call the methods to complete specific functionality needed for
whatever
> PHP file I'm working on, or is OOP used for specific functionality
like I
> would with functions? Essentially what I'm asking is what is the
primary
> purpose for OOP? Hope you understand.
OOP is a way of looking at a problem and map it into code. Some problems
will fit into it, some don't. Some people can look at problems and see
objects and some can't. But in most cases, it is not easy to take an
existing procedural program and re-map it into objects. It would be
easier to start over from the specification and write it from scratch in
the object model.
If you have been doing procedural programming, don't worry if you don't
figure it out right away. It is not an easy transition to make. Many of
us with decades of programming behind us will never be able to make that
switch. Our brains are too tightly locked into the previous thought
patterns.
Bob McConnell
--- End Message ---
--- Begin Message ---
Ben,
I use a combination of procedural and OOP in my scripts. It depends on
my needs. As an example, I use OOP for gathering order information. I created
a class which gathers all the order information allowing me to easily access
any piece of data in the order. I could do this with a bunch of individual
functions but it's easier and more logical to group them all together in a
single class. When I first started working with classes, I used them
sparingly. Now I find myself using them more and more.
Take care,
Floyd
On Jan 19, 2010, at 10:11 AM, Ben Stones wrote:
> Hi,
>
> I've been learning about object oriented programming for the past few weeks
> and I've understood it pretty well, but I have one question. Usually with
> PHP scripts I make, all the functionality for a specific page is in the
> actual PHP file, and I'd use PHP functions in a separate directory which
> would be included in whichever PHP file needs specific functions I have
> created. The functions would be for the specific things in my script, such
> as validation checks, functionality that will be used/repeated a lot
> throughout my script, etc. What I don't understand about OOP is what its
> primary purpose is for. Do I use OOP for all the functionality of my
> application, in separate directories, and include these specific class files
> and call the methods to complete specific functionality needed for whatever
> PHP file I'm working on, or is OOP used for specific functionality like I
> would with functions? Essentially what I'm asking is what is the primary
> purpose for OOP? Hope you understand.
>
> Thanks,
--- End Message ---
--- Begin Message ---
On Tue, 2010-01-19 at 15:11 +0000, Ben Stones wrote:
> Hi,
>
> I've been learning about object oriented programming for the past few weeks
> and I've understood it pretty well, but I have one question. Usually with
> PHP scripts I make, all the functionality for a specific page is in the
> actual PHP file, and I'd use PHP functions in a separate directory which
> would be included in whichever PHP file needs specific functions I have
> created. The functions would be for the specific things in my script, such
> as validation checks, functionality that will be used/repeated a lot
> throughout my script, etc. What I don't understand about OOP is what its
> primary purpose is for. Do I use OOP for all the functionality of my
> application, in separate directories, and include these specific class files
> and call the methods to complete specific functionality needed for whatever
> PHP file I'm working on, or is OOP used for specific functionality like I
> would with functions? Essentially what I'm asking is what is the primary
> purpose for OOP? Hope you understand.
>
> Thanks,
There are a few advantages by going the OOP route with PHP.
Firstly, you can bring together what would normally be in several
variables into one object, making it easier to work with, instead of
having to use various global variables to hold all the information.
Also, you can instantiate more than one object of the same type, and it
is a lot easier to work with than global variables. For some complex
cases, you could only manage this with a huge global array, which would
become unwieldy if made too large.
Secondly, object allow inheritance. So, if you create an object class,
you could use that as a basis for another more complex object by
building upon it with inheritance. You can also use other classes as a
basis for a more complex one of your own. Pear does this quite a lot.
Lastly, with OOP, you can create functions that can only be called from
within your object. These methods allow you to create functions that
will only ever be used by your classes, and won't accidentally be called
from anywhere else in your scripts.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Tue, Jan 19, 2010 at 03:11:56PM +0000, Ben Stones wrote:
> Hi,
>
> I've been learning about object oriented programming for the past few weeks
> and I've understood it pretty well, but I have one question. Usually with
> PHP scripts I make, all the functionality for a specific page is in the
> actual PHP file, and I'd use PHP functions in a separate directory which
> would be included in whichever PHP file needs specific functions I have
> created. The functions would be for the specific things in my script, such
> as validation checks, functionality that will be used/repeated a lot
> throughout my script, etc. What I don't understand about OOP is what its
> primary purpose is for. Do I use OOP for all the functionality of my
> application, in separate directories, and include these specific class files
> and call the methods to complete specific functionality needed for whatever
> PHP file I'm working on, or is OOP used for specific functionality like I
> would with functions? Essentially what I'm asking is what is the primary
> purpose for OOP? Hope you understand.
<opinion>
OOP is a *trend* or *fad* in programming. You can create a whole
application written almost entirely with OOP. It will usually follow the
MVC (Model-View-Controller) paradigm. It will have a front controller
(one page that every other page starts from) and distribute the work of
displaying pages, validating values, and storing data across a variety
of classes in a bunch of files. See a package called CodeIgniter for a
good but simple example of this paradigm. Generally, an application
written this way will load many tens of pages' worth of code before any
byte gets to the screen.
Alternatively, you can write simple OOP components for selected parts of
your application. For example, if you're dealing with a bunch of
customer screens, you can write an object oriented class which handles
all the customer queries with the database.
There are a variety of arguments that OOP advocates will make in favor
of OOP. It's *supposed* to make your programming easier and faster, and
make for easier debugging. In the real world, this may or may not be
true. OOP does work to reduce the clutter in your namespaces-- the
names of methods within classes are hidden from the rest of your
namespace, unlike global functions. It also relieves you from having to
pass a lot of parameters to each routine you call; you can store a lot
of properties in the class, and they are shared with the methods in the
class.
One of the more serious problems I've seen with OOP lies with classes
which have dependencies on other classes. It's like walking a minefield
sometimes, ensuring that this class gets instantiated before that one,
which depends on it. You can write an incredibly complicated automatic
instantiator which instantiates classes and ensures they fire in the
proper order (I have), but it seems kind of silly when you could just as
easily write external functions which perform similar functions.
</opinion>
Bottom line is, study OOP (look it up in wikipedia.org), and if you
think its advantages are worth your effort to learn the new paradigm, go
with it. But ignore the hype (and there's a lot of it). Do what works
for you.
<suit status=on type=flame-retardant>
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Tue, 2010-01-19 at 12:30 -0500, Paul M Foster wrote:
> On Tue, Jan 19, 2010 at 03:11:56PM +0000, Ben Stones wrote:
>
> > Hi,
> >
> > I've been learning about object oriented programming for the past few weeks
> > and I've understood it pretty well, but I have one question. Usually with
> > PHP scripts I make, all the functionality for a specific page is in the
> > actual PHP file, and I'd use PHP functions in a separate directory which
> > would be included in whichever PHP file needs specific functions I have
> > created. The functions would be for the specific things in my script, such
> > as validation checks, functionality that will be used/repeated a lot
> > throughout my script, etc. What I don't understand about OOP is what its
> > primary purpose is for. Do I use OOP for all the functionality of my
> > application, in separate directories, and include these specific class files
> > and call the methods to complete specific functionality needed for whatever
> > PHP file I'm working on, or is OOP used for specific functionality like I
> > would with functions? Essentially what I'm asking is what is the primary
> > purpose for OOP? Hope you understand.
>
> <opinion>
>
> OOP is a *trend* or *fad* in programming. You can create a whole
> application written almost entirely with OOP. It will usually follow the
> MVC (Model-View-Controller) paradigm. It will have a front controller
> (one page that every other page starts from) and distribute the work of
> displaying pages, validating values, and storing data across a variety
> of classes in a bunch of files. See a package called CodeIgniter for a
> good but simple example of this paradigm. Generally, an application
> written this way will load many tens of pages' worth of code before any
> byte gets to the screen.
>
> Alternatively, you can write simple OOP components for selected parts of
> your application. For example, if you're dealing with a bunch of
> customer screens, you can write an object oriented class which handles
> all the customer queries with the database.
>
> There are a variety of arguments that OOP advocates will make in favor
> of OOP. It's *supposed* to make your programming easier and faster, and
> make for easier debugging. In the real world, this may or may not be
> true. OOP does work to reduce the clutter in your namespaces-- the
> names of methods within classes are hidden from the rest of your
> namespace, unlike global functions. It also relieves you from having to
> pass a lot of parameters to each routine you call; you can store a lot
> of properties in the class, and they are shared with the methods in the
> class.
>
> One of the more serious problems I've seen with OOP lies with classes
> which have dependencies on other classes. It's like walking a minefield
> sometimes, ensuring that this class gets instantiated before that one,
> which depends on it. You can write an incredibly complicated automatic
> instantiator which instantiates classes and ensures they fire in the
> proper order (I have), but it seems kind of silly when you could just as
> easily write external functions which perform similar functions.
>
> </opinion>
>
> Bottom line is, study OOP (look it up in wikipedia.org), and if you
> think its advantages are worth your effort to learn the new paradigm, go
> with it. But ignore the hype (and there's a lot of it). Do what works
> for you.
>
> <suit status=on type=flame-retardant>
>
> Paul
>
> --
> Paul M. Foster
>
I wouldn't call OOP a fad really, as that suggest a silly short-term
trend, but you do bring up a good point about class dependency problems.
If dependencies are causing that sort of level of problem, then it might
be worth re-making part of the wheel (after all, you wouldn't see wooden
cart wheels on a Ferrari, would you?!)
I've seen plenty of sites use no OOP at all, but I think once a system
gets beyond a certain size, it does make more sense to use OOP, just to
avoid running into problems where you have so many functions performing
so many tasks but becoming a nightmare to maintain.
Oh, and your flame suit failed because you forgot the quotation marks
around the attribute values, and you didn't close the tag :p
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Tue, Jan 19, 2010 at 05:44:56PM +0000, Ashley Sheridan wrote:
<snip>
>
> Oh, and your flame suit failed because you forgot the quotation marks around
> the attribute values, and you didn't close the tag :p
Dang! I *thought* it felt awfully warm in here.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Ashley Sheridan wrote:
On Tue, 2010-01-19 at 12:30 -0500, Paul M Foster wrote:
On Tue, Jan 19, 2010 at 03:11:56PM +0000, Ben Stones wrote:
Hi,
I've been learning about object oriented programming for the past few weeks
and I've understood it pretty well, but I have one question. Usually with
PHP scripts I make, all the functionality for a specific page is in the
actual PHP file, and I'd use PHP functions in a separate directory which
would be included in whichever PHP file needs specific functions I have
created. The functions would be for the specific things in my script, such
as validation checks, functionality that will be used/repeated a lot
throughout my script, etc. What I don't understand about OOP is what its
primary purpose is for. Do I use OOP for all the functionality of my
application, in separate directories, and include these specific class files
and call the methods to complete specific functionality needed for whatever
PHP file I'm working on, or is OOP used for specific functionality like I
would with functions? Essentially what I'm asking is what is the primary
purpose for OOP? Hope you understand.
<opinion>
OOP is a *trend* or *fad* in programming. You can create a whole
application written almost entirely with OOP. It will usually follow the
MVC (Model-View-Controller) paradigm. It will have a front controller
(one page that every other page starts from) and distribute the work of
displaying pages, validating values, and storing data across a variety
of classes in a bunch of files. See a package called CodeIgniter for a
good but simple example of this paradigm. Generally, an application
written this way will load many tens of pages' worth of code before any
byte gets to the screen.
Alternatively, you can write simple OOP components for selected parts of
your application. For example, if you're dealing with a bunch of
customer screens, you can write an object oriented class which handles
all the customer queries with the database.
There are a variety of arguments that OOP advocates will make in favor
of OOP. It's *supposed* to make your programming easier and faster, and
make for easier debugging. In the real world, this may or may not be
true. OOP does work to reduce the clutter in your namespaces-- the
names of methods within classes are hidden from the rest of your
namespace, unlike global functions. It also relieves you from having to
pass a lot of parameters to each routine you call; you can store a lot
of properties in the class, and they are shared with the methods in the
class.
One of the more serious problems I've seen with OOP lies with classes
which have dependencies on other classes. It's like walking a minefield
sometimes, ensuring that this class gets instantiated before that one,
which depends on it. You can write an incredibly complicated automatic
instantiator which instantiates classes and ensures they fire in the
proper order (I have), but it seems kind of silly when you could just as
easily write external functions which perform similar functions.
</opinion>
Bottom line is, study OOP (look it up in wikipedia.org), and if you
think its advantages are worth your effort to learn the new paradigm, go
with it. But ignore the hype (and there's a lot of it). Do what works
for you.
<suit status=on type=flame-retardant>
Paul
--
Paul M. Foster
I wouldn't call OOP a fad really, as that suggest a silly short-term
trend, but you do bring up a good point about class dependency problems.
If dependencies are causing that sort of level of problem, then it might
be worth re-making part of the wheel (after all, you wouldn't see wooden
cart wheels on a Ferrari, would you?!)
I've seen plenty of sites use no OOP at all, but I think once a system
gets beyond a certain size, it does make more sense to use OOP, just to
avoid running into problems where you have so many functions performing
so many tasks but becoming a nightmare to maintain.
I would have to agree that OOP is not a fad, perhaps over-hyped at
times, but definitely not a fad. The argument about class dependencies
is an invalid argument since functions will also have dependencies on
other functions from other libraries, quite likely located in multiple
source files. In fact, you've argued an advantage for OOP in the context
of PHP since autoload can be used to mitigate this issue for classes,
but not for functions. Another advantage of OOP that is difficult to
provide via the procedural paradigm is polymorphism.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--- End Message ---
--- Begin Message ---
On Tue, Jan 19, 2010 at 01:12:49PM -0500, Robert Cummings wrote:
<snip>
>
> I would have to agree that OOP is not a fad, perhaps over-hyped at
> times, but definitely not a fad. The argument about class dependencies
> is an invalid argument since functions will also have dependencies on
> other functions from other libraries, quite likely located in multiple
> source files.
Yes, functions can have dependencies as well, but you simply call the
function you need from within another function. It's been done for
decades in C and any number of other languages. Anyone who's ever
programmed in C (or comparable language) is familiar with having to do
"includes" at the beginning of source files and simply calling functions
now visible or now linked. This practice is frowned upon in OOP, or
"dependency injection" wouldn't have been written about so much.
> In fact, you've argued an advantage for OOP in the context
> of PHP since autoload can be used to mitigate this issue for classes,
> but not for functions.
Autoloading doesn't mitigate class interdependency unless you build an
autoload function which handles dependency injection transparently.
Again, a complex proposition.
> Another advantage of OOP that is difficult to
> provide via the procedural paradigm is polymorphism.
Agreed. Though the advantages of polymorphism are questionable,
depending on your viewpoint.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Tue, Jan 19, 2010 at 10:06:26PM +1100, [email protected] wrote:
> I am trying for the first time to use cookies. The manual contains the
> statement "Cookies
> are part of the HTTP header, so setcookie() must be called before any
> output is sent to
> the browser."
>
> When I first started using sessions, I was alarmed to read a very similar
> statement about
> sessions, but I soon found that if I started my program with the statement
> "session_start();" I could then set up, access, modify or clear any session
> variable at
> any time in my program. This is enormously useful, as I can put the session
> handling at
> any convenient point in my program, and can precede them with diagnostics
> if I need to.
>
> However I have almost immediately found that while I appear to be able to
> read cookies at
> any time, I cannot set them when I would like to. Is there any similar
> trick which will
> work with cookies? If I really have to work out what they should be,
> and then set them up,
> before issuing any diagnostics, etc, it will make life decidely more
> complicated. (I
> assume that I can set several cookies using successive calls to setcookie()?)
Session variables are available throughout your session. Cookie
variables are only available if you read them into variables you can
access. Changes to session variables will the flushed to the server when
your page is terminated. Cookie variables are flushed to disk if you
make the appropriate *_cookie() function call, and even then I don't
know if this is actually echoed to disk until your page is terminated.
>
> I was also somewhat surprised to find that a cookie is used to implement
> sessions. Does
> this place any limitations on using both sessions and cookies in the
> same program?
I don't believe so. If I'm not mistaken, session values are stored on the
server, not on the client. What's stored on the client is the session
ID.
Please bear in mind my understanding of cookies is fragmentary, and I
hope someone else will write in to correct any incorrect statements I've
made.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Tue, Jan 19, 2010 at 12:42 PM, Paul M Foster <[email protected]>wrote:
> On Tue, Jan 19, 2010 at 10:06:26PM +1100, [email protected] wrote:
>
> > I am trying for the first time to use cookies. The manual contains the
> > statement "Cookies
> > are part of the HTTP header, so setcookie() must be called before any
> > output is sent to
> > the browser."
> >
> > When I first started using sessions, I was alarmed to read a very similar
> > statement about
> > sessions, but I soon found that if I started my program with the
> statement
> > "session_start();" I could then set up, access, modify or clear any
> session
> > variable at
> > any time in my program. This is enormously useful, as I can put the
> session
> > handling at
> > any convenient point in my program, and can precede them with diagnostics
> > if I need to.
> >
> > However I have almost immediately found that while I appear to be able to
> > read cookies at
> > any time, I cannot set them when I would like to. Is there any similar
> > trick which will
> > work with cookies? If I really have to work out what they should be,
> > and then set them up,
> > before issuing any diagnostics, etc, it will make life decidely more
> > complicated. (I
> > assume that I can set several cookies using successive calls to
> setcookie()?)
>
> Session variables are available throughout your session. Cookie
> variables are only available if you read them into variables you can
> access. Changes to session variables will the flushed to the server when
> your page is terminated. Cookie variables are flushed to disk if you
> make the appropriate *_cookie() function call, and even then I don't
> know if this is actually echoed to disk until your page is terminated.
>
> >
> > I was also somewhat surprised to find that a cookie is used to implement
> > sessions. Does
> > this place any limitations on using both sessions and cookies in the
> > same program?
>
> I don't believe so. If I'm not mistaken, session values are stored on the
> server, not on the client. What's stored on the client is the session
> ID.
>
> Please bear in mind my understanding of cookies is fragmentary, and I
> hope someone else will write in to correct any incorrect statements I've
> made.
>
> Paul
>
> --
> Paul M. Foster
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> I was also somewhat surprised to find that a cookie is used to implement
> sessions. Does
> this place any limitations on using both sessions and cookies in the
> same program?
There shouldn't be any issue. By default, PHP uses a cookie named
PHPSESSIONID to associate a particular visitor with their corresponding
session data stored server-side. So, just be sure not to use a cookie
called "PHPSESSIONID".
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Tue, 19 Jan 2010 09:12:17 -0200, [email protected] (Bruno Fajardo) wrote:
>2010/1/19 <[email protected]>:
>> I am trying for the first time to use cookies. The manual contains the
>> statement "Cookies
>> are part of the HTTP header, so setcookie() must be called before any output
>> is sent to
>> the browser."
>>
>> When I first started using sessions, I was alarmed to read a very similar
>> statement about
>> sessions, but I soon found that if I started my program with the statement
>> "session_start();" I could then set up, access, modify or clear any session
>> variable at
>> any time in my program. This is enormously useful, as I can put the session
>> handling at
>> any convenient point in my program, and can precede them with diagnostics if
>> I need to.
>>
>> However I have almost immediately found that while I appear to be able to
>> read cookies at
>> any time, I cannot set them when I would like to. Is there any similar trick
>> which will
>> work with cookies?
>
>The only trick is that you have to call setcookie() before any output
>is sent to the browser, just like the session_start() behavior.
> ......
Thank you all for your suggestions. Unfortunately I have already tried this,
and it
doesn't work for me (I am running PHP: 5.1.6). I have only tested this on my
own PC, but
if it doesn't work here, I would be very surprised if it would work on the
remote server.
Index.php starts:
<?php //;V;;; Cypalda/Index.php Printed:
session_start ();
setcookie ();
setcookie ('user_id', 'Wilma*Witgenstein', time()+3600);
And this produces the following output:
Warning: setcookie() expects at least 1 parameter, 0 given in
D:\Websites\cypalda.com\index.php on line 4
Warning: Cannot modify header information - headers already sent by (output
started at
D:\Websites\cypalda.com\index.php:4) in D:\Websites\cypalda.com\index.php on
line 5
It is interesting to note that the second diagnostic is generated because the
first
diagnostic is taken to have initiated the headers. I think I can live with this
limitation, but this diagnostic is a warning of the hassles I am likely to face
if I
cannot find a way around it.
--- End Message ---
--- Begin Message ---
Op 1/18/10 10:38 AM, Ali Asghar Toraby Parizy schreef:
> Hi
> I have installed php 5.3.1 (with thread safety = on) recently And I
I would try without thread safety to start with, 'std' setup uses
the pre-fork model which doesn't need it and *may* cause probs. [fast]CGI
doesn't need thread safety either IIRC.
> tried to install zend debugger yesterday. I downloaded zend debugger
> extension from http://downloads.zend.com/pdt/server-debugger/
> But I didn't find dll module for 5.3.x release. So I tried dll file in
> 5_2_x_comp folder. When I start Apache, I have a line in log file that
that 5.2 version won't work.
> says:
I think you can DL a 5.3 compatible module from:
http://www.zend.com/en/products/studio/downloads
requires registration IIRC.
> Apache/2.2.14 (Win32) PHP/5.3.1 configured -- resuming normal operations
> And phpinfo() says nothing about debugger module! What do you think
> about this thing? I haven't seen any error, But there is no debug
> session!
if your not seeing any errors related to failing to load then you have
either not made the required changed to php.ini or the changes you made are
not at all correct (and php is ignoring them) ... I did also read stuff about
the
zend_* php.ini directives no longer supporting the '_ts' variants in php5.3, but
I have on idea if that is correct.
> Should I wait for 5.3.x release of zend debugger?
--- End Message ---
--- Begin Message ---
Hi
I have an abstract syntax tree which I need to iterate. The AST is generated
by the lemon port to PHP, found in PEAR.
Now "normally", I'd do it with the brand new and shiny (PHP 5.3.1) SPL
classes, and it would look like this:
$it = new \RecursiveIteratorIterator(
new \RecursiveArrayIterator($ast),
\RecursiveIteratorIterator::SELF_FIRST);
Actually, that's what I'm already doing in another part of the code which
determinates a rough type of the entire tree (i.e it can be an assignment, a
condition, etc). Now details aside, the only important thing is the
iteration is done in a RecursiveIteratorIterator::SELF_FIRST manner, that
is, top-down.
Going back to my problem, I need to iterate the AST bottom-up, that is,
something like RecursiveIteratorIterator::CHILD_FIRST, in order to do some
substitutions and optimizations in the tree.
The problem is, these operations need to be context-aware, i.e. I need the
path down to the current node, starting at the root. And since I want to
iterate bottom-up, I can't have that with RecursiveIteratorIterator, at
least not with it alone.
Well think about it for a second. I want to iterate bottom-up and have the
top-down context (a stack) of the current node, at each iteration.
Technically it should be possible, since RecursiveIteratorIterator must
first go to the tail of the tree(I assume), in order to iterate it
backwards. In its way to the tail, it could cache the current position, and
simply pop out elements as it returns back from recursion.
Now this is a keyword: **caching**. This is why I suspect it should be
possible with another SPL class: RecursiveCachingIterator.
The question is: is it really possible? If yes, how?
I've been trying to puzzle around with some code, without success, and the
documentation is scarce. Really, really scarce.
So I'm looking for **as much SPL (re)usage as possible**. I know I could
write my own recursive functions with a custom stack.
A small PoC would be welcome.
Thanks
--
Flavius Aspra
--- End Message ---
--- Begin Message ---
Richard Quadling schrieb:
2010/1/18 Shawn McKenzie <[email protected]>:
Shawn McKenzie wrote:
Never mind, that was stupid. I saw that somewhere before, but obviously
it doesn't work.
I found some code, maybe I redeem myself?
static public function cast(&$object, $class=__CLASS__){
if(class_exists($class)) {
$object = unserialize(
preg_replace('/^O:[0-9]+:"[^"]+":/i',
'O:'.strlen($class).':"'.$class.'":',
serialize($object)));
}
}
$row = odbc_fetch_object($result);
structuresRemovalReason::cast($row);
--
Thanks!
-Shawn
http://www.spidean.com
That's an interesting approach.
Though I'm going to use reflection. I realise I need to hold some of
the data in strings where the data is not a string (datetimes for
example).
So, using a docblock with a customtag and this seems to be working just fine.
Extended ReflectionClass and ReflectionProperty.
Thanks,
Richard.
Hi,
i think it will be important since more PHP Developer are using Design
Patterns. I think the cast functionality should be implemented once...
Regards
Carlos
--- End Message ---
--- Begin Message ---
http://www.webdeveloper.com/forum/showthread.php?t=101174
You could do it like this too...
ORDER BY `rollnumber` + 0 ASC
And if you just got the data out in mysql (no ORDER BY -- which can be slow
in mysql), you could use PHP's sort as well...
http://php.net/manual/en/function.natsort.php
> -----Original Message-----
> From: Robert Cummings [mailto:[email protected]]
> Sent: Saturday, January 16, 2010 9:37 PM
> To: John Taylor-Johnston
> Cc: PHP-General
> Subject: Re: [PHP] order by ASC
>
> John Taylor-Johnston wrote:
> > Did some googling. This worked:
> > ORDER BY CAST(`rollnumber` AS SIGNED)
> >
> > What is the difference? My problem in the meanwhile must be
> my version
> > of MySQL?
>
> You could have skipped quotes altogether. The difference is
> that you are
> referencing a field name, not a string value.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
On Tue, 2010-01-19 at 16:16 -0800, Daevid Vincent wrote:
> http://www.webdeveloper.com/forum/showthread.php?t=101174
>
> You could do it like this too...
>
> ORDER BY `rollnumber` + 0 ASC
>
> And if you just got the data out in mysql (no ORDER BY -- which can be slow
> in mysql), you could use PHP's sort as well...
>
> http://php.net/manual/en/function.natsort.php
>
> > -----Original Message-----
> > From: Robert Cummings [mailto:[email protected]]
> > Sent: Saturday, January 16, 2010 9:37 PM
> > To: John Taylor-Johnston
> > Cc: PHP-General
> > Subject: Re: [PHP] order by ASC
> >
> > John Taylor-Johnston wrote:
> > > Did some googling. This worked:
> > > ORDER BY CAST(`rollnumber` AS SIGNED)
> > >
> > > What is the difference? My problem in the meanwhile must be
> > my version
> > > of MySQL?
> >
> > You could have skipped quotes altogether. The difference is
> > that you are
> > referencing a field name, not a string value.
> >
> > Cheers,
> > Rob.
> > --
> > http://www.interjinn.com
> > Application and Templating Framework for PHP
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
I've always found that ordering is much faster in MySQL than PHP. You
use quite a lot of memory sorting in PHP as well, as you first have to
load the whole result set into an array, which is additional to any
memory used in the result set by PHP and MySQL anyway.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
http://lmgtfy.com/?q=mysql+order+by+slow
it's notoriously slow to use ORDER BY with large tables. Mainly b/c mySQL
has to use a hash/temp table to re-sort AFAIK.
I wasn't thinking of sorting the whole set, only the list of numbers as the
OP only talked about sorting a single column...
>>> rollnumber is a varchar(50). I need it to be a text field. ASC does
>>> not order the way I want.
>>>
>>> 1000
>>> 1001
>>> 998
>>> 999
>>>
>>> I want it to order like this:
>>>
>>> 998
>>> 999
>>> 1000
>>> 1001
_____
From: Ashley Sheridan [mailto:[email protected]]
Sent: Tuesday, January 19, 2010 4:40 PM
To: Daevid Vincent
Cc: 'PHP-General'
Subject: RE: [PHP] order by ASC
On Tue, 2010-01-19 at 16:16 -0800, Daevid Vincent wrote:
http://www.webdeveloper.com/forum/showthread.php?t=101174
You could do it like this too...
ORDER BY `rollnumber` + 0 ASC
And if you just got the data out in mysql (no ORDER BY -- which can be slow
in mysql), you could use PHP's sort as well...
http://php.net/manual/en/function.natsort.php
> -----Original Message-----
> From: Robert Cummings [mailto:[email protected]]
> Sent: Saturday, January 16, 2010 9:37 PM
> To: John Taylor-Johnston
> Cc: PHP-General
> Subject: Re: [PHP] order by ASC
>
> John Taylor-Johnston wrote:
> > Did some googling. This worked:
> > ORDER BY CAST(`rollnumber` AS SIGNED)
> >
> > What is the difference? My problem in the meanwhile must be
> my version
> > of MySQL?
>
> You could have skipped quotes altogether. The difference is
> that you are
> referencing a field name, not a string value.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
I've always found that ordering is much faster in MySQL than PHP. You use
quite a lot of memory sorting in PHP as well, as you first have to load the
whole result set into an array, which is additional to any memory used in
the result set by PHP and MySQL anyway.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Tue, 2010-01-19 at 17:11 -0800, Daevid Vincent wrote:
> http://lmgtfy.com/?q=mysql+order+by+slow
>
> it's notoriously slow to use ORDER BY with large tables. Mainly b/c mySQL
> has to use a hash/temp table to re-sort AFAIK.
>
> I wasn't thinking of sorting the whole set, only the list of numbers as the
> OP only talked about sorting a single column...
>
> >>> rollnumber is a varchar(50). I need it to be a text field. ASC does
> >>> not order the way I want.
> >>>
> >>> 1000
> >>> 1001
> >>> 998
> >>> 999
> >>>
> >>> I want it to order like this:
> >>>
> >>> 998
> >>> 999
> >>> 1000
> >>> 1001
>
>
> _____
>
> From: Ashley Sheridan [mailto:[email protected]]
> Sent: Tuesday, January 19, 2010 4:40 PM
> To: Daevid Vincent
> Cc: 'PHP-General'
> Subject: RE: [PHP] order by ASC
>
>
> On Tue, 2010-01-19 at 16:16 -0800, Daevid Vincent wrote:
>
> http://www.webdeveloper.com/forum/showthread.php?t=101174
>
>
>
> You could do it like this too...
>
>
>
> ORDER BY `rollnumber` + 0 ASC
>
>
>
> And if you just got the data out in mysql (no ORDER BY -- which can be slow
>
> in mysql), you could use PHP's sort as well...
>
>
>
> http://php.net/manual/en/function.natsort.php
>
>
>
> > -----Original Message-----
>
> > From: Robert Cummings [mailto:[email protected]]
>
> > Sent: Saturday, January 16, 2010 9:37 PM
>
> > To: John Taylor-Johnston
>
> > Cc: PHP-General
>
> > Subject: Re: [PHP] order by ASC
>
> >
>
> > John Taylor-Johnston wrote:
>
> > > Did some googling. This worked:
>
> > > ORDER BY CAST(`rollnumber` AS SIGNED)
>
> > >
>
> > > What is the difference? My problem in the meanwhile must be
>
> > my version
>
> > > of MySQL?
>
> >
>
> > You could have skipped quotes altogether. The difference is
>
> > that you are
>
> > referencing a field name, not a string value.
>
> >
>
> > Cheers,
>
> > Rob.
>
> > --
>
> > http://www.interjinn.com
>
> > Application and Templating Framework for PHP
>
> >
>
> > --
>
> > PHP General Mailing List (http://www.php.net/)
>
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> >
>
>
>
>
>
>
> I've always found that ordering is much faster in MySQL than PHP. You use
> quite a lot of memory sorting in PHP as well, as you first have to load the
> whole result set into an array, which is additional to any memory used in
> the result set by PHP and MySQL anyway.
>
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
>
I had a look at some of the results from that link to Google, but I
didn't see anything indicating MySQL was slower at ordering than PHP,
only that MySQL has issues ordering very large query sets on queries
that it cannot use an index to order on.
I've tried optimising ordering in both PHP and MySQL, and found that
usually it's best to leave as much to the database as possible, unless
the ordering becomes too complex.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
