A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.
Then I happened to look at the temporary files created by sessions and
found much redundant data was stored in each file about the teachers
since they were referenced by every student in the same classroom.
I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead either
way -- reading large session files each time the user navigates to a
new page, or querying the database each time the user navigates to a
new page.
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?
13  2386 
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?
You can use the HEAP storage engine in MySQL (I suppose you are using
MySQL). Created tables an their contents are stored in memory, read-
and write access to the tables would be much more effective than
reading large session files or to storing data in MyIsam or InnoDB
storage engines.
Regards,
purcaholic
On 31 Aug, 12:13, purcaholic <purcaho...@googlemail.comwrote:
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?
You can use the HEAP storage engine in MySQL (I suppose you are using
MySQL). Created tables an their contents are stored in memory, read-
and write access to the tables would be much more effective than
reading large session files or to storing data in MyIsam or InnoDB
storage engines.
Regards,
purcaholic
That doesn't really answer the OPs question - he could store the
session data in a HEAP table or ramdisk - but storing the underlying
data in a HEAP would be really stupid.
OP: Storing the data in the session means that even although larger
amounts are retained, it's all read in one go - if you have to
recreate the objects at runtime you'll be making one or multiple calls
to the database. But that's at the risk of the copied data not being
current.
You have to decide based on the frequency of updates and how much of
the data will actualy be required at runtime (there's not much point
storing hundreds of objects in the session if you only use, a couple
in each script.
C.
DigitalDave wrote:
A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.
Then I happened to look at the temporary files created by sessions and
found much redundant data was stored in each file about the teachers
since they were referenced by every student in the same classroom.
I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead either
way -- reading large session files each time the user navigates to a new
page, or querying the database each time the user navigates to a new page.
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be useful
between multiple pages on a site? When are objects stored in sessions
recommended over using database queries?
Yes, objects are quite useful. It's all in how you design your object.
For instance, it's not necessary to have a copy of the teacher object
for each student - only a way to get to the teacher object.
But I don't store large amounts of data in the session like that. I
just query the database when it's needed. It's not required on every
page, and if it is required that often, chances are it's already in the
database cache, anyway.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
You can store IDs instead of real objects in session, and have a
function like "Load_Object_From_Session()" and
"Save_Object_To_Session()" to operate them - stored in shared memory
or cache storage (PHP-APC cache can provide this, see http://www.php.net/manual/en/book.apc.php )
On Aug 31, 2:15*pm, DigitalDave <d...@noSpam.comwrote:
A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.
Then I happened to look at the temporary files created by sessions and
found much redundant data was stored in each file about the teachers
since they were referenced by every student in the same classroom.
I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead either
way -- reading large session files each time the user navigates to a
new page, or querying the database each time the user navigates to a
new page.
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?
AqD wrote:
On Aug 31, 2:15 pm, DigitalDave <d...@noSpam.comwrote:
>A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.
Then I happened to look at the temporary files created by sessions and
found much redundant data was stored in each file about the teachers
since they were referenced by every student in the same classroom.
I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead either
way -- reading large session files each time the user navigates to a
new page, or querying the database each time the user navigates to a
new page.
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?
You can store IDs instead of real objects in session, and have a
function like "Load_Object_From_Session()" and
"Save_Object_To_Session()" to operate them - stored in shared memory
or cache storage (PHP-APC cache can provide this, see
http://www.php.net/manual/en/book.apc.php )
(Top posting fixed)
A very bad idea. Object id's are only unique to the current script -
not across scripts. So now you have multiple objects with the same id
in shared memory. Additionally, you will need to keep some catalog of
what's in shared memory. And using shared memory would be very insecure.
P.S. Please don't top post.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On 2008-08-31 06:06:05 -0700, Jerry Stuckle <js*******@attglobal.netsaid:
DigitalDave wrote:
>A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.
Then I happened to look at the temporary files created by sessions and
found much redundant data was stored in each file about the teachers
since they were referenced by every student in the same classroom.
I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead either
way -- reading large session files each time the user navigates to a
new page, or querying the database each time the user navigates to a
new page.
So my question is: Are php5 objects mostly useful when their lifetimes
are only within a single page? Or what other way would objects be
useful between multiple pages on a site? When are objects stored in
sessions recommended over using database queries?
Yes, objects are quite useful. It's all in how you design your object.
For instance, it's not necessary to have a copy of the teacher object
for each student - only a way to get to the teacher object.
That's exactly what we did -- we stored a reference to the teacher
object in each student object (aggregation.) But what we found upon
examining the temp file created by the session, was redundant teacher
data.
But I don't store large amounts of data in the session like that. I
just query the database when it's needed. It's not required on every
page, and if it is required that often, chances are it's already in the
database cache, anyway.
It wasn't large amounts of data in these objects. It was just redundant
objects stored in the session temp files.
But thanks for the idea that I'm beginning to get that objects aren't
useful between pages if there is composition or aggregation between
classes.
DigitalDave wrote:
On 2008-08-31 06:06:05 -0700, Jerry Stuckle <js*******@attglobal.netsaid:
>DigitalDave wrote:
>>A project I did awhile back stored php5 objects in elements of the
$_SESSION array between pages that were navigated on the site. There
were object classes representing teachers, and object classes
representing students that referenced teacher objects.
Then I happened to look at the temporary files created by sessions
and found much redundant data was stored in each file about the
teachers since they were referenced by every student in the same
classroom.
I realize that I could have stored some persistent object data in a
database rather than in the objects. But there would be overhead
either way -- reading large session files each time the user
navigates to a new page, or querying the database each time the user
navigates to a new page.
So my question is: Are php5 objects mostly useful when their
lifetimes are only within a single page? Or what other way would
objects be useful between multiple pages on a site? When are objects
stored in sessions recommended over using database queries?
Yes, objects are quite useful. It's all in how you design your
object. For instance, it's not necessary to have a copy of the
teacher object for each student - only a way to get to the teacher
object.
That's exactly what we did -- we stored a reference to the teacher
object in each student object (aggregation.) But what we found upon
examining the temp file created by the session, was redundant teacher data.
I didn't say keep a reference to the teacher object - I said have a way
to get to the teacher object. Such as an id to the object, etc.
>But I don't store large amounts of data in the session like that. I
just query the database when it's needed. It's not required on every
page, and if it is required that often, chances are it's already in
the database cache, anyway.
It wasn't large amounts of data in these objects. It was just redundant
objects stored in the session temp files.
Which you wouldn't have had had you not stored a reference to the
teacher object in your student variable.
But thanks for the idea that I'm beginning to get that objects aren't
useful between pages if there is composition or aggregation between
classes.
Objects are very useful between pages.
But this has nothing to do with objects. If ANY variable is a
reference to something else, storing the variable in the session stores
whatever it refers to. That's the only way it can work.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Sep 1, 8:46*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqD wrote:
*You can store IDs instead of real objects in session, and have a
*function like "Load_Object_From_Session()" and
*"Save_Object_To_Session()" to operate them - stored in shared memory
*or cache storage (PHP-APC cache can provide this, see
*>http://www.php.net/manual/en/book.apc.php)
*>
(Top posting fixed)
A very bad idea. *Object id's are only unique to the current script -
not across scripts.
An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
>*So now you have multiple objects with the same id
in shared memory.
is not true.
>*Additionally, you will need to keep some catalog of
what's in shared memory. *And using shared memory would be very insecure.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.
AqD wrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqD wrote:
> You can store IDs instead of real objects in session, and have a
function like "Load_Object_From_Session()" and
"Save_Object_To_Session()" to operate them - stored in shared memory
or cache storage (PHP-APC cache can provide this, see
http://www.php.net/manual/en/book.apc.php)
(Top posting fixed)
A very bad idea. Object id's are only unique to the current script -
not across scripts.
An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
Actually, objects do have resource id's. You just normally don't see
them. But I was referring to user-defined id's, based on your previous
comments. They are, however, still not unique across sessions.
> So now you have multiple objects with the same id
in shared memory.
is not true.
> Additionally, you will need to keep some catalog of
what's in shared memory. And using shared memory would be very insecure.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.
Which again is a very bad idea. Session files are relatively secure.
APC cache is very insecure.
Plus now you're taking memory from the rest of the system. While it
could speed up this application, it can also slow down the entire
system, depending on how much you use. You also have to be concerned
that the memory gets cleaned up properly (what happens if you put
something in it but the user never progresses to the next page?). That
requires more work - which cuts into the script performance.
Your answer is not a good one at all. There are many more problems with
it than it solves.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Sep 2, 8:36*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
*You can store IDs instead of real objects in session, and have a
*function like "Load_Object_From_Session()" and
*"Save_Object_To_Session()" to operate them - stored in shared memory
*or cache storage (PHP-APC cache can provide this, see
*>http://www.php.net/manual/en/book.apc.php)
(Top posting fixed)
A very bad idea. *Object id's are only unique to the current script -
not across scripts.
An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
Actually, objects do have resource id's. *You just normally don't see
them. *But I was referring to user-defined id's, based on your previous
comments. *They are, however, still not unique across sessions.
As I said it's up to the OP to implement an unique ID across sessions.
I'm NOT telling him the details - but only a direction.
>
*So now you have multiple objects with the same id
in shared memory.
is not true.
*Additionally, you will need to keep some catalog of
what's in shared memory. *And using shared memory would be very insecure.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.
Which again is a very bad idea. *Session files are relatively secure.
APC cache is very insecure.
ROFL!
You do know PHP session files are stored as plain text? How could it
be any more secure than APC cache, which is also stored in temp file
in un-encrypted format?
If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
>
Plus now you're taking memory from the rest of the system. *While it
could speed up this application, it can also slow down the entire
system, depending on how much you use. *You also have to be concerned
that the memory gets cleaned up properly (what happens if you put
something in it but the user never progresses to the next page?). *That
requires more work - which cuts into the script performance.
1.Obviously you don't know about APC at all. It uses temp files just
like session.
2.Memory cache systems like memcache always provide some kind of
expiration/cleanup mechanism.
>
Your answer is not a good one at all. *There are many more problems with
it than it solves.
Your opinions on my answer are quite funny :P
Your "problems" are the problems encountered when somone tries to
implement the cache system by himself - but I'm NOT telling him to do
this. Just pick up some existing cache system - and if it has any of
the problems you mentioned, find another one.
AqD wrote:
On Sep 2, 8:36 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
You can store IDs instead of real objects in session, and have a
function like "Load_Object_From_Session()" and
"Save_Object_To_Session()" to operate them - stored in shared memory
or cache storage (PHP-APC cache can provide this, see
>http://www.php.net/manual/en/book.apc.php)
(Top posting fixed)
A very bad idea. Object id's are only unique to the current script -
not across scripts.
An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
Actually, objects do have resource id's. You just normally don't see
them. But I was referring to user-defined id's, based on your previous
comments. They are, however, still not unique across sessions.
As I said it's up to the OP to implement an unique ID across sessions.
I'm NOT telling him the details - but only a direction.
>>> So now you have multiple objects with the same id
in shared memory.
is not true.
Additionally, you will need to keep some catalog of
what's in shared memory. And using shared memory would be very insecure.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.
Which again is a very bad idea. Session files are relatively secure.
APC cache is very insecure.
ROFL!
You do know PHP session files are stored as plain text? How could it
be any more secure than APC cache, which is also stored in temp file
in un-encrypted format?
Because you obviously don't understand how things work. The user
doesn't directly read/write to the session file like he does the APC
cache. Any process can easily screw up the APC cache. It takes work to
do it in the session file.
I didn't say session files were secure. I said APC cache is much less
secure - and I stand by my statement.
If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
>Plus now you're taking memory from the rest of the system. While it
could speed up this application, it can also slow down the entire
system, depending on how much you use. You also have to be concerned
that the memory gets cleaned up properly (what happens if you put
something in it but the user never progresses to the next page?). That
requires more work - which cuts into the script performance.
1.Obviously you don't know about APC at all. It uses temp files just
like session.
2.Memory cache systems like memcache always provide some kind of
expiration/cleanup mechanism.
Yes, I do know about APC. And it also uses memory. Plus, you have to
figure out just when to expire the cache. And all kinds of other
things. And BTW - it is also slower than sessions.
In this case, APC cache is a solution looking for a problem.
>Your answer is not a good one at all. There are many more problems with
it than it solves.
Your opinions on my answer are quite funny :P
Your "problems" are the problems encountered when somone tries to
implement the cache system by himself - but I'm NOT telling him to do
this. Just pick up some existing cache system - and if it has any of
the problems you mentioned, find another one.
You are so hung up on APC cache that you don't recognize its limitations.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
On Sep 5, 7:39*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 2, 8:36 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
*You can store IDs instead of real objects in session, and have a
*function like "Load_Object_From_Session()" and
*"Save_Object_To_Session()" to operate them - stored in shared memory
*or cache storage (PHP-APC cache can provide this, see
*>http://www.php.net/manual/en/book.apc.php)
(Top posting fixed)
A very bad idea. *Object id's are only unique to the current script -
not across scripts.
An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
Actually, objects do have resource id's. *You just normally don't see
them. *But I was referring to user-defined id's, based on your previous
comments. *They are, however, still not unique across sessions.
As I said it's up to the OP to implement an unique ID across sessions.
I'm NOT telling him the details - but only a direction.
>>*So now you have multiple objects with the same id
in shared memory.
is not true.
*Additionally, you will need to keep some catalog of
what's in shared memory. *And using shared memory would be very insecure.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.
Which again is a very bad idea. *Session files are relatively secure..
APC cache is very insecure.
ROFL!
You do know PHP session files are stored as plain text? How could it
be any more secure than APC cache, which is also stored in temp file
in un-encrypted format?
Because you obviously don't understand how things work. *The user
doesn't directly read/write to the session file like he does the APC
cache. *Any process can easily screw up the APC cache. *It takes workto
do it in the session file.
I didn't say session files were secure. *I said APC cache is much less
secure - and I stand by my statement.
So? Why would this be a problem? Any process can write to session
storage too.
>
If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
Plus now you're taking memory from the rest of the system. *While it
could speed up this application, it can also slow down the entire
system, depending on how much you use. *You also have to be concerned
that the memory gets cleaned up properly (what happens if you put
something in it but the user never progresses to the next page?). *That
requires more work - which cuts into the script performance.
1.Obviously you don't know about APC at all. It uses temp files just
like session.
2.Memory cache systems like memcache always provide some kind of
expiration/cleanup mechanism.
Yes, I do know about APC. *And it also uses memory. *Plus, you have to
figure out just when to expire the cache. *And all kinds of other
things. *And BTW - it is also slower than sessions.
Session isn't slower or faster. Session is the API not implemetation.
The point of using cache rather than session and to setup expiration
information etc, is simply because it's more flexible - because it's
not bound by session scope.
And it doesn't have to be APC cache.
>
In this case, APC cache is a solution looking for a problem.
Then the OP could replace APC cache with other cache systems.
>
Your answer is not a good one at all. *There are many more problems with
it than it solves.
Your opinions on my answer are quite funny :P
Your "problems" are the problems encountered when somone tries to
implement the cache system by himself - but I'm NOT telling him to do
this. Just pick up some existing cache system - and if it has any of
the problems you mentioned, find another one.
You are so hung up on APC cache that you don't recognize its limitations.
It's true I don't recognize its limitations. But my suggestion is to
tell him to use some cache system. It doesn't have to be APC. And all
the problems you mentioned don't matter.
AqD wrote:
On Sep 5, 7:39 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
>>On Sep 2, 8:36 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
AqDwrote:
On Sep 1, 8:46 pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>AqDwrote:
> You can store IDs instead of real objects in session, and have a
> function like "Load_Object_From_Session()" and
> "Save_Object_To_Session()" to operate them - stored in shared memory
> or cache storage (PHP-APC cache can provide this, see
> >http://www.php.net/manual/en/book.apc.php)
>(Top posting fixed)
>A very bad idea. Object id's are only unique to the current script -
>not across scripts.
An object itself has no ID. It's up to him to decide what the ID
should be (he has to implement the Save/Load functions by himself).
The uniqueness depends on his implementation.
Actually, objects do have resource id's. You just normally don't see
them. But I was referring to user-defined id's, based on your previous
comments. They are, however, still not unique across sessions.
As I said it's up to the OP to implement an unique ID across sessions.
I'm NOT telling him the details - but only a direction.
> So now you have multiple objects with the same id
>in shared memory.
is not true.
> Additionally, you will need to keep some catalog of
>what's in shared memory. And using shared memory would be very insecure.
1.He can use APC cache instead of dealing shared memory by himself.
2.Shared memory or APC cache can only be as insecure as data in
session files or databases. It doesn't matter.
Which again is a very bad idea. Session files are relatively secure.
APC cache is very insecure.
ROFL!
You do know PHP session files are stored as plain text? How could it
be any more secure than APC cache, which is also stored in temp file
in un-encrypted format?
Because you obviously don't understand how things work. The user
doesn't directly read/write to the session file like he does the APC
cache. Any process can easily screw up the APC cache. It takes work to
do it in the session file.
I didn't say session files were secure. I said APC cache is much less
secure - and I stand by my statement.
So? Why would this be a problem? Any process can write to session
storage too.
>>If he needs security, he could implement an encryption layer - it's as
easy as to make one for session.
Plus now you're taking memory from the rest of the system. While it
could speed up this application, it can also slow down the entire
system, depending on how much you use. You also have to be concerned
that the memory gets cleaned up properly (what happens if you put
something in it but the user never progresses to the next page?). That
requires more work - which cuts into the script performance.
1.Obviously you don't know about APC at all. It uses temp files just
like session.
2.Memory cache systems like memcache always provide some kind of
expiration/cleanup mechanism.
Yes, I do know about APC. And it also uses memory. Plus, you have to
figure out just when to expire the cache. And all kinds of other
things. And BTW - it is also slower than sessions.
Session isn't slower or faster. Session is the API not implemetation.
The point of using cache rather than session and to setup expiration
information etc, is simply because it's more flexible - because it's
not bound by session scope.
And it doesn't have to be APC cache.
>In this case, APC cache is a solution looking for a problem.
Then the OP could replace APC cache with other cache systems.
>>>Your answer is not a good one at all. There are many more problems with
it than it solves.
Your opinions on my answer are quite funny :P
Your "problems" are the problems encountered when somone tries to
implement the cache system by himself - but I'm NOT telling him to do
this. Just pick up some existing cache system - and if it has any of
the problems you mentioned, find another one.
You are so hung up on APC cache that you don't recognize its limitations.
It's true I don't recognize its limitations. But my suggestion is to
tell him to use some cache system. It doesn't have to be APC. And all
the problems you mentioned don't matter.
They don't matter to you because you're so hung up on your cache that
you don't recognize the problems and limitations involved.
Sessions are used by millions of programmers - simply because they work
so well. I'm not saying they are the end-all to all problems. But they
work much better than trying to implement some crazy caching scheme.
The code is already built, tested, debugged and working. And it works well.
You can't say the same about caching mechanisms.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Christoph Nothdurfter |
last post by:
Hallo!
I was wondering if my PHP4-Scripts will run under PHP5 (Haeven't tried the
beta yet).
Does anybody know?
Thank you,
-Christoph
|
by: Chung Leong |
last post by:
Help me here. I've become a bitconfused about how PHP4 deals with
objects after reading this description of PHP5:
"PHP's handling of objects has been completely rewritten, allowing for
better...
|
by: Rob Ristroph |
last post by:
I have tried out PHP 5 for the first time (with assistance from this
group -- thanks!).
The people I was working with have a site that uses lots of php
objects. They are having problems with...
|
by: Daniel Andersen |
last post by:
Hey,
We are in the process of rewriting our internal management system (which was
written in PHP4), and figured this would be a good time to migrate to PHP5
to get all the OO goodness it has to...
|
by: Mathieu Maes |
last post by:
Hi there
I'm quite experienced in programming in PHP4, but I would like to make
a step to PHP5.
I created following class which works perfectly in PHP4 :
Class Nessi
{
// ident part
|
by: Dave |
last post by:
I have multiple forms that will create an object. Basically a energy
efficiency measure object. The measure object will have a couple of
required properties set but after that it can have 10-20...
|
by: ink |
last post by:
Hi all,
I am trying to pull some financial data off of an HTML web page so that I
can store it in a Database for Sorting and filtering.
I have been thinking about this for some time and trying...
|
by: FFMG |
last post by:
Hi,
I am slowly moving my code to php5.
But I would like to make it backward compatible in case something bad
happens, (and to make sure I understand what the changes are).
The way the...
|
by: Logos |
last post by:
I have what may be a bug, or may be a misunderstanding on how pass by
reference and class inheritance works in PHP. Since I'm relatively
new to PHP, I'm hoping for a little outside help to shed...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
