php-general Digest 23 Jan 2005 13:38:26 -0000 Issue 3244

Topics (messages 207061 through 207076):

Re: php5 --enable-soap compile error
        207061 by: Marten Lehmann

Re: Why no type hints for built-in types?
        207062 by: Rasmus Lerdorf
        207067 by: Matthew Weier O'Phinney
        207074 by: Terje Sletteb�

Geographical tendancies with RemoteHost
        207063 by: John Taylor-Johnston
        207076 by: Jochem Maas

wiki as php object?
        207064 by: Kurt Yoder
        207065 by: Matthew Weier O'Phinney

Re: Why is access and visibility mixed up in PHP?
        207066 by: Matthew Weier O'Phinney
        207075 by: Terje Sletteb�

Re: Loading all clases always
        207068 by: Matthew Weier O'Phinney

Re: Procedural to OOP
        207069 by: Matthew Weier O'Phinney

Re: Extending a Class
        207070 by: Matthew Weier O'Phinney

Session errors when uploaded to host
        207071 by: Tim Burgan
        207073 by: Burhan Khalid

library manger ..
        207072 by: gowthaman ramasamy

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 ---
Note:

the problem seems to start a bit earlier:

gcc -Iext/soap/ -I/usr/src/redhat/BUILD/php-5.0.3/ext/soap/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php-5.0.3/include -I/usr/src/redhat/BUILD/php-5.0.3/main -I/usr/src/redhat/BUILD/php-5.0.3 -I/usr/src/redhat/BUILD/php-5.0.3/Zend -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/usr/kerberos/include -I/usr/src/redhat/BUILD/php-5.0.3/ext/mbstring/oniguruma -I/usr/src/redhat/BUILD/php-5.0.3/ext/mbstring/libmbfl -I/usr/src/redhat/BUILD/php-5.0.3/ext/mbstring/libmbfl/mbfl -I/vrmd/webserver/mhash/include -I/usr/include/mysql -I/usr/include/pspell -I/usr/src/redhat/BUILD/php-5.0.3/TSRM -I/usr/kerberos/include -c /usr/src/redhat/BUILD/php-5.0.3/ext/soap/soap.c -o ext/soap/soap.o && echo > ext/soap/soap.lo
gcc -Iext/soap/ -I/usr/src/redhat/BUILD/php-5.0.3/ext/soap/ -DPHP_ATOM_INC -I/usr/src/redhat/BUILD/php-5.0.3/include -I/usr/src/redhat/BUILD/php-5.0.3/main -I/usr/src/redhat/BUILD/php-5.0.3 -I/usr/src/redhat/BUILD/php-5.0.3/Zend -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/usr/kerberos/include -I/usr/src/redhat/BUILD/php-5.0.3/ext/mbstring/oniguruma -I/usr/src/redhat/BUILD/php-5.0.3/ext/mbstring/libmbfl -I/usr/src/redhat/BUILD/php-5.0.3/ext/mbstring/libmbfl/mbfl -I/vrmd/webserver/mhash/include -I/usr/include/mysql -I/usr/include/pspell -I/usr/src/redhat/BUILD/php-5.0.3/TSRM -I/usr/kerberos/include -c /usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c -o ext/soap/php_encoding.o && echo > ext/soap/php_encoding.lo
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c: In function `to_zval_string':
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c:498: warning: initialization makes pointer from integer without a cast
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c: In function `to_zval_stringr':
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c:534: warning: initialization makes pointer from integer without a cast
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c: In function `to_zval_stringc':
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c:570: warning: initialization makes pointer from integer without a cast
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c: In function `to_xml_string':
/usr/src/redhat/BUILD/php-5.0.3/ext/soap/php_encoding.c:638: warning: initialization makes pointer from integer without a cast

--- End Message ---
--- Begin Message --- Terje Sletteb� wrote:
I don't find this answer satisfactory. Yes, PHP has loose/weak typing, but
at any one time, a value or a variable has a distinct type. In the example
in the quote above, you'd have to ensure that the value you pass is of the
right type.

Well, like it or not, that is the way it is. PHP is first and foremost a web scripting language. Browsers don't send a type along with each bit of information they send. Everything comes across as a string and as such all the internal PHP functions do the right thing when you pass a string to a function that really takes a number. We have no plans to break this and create an inconsistent set of functions that no longer do this.


-Rasmus
--- End Message ---
--- Begin Message ---
* Terje Sletteb� <[EMAIL PROTECTED]>:
> In PHP5, you can provide "type hints" for functions, like this:
>
> class Person {...}
>
> function f(Person $p)
> {
>   ...
> }
>
> Since this is optional static typing for objects, why not make the same
> capability available for all types, built-in types included?
>
> I come from a background with generally static and strong typing (C++,
> Java), and having worked with PHP a couple of years, I've quite a few times
> got bitten by stupid bugs that could have been caught by static typing, such
> as passing an empty string - which gets converted to 0 in an arithmetic
> context, when the function was supposed to receive a number, or some such,
> and no error is reported. These bugs can be hard to find.

This is where the === and !== comparison operators can come in handy, as
they compare not only the values but the types. I often need to do this
when checking for zeroes.

> This has been suggested in a few Q & A's at Zend, such as this one:
> http://www.zend.com/expert_qa/qas.php?id=104&single=1
>
> --- Start quote ---
>
> Will be a support for type hints of simple types, like
> class Foo{
>     public function bar(int $var) {    }
> }
>
>     No, type hints of simple types will not be supported. The reason is
> PHP's dynamic nature. A number posted to a script will arrive as a string
> even though it's a number. In this case, PHP assumes that "10" and 10 are
> the same thing. Having such type hints would not fit into this
> auto-conversion of PHP.
>
> --- End quote ---
>
> I don't find this answer satisfactory. Yes, PHP has loose/weak typing, but
> at any one time, a value or a variable has a distinct type. In the example
> in the quote above, you'd have to ensure that the value you pass is of the
> right type.

I can recognize that this answer would not be satisfactory for someone
with a background in traditional application architecture. However, PHP
has been developed from the beginning as a programming language for the
web. Since the nature of web requests is to transfer all values as
strings, PHP needs to be able to compare items of different types -- '0'
needs to evaluate to the same thing as 0. This may not be optimal for
many applications, but for most web applications to which PHP is
applied, it is considered a *feature*.

> This would also open the door to overloading, although it seems from the
> replies from Andi and Zeev in the Zend forums that neither optional static
> typing, nor overloading is considered at this time, and likely not in the
> future, either. :/ What I have seen of arguments against it, I haven't found
> sufficiently convincing, so therefore I'd like to hear about the pros and
> cons of optional static typing, and possibly overloading (however, that
> should really be a separate thread). What the PHP manual calls "overloading"
> has really nothing to do with the concept of overloading in other OO
> languages, such as C++/Java.

PHP already supports overloading as you're accustomed to it -- the
syntax is different, and PHP refers to the practice as "variable-lentgh
argument lists". You use func_num_args(), func_get_args(), and
func_get_arg() to accomplish it:

function someOverloadedFun()
{
    $numargs = func_num_args();
    $args    = func_get_args();
    if (0 == $numargs) {
        return "ERROR!";
    }
    if (1 == $numargs) {
        if (is_string($args[0])) {
            return "Received string: $args[0]";
        } elseif (is_object($args[0])) {
            return "Received object!";
        }
    } elseif ((2 == $numargs)) {
        return "Received arg0 == $args[0] and arg1 == $args[1]";
    }
    // etc.
}

Yes, this is more cumbersome than providing hints -- but typically, if I
design properly, I'm checking types within already, and I've already
determined a way to limit what is passed to the function/method. One
technique I use is to pass a single associate array to a function or
method, and grab my arguments from that. 

> There's a rather lively discussion about adding optional static typing in
> Python (http://www.artima.com/weblogs/viewpost.jsp?thread=85551), and unless
> it has already been, maybe it's time for us to consider it for PHP, as well.
> The current static type checking in PHP5 is something rather half-baked,
> only covering user-defined types.

I can definitely see a use for this -- but, again, PHP has been designed
with loose typing as a *feature*. While type hinting may be a nice
additional feature, I have my doubts as to the necessity or overhead it
would incur.

-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
> Terje Sletteb� wrote:
> > I don't find this answer satisfactory. Yes, PHP has loose/weak typing,
but
> > at any one time, a value or a variable has a distinct type. In the
example
> > in the quote above, you'd have to ensure that the value you pass is of
the
> > right type.
>
> Well, like it or not, that is the way it is.  PHP is first and foremost
> a web scripting language.  Browsers don't send a type along with each
> bit of information they send.  Everything comes across as a string and
> as such all the internal PHP functions do the right thing when you pass
> a string to a function that really takes a number.  We have no plans to
> break this and create an inconsistent set of functions that no longer do
> this.

Thanks for your reply. I can understand the reasoning for that. However,
what the request was about was _optional_ explicit typing; the standard
library didn't have to use it at all, but it would be available to users.
Many places in a web application pass values between functions, where the
type is well-known (i.e. not directly from a browser).

Nevertheless, I assume the official answer is the same, and I understand it,
if this is not a reasonably commonly requested feature.

Regards,

Terje

--- End Message ---
--- Begin Message ---
With my counter, I track RemoteHost and IPAddress and save it in a mysql table. 
One of my colleagues asked me these questions (below).
I can track number of hits per month. Is there any OS code anywhere that I 
might implement to see geographical tendencies?

John

>Is it possible to track this as a statistical graph that gives us average
>hits per month over a longer period? This would be useful for further grant
>applications. Also of course if we could track hits per rough geographical
>regions (i.e. Quebec, Canada, North America, Latin America, Europe, Other).
>Is this doable without too much effort?

--- End Message ---
--- Begin Message --- John Taylor-Johnston wrote:
With my counter, I track RemoteHost and IPAddress and save it in a mysql table. 
One of my colleagues asked me these questions (below).
I can track number of hits per month. Is there any OS code anywhere that I 
might implement to see geographical tendencies?

John


Is it possible to track this as a statistical graph that gives us average
hits per month over a longer period? This would be useful for further grant
applications. Also of course if we could track hits per rough geographical
regions (i.e. Quebec, Canada, North America, Latin America, Europe, Other).
Is this doable without too much effort?

php.net (can) redirect requests to the 'nearest' mirror based on your IP. to find out how they do this you might start by reading this source file:


http://www.php.net/source.php?url=/include/ip-to-country.inc

hint: they use data from http://www.ip-to-country.com/

hope that give you an idea, good luck




--- End Message ---
--- Begin Message ---
Hi folks

I am creating a php site that will eventually include a wiki. The twist is that visitors to my site will each be able to create their own sections. Each section should have its own wiki, completely independent of all the other wikis. I could of course code up my own wiki from scratch, but would prefer not to have to re-invent the wheel.

I have found many wiki implementations that are "full-blown" applications. Has anyone seen a wiki implementation that is more "integration friendly"? Ideally, a wiki could be created, accessed, and displayed as an object so that I could completely encapsulate it within my own code. This would give me complete control over url's, look and feel, etc.

Anyone have any suggestions?

--

Kurt Yoder
http://yoderhome.com

--- End Message ---
--- Begin Message ---
* Kurt Yoder <[EMAIL PROTECTED]>:
> I am creating a php site that will eventually include a wiki. The twist 
> is that visitors to my site will each be able to create their own 
> sections. Each section should have its own wiki, completely independent 
> of all the other wikis. I could of course code up my own wiki from 
> scratch, but would prefer not to have to re-invent the wheel.
>
> I have found many wiki implementations that are "full-blown" 
> applications. Has anyone seen a wiki implementation that is more 
> "integration friendly"? Ideally, a wiki could be created, accessed, and 
> displayed as an object so that I could completely encapsulate it within 
> my own code. This would give me complete control over url's, look and 
> feel, etc.

PEAR's Text_Wiki class can be used to do the WikiText -> HTML
translation (and vice versa); it wouldn't be difficult to write an
object around that class to handle storage and data retrieval. (I've
actually been planning on something like that for use with my
Cgiapp.class.php project -- http://freshmeat.net/projects/cgiapp).

Other than that -- the only PHP-based wikis I've seen all act as their
own application and are not encapsulation friendly.

-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
* Terje Sletteb� <[EMAIL PROTECTED]>:
> (I've posted this to the PHP newsgroups, as well, but as many here might not
> read them, I post here, as well. I hope that's not considered "overboard",
> and if so, please let me know)

The newsgroups are simply an NNTP interface to the mailing lists -- use
one or the other; either way, it gets to the same place.

> Today, I worked on an implementation of a finite state machine. 
<snip>
> The base class defines some
> (virtual) functions that may be overridden in a derived class, but they are
> only called from the base class. My original code was as follows
<snip>:
>
<snip -- class with private method, subclass with private method>
>
> In C++ this would work just fine: As null_action() is called from fsm, and
> it's private in fsm, this works fine. It gets overridden in my_fsm, but
> being private in fsm, it can only be called there (not in my_fsm), which is
> as intended. This is because access and visibility are orthogonal concepts
> in C++: The access specifiers only specify who are allowed to access (as in
> calling, taking the address of, etc.) a function, but it doesn't affect
> overriding.
>
> The reason for this is as follows (from "The Design and Evolution of C++"):
> By not letting the access specifiers affect visibility (including
> overriding), changing the access specifiers of functions won't affect the
> program semantics.
>
> However, this is not so for PHP...
>
> The above won't work, or at least not work as intended: The function
> null_action() will only be visible in the class it's defined, and therefore
> the derived class version won't override the base class version. In order to
> get it to work, the access specifiers have to be changed to protected. This
> means that derived classes may also _call_ the function, something that is
> not desired. This means I can't enforce this design constraint of having
> this function private.
>
> Why is it done like this?

I'm not sure why the behaviour is as it is, but I do know that PHP
developers were heavily influenced by Java when writing the new PHP5
object model; I suspect your answers may lie there. 

One question I have to ask of you: why would you want the derived class
to be able to know a method exists if it will not be able to call it?
This seems to me to be... well, silly. Either the method is available to
the class or it isn't and/or the method is available to an instantiated
object or it isn't; visibility as being orthagonal to access just
doesn't make a lot of sense to me. Perhaps you could make a case as to
when this would be beneficial?

You might also want to take some of your questions to the php-dev list
-- they seem to be more related to the internals of PHP than PHP usage.

-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
>From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>

> * Terje Sletteb� <[EMAIL PROTECTED]>:
> > (I've posted this to the PHP newsgroups, as well, but as many here might
not
> > read them, I post here, as well. I hope that's not considered
"overboard",
> > and if so, please let me know)
>
> The newsgroups are simply an NNTP interface to the mailing lists -- use
> one or the other; either way, it gets to the same place.

Ah, thanks. Sorry for the double-posts, then.

> <snip -- class with private method, subclass with private method>
> >
> > The above won't work, or at least not work as intended: The function
> > null_action() will only be visible in the class it's defined, and
therefore
> > the derived class version won't override the base class version. In
order to
> > get it to work, the access specifiers have to be changed to protected.
This
> > means that derived classes may also _call_ the function, something that
is
> > not desired. This means I can't enforce this design constraint of having
> > this function private.
> >
> > Why is it done like this?
>
> I'm not sure why the behaviour is as it is, but I do know that PHP
> developers were heavily influenced by Java when writing the new PHP5
> object model; I suspect your answers may lie there.

Yes, I think so, too, and I thought of that, as well. I think it does
something similar. I checked now: yep, it does the same there.

> One question I have to ask of you: why would you want the derived class
> to be able to know a method exists if it will not be able to call it?
> This seems to me to be... well, silly. Either the method is available to
> the class or it isn't and/or the method is available to an instantiated
> object or it isn't; visibility as being orthagonal to access just
> doesn't make a lot of sense to me. Perhaps you could make a case as to
> when this would be beneficial?

I realise that it may seem counter-intuitive or strange, but in this case it
actually makes sense: To take a practical example: A stopwatch FSM (example
from boost::fsm
(http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost-sandbox/boost-sandbo
x/libs/fsm/doc/index.html?content-type=text%2Fplain&rev=1.31)). Here's a
complete, working example (except for the fsm class):

--- Start code ---

include_once("fsm.php");

// States (nested classes are not supported, so these must be at global
scope)

class active {}
class running extends active {}
class stopped extends active {}

class stopwatch_fsm extends fsm
{
  public function stopwatch_fsm()
  {
    $this->fsm("stopped"); // Initial state
    $this->add_transitions($this->transitions);
  }

  protected function start($from_state,$to_state)
  {
    echo "Start stopwatch<br>";
  }

  protected function stop($from_state,$to_state)
  {
    echo "Stop stopwatch<br>";
  }

  protected function reset($from_state,$to_state)
  {
    echo "Reset stopwatch<br>";
  }

  private $transitions=array(
    //    <signal>, <state>, <new state>, <action>
    array("Start/stop button", "stopped", "running","start"),
    array("Start/stop button", "running", "stopped","stop"),
    array("Reset button", "active", "stopped","reset"));
}

--- End code ---

To explain the above:  The FSM stopwatch_fsm contains a state "active", with
two nested states "running" and "stopped". These are modelled as classes.
The transitions between the states are defined in the above array, each line
gives a signal/initial state/final state/action for a transition. For
example, if it's in the "stopped" state, and receives a "Start/stop button"
signal, it transitions to the "running" state, and calls the start() member
function. Same for the other two defined transitions.

Test program:

include_once("stopwatch_fsm.php");

$test=new stopwatch_fsm();

$test->process("Start/stop button");
$test->process("Start/stop button");
$test->process("Start/stop button");
$test->process("Reset button");

This will print:

Start stopwatch
Stop stopwatch
Start stopwatch
Reset stopwatch

The idea is that fsm will, upon doing state transitions, call the
appropriate action functions, as member functions (here, start/stop/reset),
so these have to be defined in the derived class. Interestingly, this
actually works even if start/stop/reset are _not_ defined in the base class,
fsm (!)

I seem to have talked myself into a corner. :) As these functions are not
defined in the base class, they are _not_ overridden in the derived class;
they are merely defined there. The example I had in the original posting was
a member function that _was_ defined in the base class, and overridden in
the derived class ("null_action"). This is the member function that gets
called, if no specific action function is provided in the transition table.

In _that_ example, the derived class would need to be able to override it,
but need not be able to call it (as it's called by the base class).

I hope this makes some kind of sense... :)

(By the way, besides pear::fsm, this is also inspired by the mentioned
boost::fsm, which also uses classes to model states)

> You might also want to take some of your questions to the php-dev list
> -- they seem to be more related to the internals of PHP than PHP usage.

Ah, I didn't know about that one. I didn't find it here:
http://www.php.net/mailing-lists.php How can I subscribe to it?

Regards,

Terje

P.S. Why does replies to list posting go to the sender, rather than the
list, by default? Shouldn't reply-to be set to the list, as usual? I had to
manually edit the address, to make the reply go to the list.

--- End Message ---
--- Begin Message ---
* Chris <[EMAIL PROTECTED]>:
> You may want to look at the PHP 5 __autoload function:
>
> http://www.php.net/oop5.autoload

These are semi-available in PHP4 as well -- look up 'overload' in the
function reference.

> I know it's not the answer to your question, but it could be just as 
> good, or better, than what you were looking for.

The OP might also want to look up the INI variable 'auto_prepend_file'
if they really *do* want to load all classes on each page call -- this
would eliminate the need to modify all scripts in the web tree. It could
also be used with the overload/__autoload functions (PHP4 or PHP5) --
the auto_prepend_file could contain the __autoload function definition.

> Ben Edwards (lists) wrote:
> > I have all my classes in a single directory.  I was thinking of
> > automatically loading them all at the beginning of every page.  The
> > logic being that the class definitions will get cached (I guess PHP uses
> > filesize/date/time) so the overhead would not be that great.  Also at
> > any given time they will all probably be needed by one of the visitors.

-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
* Mike Smith <[EMAIL PROTECTED]>:
> I am rewriting a project, and have decided to use/learn OOP. I am
> using ADODB to connect to a MS SQL 2000 box. This code works, but I'd
> like to know if I'm following good form or if I'm totally missing the
> boat. I'd also like to include things like the
> dbhost/username/password, etc in a seperate config file would I...
>
> class foo{
>
> function bar(){
> include('my_config_file_here.php');// sets $dbhost etc...
>
> var $db_host = $dbhost;
> ...
> }
> }
>
> ...or is there another way.

I do the same thing... but only for areas that I consider static.
Otherwise, I pass the DSN in as a parameter to the object constructor --
and even then, I'm having it defined from a function that's in a file
outside my document root:

In Foo.class.php:

    require_once 'DB.php';
    class foo 
    {
        function foo($dsn)
        {
            // I use PEAR, so this is how I connect to a DB:
            $db =& DB::connect($dsn);
            $this->db =& $db;
        }
    }

In instance script:

    require_once 'Foo.class.php';
    require_once 'connection.php'; // this file is in the include path,
        // but not in the web tree

    $foo = new Foo(connectionFunc());

> Here is my class and my index.php which will present it. I looked at
> Smarty, but I think my head would explode trying to link
> ADODB-OOP-SMARTY. 

It's actually not difficult at all to connect ADODB/PEAR::DB to Smarty,
believe it or not. You pass resultsets directly to Smarty, and then use
Smarty's foreach or section constructs to loop over them. Once you do
that, I think you'll find your code becomes cleaner, and you have less
disconnect as you work in PHP (I often had disconnect when intermingling
HTML and PHP from trying to switch back and forth between the languages;
moving to a templating system was a huge productivity boost, as when you
work in a template, you use HTML; when you work in a script/class, you
use PHP).

-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
* Phillip S. Baker <[EMAIL PROTECTED]>:
> Thank you,
>
> This makes allot of sense.
> However one last question about this.
>
> If I access the overrided function from the child class do I access it by.
>
> $instanceofchildclass->parent::someMethod();
>
> OR would I still simply just call it
>
> $instanceofchildclass->someMethod();
>
> And it would get to use the overrided function in the child class??

The child class (assuming it has overridden a method) would access the
original method in the parent with:

    parent::someMethod();

If the child class wishes to access the method it has overridden (i.e.,
it wants to access its own method, not the parent's), it uses:

    $this->someMethod();

The object *instance* only gets to access the overridden method (assuming
it's an instance of the child class):

    $instance->someMethod();

-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
Hello,


I've developed my site, and tested on a web host (Apache, PHP 4.3.9).
Now I've uploaded to a different host (IIS, PHP 4.3.1) where I want to keep it, and I get session error messages like:


Warning: session_start() [function.session-start <http://www.php.net/function.session-start>]: open(/tmp\sess_30f6794de4b0d80b91035c6c01aae52d, O_RDWR) failed: No such file or directory (2) in E:\W3Sites\ywamsa\www\timburgan\index.php on line 9

Warning: session_start() [function.session-start <http://www.php.net/function.session-start>]: Cannot send session cookie - headers already sent by (output started at E:\W3Sites\ywamsa\www\timburgan\index.php:9) in E:\W3Sites\ywamsa\www\timburgan\index.php on line 9


My code on line 9 is: This is the first line of my code session_start();

My code on line 12 is: This is the second line of my code
header("Cache-control: private");


Is there any solution to this? Tim



PS. I looked up session_start() in the PHP manual, and found this comment that may offer a solution that I've pasted below. Will this work? Are my problems a bug with PHP and IIS?

[START QUOTE]
*tech at insights dot net dot au*
17-Oct-2004 04:28

|I am sure anybody that is trying to use IIS and PHP is throughly annoyed with the session_start() bug that recreates a new session every time it is accessed.

The problem is the session_id isn't passed before the session_start() so it creates a new session. So a simple sollution is:

$id = 473483478383834;
session_id($id);
session_start();

Another way that is a bit more dynamic using a Cookie to hold the session_id:

if (isset($SessID)){ session_id($SessID); }
session_start();
header("Cache-control: private"); // IE 6 Fix.
setcookie("SessID", session_id(), time() + 3600);


There are probably much better ways of doing this but for use with my offline Win/IIS setup it seems to be fine.

[END QUOTE]
|

--- End Message ---
--- Begin Message --- Tim Burgan wrote:
Hello,


I've developed my site, and tested on a web host (Apache, PHP 4.3.9).
Now I've uploaded to a different host (IIS, PHP 4.3.1) where I want to keep it, and I get session error messages like:


Warning: session_start() [function.session-start <http://www.php.net/function.session-start>]: open(/tmp\sess_30f6794de4b0d80b91035c6c01aae52d, O_RDWR) failed: No such file or directory (2) in E:\W3Sites\ywamsa\www\timburgan\index.php on line 9

Warning: session_start() [function.session-start <http://www.php.net/function.session-start>]: Cannot send session cookie - headers already sent by (output started at E:\W3Sites\ywamsa\www\timburgan\index.php:9) in E:\W3Sites\ywamsa\www\timburgan\index.php on line 9


The problem is that the php installation on this server is not configured correctly. It still holds the default session location (/tmp) which doesn't exist on Windows PCs.


You need to ask the server administrator to verify the PHP installation and point the session location directory to a valid location on the server.
--- End Message ---
--- Begin Message ---
Hi list,
can any one suggest a good PHP/mysql based library manager to manage
books,magazines, documents, cds etc ..... 
I tried libman .. but i am having problem with that .....
many thanks in advance ...
with love
gowtham

--- End Message ---

Reply via email to