[PHP-DEV] CVS Account Request: flex
Helping (active development) with ext/xslt extension (sablot backend). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] xslt sablot backend
Hello,
Two problems with sablot support in PHP 4.1.2 (and propably later releases).
1) This patch makes xslt/sablot to work with libsablot = 0.90 and also
makes it incompatible with earlier sablotron releases. This fix might be in
HEAD already (at least it seems so), but please include this with next
minor release since anything 0.90 is too damn old if we are talking about
sablotron.
2) Added a lot of if(retval) checks to avoid segfaults when user specified
callback doesn't exist. Right now after module issues warning it segfaults
when trying to zval_ptr_dtor(retval) because that retval isn't actually
allocated when specified function doesn't exist.
This patch is against 4.1.2 source.
Thanks,
Lenar
--- sablot.c.old Sat May 11 12:10:49 2002
+++ sablot.c Sat May 11 12:58:18 2002
-52,15 +52,15
static int scheme_close(void *, SablotHandle, int);
/* Sax handler functions */
-static SAX_RETURN sax_startdoc(void *);
-static SAX_RETURN sax_startelement(void *, const char *, const char **);
-static SAX_RETURN sax_endelement(void *, const char *);
-static SAX_RETURN sax_startnamespace(void *, const char *, const char *);
-static SAX_RETURN sax_endnamespace(void *, const char *);
-static SAX_RETURN sax_comment(void *, const char *);
-static SAX_RETURN sax_pi(void *, const char *, const char *);
-static SAX_RETURN sax_characters(void *, const char *, int);
-static SAX_RETURN sax_enddoc(void *);
+static SAX_RETURN sax_startdoc(void *, SablotHandle);
+static SAX_RETURN sax_startelement(void *, SablotHandle, const char *, const char **);
+static SAX_RETURN sax_endelement(void *, SablotHandle, const char *);
+static SAX_RETURN sax_startnamespace(void *, SablotHandle, const char *, const char *);
+static SAX_RETURN sax_endnamespace(void *, SablotHandle, const char *);
+static SAX_RETURN sax_comment(void *, SablotHandle, const char *);
+static SAX_RETURN sax_pi(void *, SablotHandle, const char *, const char *);
+static SAX_RETURN sax_characters(void *, SablotHandle, const char *, int);
+static SAX_RETURN sax_enddoc(void *, SablotHandle);
/* Error handlers */
static MH_ERROR error_makecode(void *, SablotHandle, int, unsigned short, unsigned short);
-723,12 +723,14
xslt_call_function(scheme get all, XSLT_SCHEME(handle).get_all,
3, argv, retval);
- /* Save the return value in the buffer (copying it) */
- *buffer = estrndup(Z_STRVAL_P(retval), Z_STRLEN_P(retval));
- *byte_count = Z_STRLEN_P(retval);
+ if(retval) {
+ /* Save the return value in the buffer (copying it) */
+ *buffer = estrndup(Z_STRVAL_P(retval), Z_STRLEN_P(retval));
+ *byte_count = Z_STRLEN_P(retval);
- /* Free return value */
- zval_ptr_dtor(retval);
+ /* Free return value */
+ zval_ptr_dtor(retval);
+ }
return 0;
}
-801,11 +803,13
xslt_call_function(scheme open, XSLT_SCHEME(handle).open,
3, argv, retval);
- /* Return value is a resource pointer to an open file */
- *fd = Z_LVAL_P(retval);
+ if(retval) {
+ /* Return value is a resource pointer to an open file */
+ *fd = Z_LVAL_P(retval);
- /* Free it all up */
- zval_ptr_dtor(retval);
+ /* Free it all up */
+ zval_ptr_dtor(retval);
+ }
/* return success */
return 0;
-845,11 +849,13
xslt_call_function(scheme get, XSLT_SCHEME(handle).get,
3, argv, retval);
- /* Returns the number of bytes read */
- *byte_count = Z_LVAL_P(retval);
+ if(retval) {
+ /* Returns the number of bytes read */
+ *byte_count = Z_LVAL_P(retval);
- /* Free things up */
- zval_ptr_dtor(retval);
+ /* Free things up */
+ zval_ptr_dtor(retval);
+ }
/* return success */
return 0;
-889,11 +895,13
xslt_call_function(scheme put, XSLT_SCHEME(handle).put,
3, argv, retval);
- /* The return value is the number of bytes written */
- *byte_count = Z_LVAL_P(retval);
+ if(retval) {
+ /* The return value is the number of bytes written */
+ *byte_count = Z_LVAL_P(retval);
- /* Free everything up */
- zval_ptr_dtor(retval);
+ /* Free everything up */
+ zval_ptr_dtor(retval);
+ }
/* Return success */
return 0;
-931,7 +939,8
2, argv, retval);
/* Free everything up */
- zval_ptr_dtor(retval);
+ if(retval)
+ zval_ptr_dtor(retval);
/* Return success */
return 0;
-940,7 +949,7
/* {{{ sax_startdoc()
Called when the document starts to be processed */
-static SAX_RETURN sax_startdoc(void *ctx)
+static SAX_RETURN sax_startdoc(void *ctx, SablotHandle proc)
{
zval *argv[1];/* Arguments to the sax start doc function */
zval *retval; /* Return value from sax start doc function */
-964,13 +973,15
1, argv, retval);
/* Cleanup */
- zval_ptr_dtor(retval);
+ if(retval)
+ zval_ptr_dtor(retval);
}
/* }}} */
/* {{{ sax_startelement()
Called when an element is begun to be processed */
static SAX_RETURN sax_startelement(void *ctx,
+
Re: [PHP-DEV] Re: PHP 5
Joe Webster wrote: Example: We have 200+ radio station websites in a network. The way we store data in the database is by call letters (since some websites have more than one domain). So call letters (whor-fm :) ) are the key to just about everything we do. So, in the vhost file for apache we want to set the station call letters so that the letters are available to the code. Maybe you should use SetEnv? Lenar -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #14658 Updated: The strtok() changes destroyed 4 years old applications!
[EMAIL PROTECTED] wrote: ID: 14658 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Feature/Change Request Operating System: Linux, Solaris, Windows PHP Version: 4.1.0 New Comment: We are aware of this situation, and after some discussion on the mailinglist, we will not change it back. However, to read CSV files, there is function fgetcvs (http://www.php.net/manual/en/function.fgetcsv.php) which should do exactly what you want. Derick Previous Comments: [2001-12-22 05:46:46] [EMAIL PROTECTED] The change made in 4.1.0 to strtok() destroyed my applications from the past 4 years! Thats because I used strtok() to read data from CSV (comma separated values) files - for which it works perfektly! For CSV (not only separated with commans - also with | and other symbols) it is required that EMPTY fields will be reported as empty field!!! So the change you made brokes my existing applications. Or one can use split() Lenar For parsing tokens as explained I understand the change - because there you wont need empty tokens! But for real parsing strtok is useless(!) because you always have more than one separator - for human language parsing you need space, return/line feed, full stop as well as comma, questionmark etc. as separators! strtok() fails here as it seems to me!!! So my suggestion ist - to restore the old behaviour for CSV parsing and adding a new command like strparse() that will work with a list of separators!!! Greetings Dipl.-Inform. Kai Hofmann Edit this bug report at http://bugs.php.net/?id=14658edit=1 -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #14442 Updated: Segmentation fault when using xslt_process()
($xsl, filesize(test.xsl)); $xmlc = fread($xml, filesize(test.xml)); xslt_process($pr, $xmlc, $xslc); xslt_free($pr); ? -- when i run this script, the xslt_process() command crashes the server. The gdb backtrace result is here... -- Program received signal SIGSEGV, Segmentation fault. 0x4008d044 in Situation::generateMessage (this=0x3c202020, type=1498698543, code=171853132, arg1=@0x20202020, arg2=@0x20202020, theMessage=@0x682f3c20) at situa.cpp:263 263 if (messenger !(flags SAB_NO_ERROR_REPORTING)) Current language: auto; currently c++ (gdb) bt #0 0x4008d044 in Situation::generateMessage (this=0x3c202020, #type=1498698543, code=171853132, arg1=@0x20202020, arg2=@0x20202020, theMessage=@0x682f3c20) at situa.cpp:263 #1 0x20202020 in ?? () Cannot access memory at address 0x20202020 -- My system is Red Hat 7.0, I have upgraded most software with RPM's to RH7.2 level. I have installed from source the latest expat and Sablotron packages (no errors). My PHP configure was - ./configure --prefix=/etc --with-apache=/usr/src/Apachetoolbox-1.5.45/apache_1.3.22 --enable-exif --enable-track-vars --with-calendar=shared --enable-safe-mode --enable-magic-quotes --enable-trans-sid --enable-wddx --enable-ftp --with-gd=/etc --with-zlib --enable-gd-native-tt --with-t1lib=/etc/lib/php/t1libs --with-jpeg-dir=/etc --with-png-dir=/etc --with-zlib-dir=/etc --with-ttf --with-freetype-dir=/etc --with-mcrypt --with-openssl --with-mysql=/usr --enable-xslt --with-dom --with-xslt-sablot - The Apache configure was - ./configure \ --with-layout=Apache \ --prefix=/etc/httpd \ --enable-suexec \ --suexec-caller=nobody \ --enable-module=so \ --enable-module=access \ --disable-module=auth_db \ --disable-module=digest \ --enable-module=imap \ --enable-module=mime \ --enable-module=setenvif \ --disable-module=usertrack \ --enable-module=auth \ --disable-module=cern_meta \ --disable-module=expires \ --enable-module=log_config \ --disable-module=proxy \ --disable-module=vhost_alias \ --disable-module=auth_anon \ --enable-module=cgi \ --disable-module=headers \ --disable-module=log_referer \ --enable-module=rewrite \ --enable-module=userdir \ --enable-module=asis \ --enable-module=autoindex \ --disable-module=example \ --disable-module=log_agent \ --enable-module=negotiation \ --disable-module=status \ --enable-module=actions \ --disable-module=auth_dbm \ --enable-module=dir \ --enable-module=include \ --disable-module=mime_magic \ --disable-module=unique_id \ --enable-module=alias \ --disable-module=auth_digest \ --enable-module=env \ --disable-module=info \ --disable-module=mmap_static \ --disable-module=speling \ --add-module=/usr/src/Apachetoolbox-1.5.45/src/apache-contrib-1.0.8/mod_macro/mod_macro.c \ --activate-module=src/modules/perl/libperl.a \ --add-module=/usr/src/Apachetoolbox-1.5.45/src/mod_bandwidth.c \ --activate-module=src/modules/php4/libphp4.a \ - Edit this bug report at http://bugs.php.net/?id=14442edit=1 -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13896 Updated: Segmentation fault with xslt extention
the rest of the comments, please view the bug report online at http://bugs.php.net/?id=13896 Edit this bug report at http://bugs.php.net/?id=13896edit=1 -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PATCH] optional parameter to mysql_connect() to create truly new link
Hi, I think no magic needed, optional parameter is good enough solution and gives the control to the hands of programmer. Just - there should be this flag for both: mysql_connect() and mysql_pconnect(). And I agree different usernames is not the right thing to suggest. Lenar Markus Fischer wrote: On Wed, Nov 21, 2001 at 12:16:51PM +0200, Lenar Lõhmus wrote : Markus Fischer wrote: Hi, The attached patch against current CVS adds an optional parameter to mysql_connect() to specify if a truly new link to the database should be established. The patch changes the prototype to: resource mysql_connect ([string hostname [, string username [, string password [, bool new_link ); There is no BC issue. The optional parameter is ignored when using mysql_pconnect(). I think it's not right to ignore this with mysql_pconnect(). In this case the meaning of this flag should be: 'return existing mysql resource (or create new) not yet returned by similar call during this request' Sure. It's just a matter of altering the logic (just a oneliner). The problem, with the current implementation you _can't_ work this around from PHP side. Only with different database users which is, IMHO, not the right solution. PHP traps traps you into this and its not hard to fix and has no BC issues at all. I already received mail that its stupid to add a new param to the Function. and that its better that PHP detects this problem self. I don't see such a problem with an optional parameter. And, I don't think its possible for PHP to do magic and detect itself what to do. I wonder what others think? - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] php module calling php code
Colin McDonald wrote: you where close: call_user_method() Zak was right. call_user_method() is deprecated. At least it sais so when NOTICEs are enabled. colin Zak Greant wrote: IIAGR, you should be able to find an example in call_user_func() -- Lenar Lõhmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Removing ext/sablot from 4.1?
Sterling Hughes wrote: Hey, Just sending out a feeler message, while I still have some motivation to argue about the future of XSLT (ie, I have other work I should be doing ;) -- I'd like to move ext/sablot from the standard PHP distribution, and update the PHP documentation to the new XSLT API for PHP 4.1 for four reasons: 1) Its a bit confusing with two extensions doing the same thing 2) ext/xslt has become almost stable :) No really... At least it is much more stable than ext/sablot. 3) A bit of an encouragement for users to switch to the new xslt extension which is not only cleaner, but its also signifigantly improved with regards to features and speed. 4) 4.1 is a bit of a compatibility breaking release, I don't know when I'll get the chance again (PHP 5?) -Sterling +2 for removing. At least some package maintainers will realize then that it's gone and start looking for replacement. Speaking about Debian here :) -- Lenar Lõhmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: XSLT Extension and paths
Sebastian Bergmann wrote: Sebastian Bergmann wrote: ?php $p = xslt_create(); $res = xslt_process($p, 'test.xml','test.xsl'); if(!$res) echo xslt_error($p); echo $res; xslt_free($p); ? This snippet triggered some memories. With 4.1.0rc1-cgi (maybe under apache too, haven't tested) .. if you leave xslt_free() out then after script has finished and php is shutting down .. it segfaults. Lenar -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] ?php= ? sytanx again
[EMAIL PROTECTED] wrote: On Fri, 16 Nov 2001, Marc Boeren wrote: Let's take this one step further (into absurdity ;-) and also add script language=php= %var; /script Why not remove this utter crap at all? =) (I know about BC, but I really think these tags are stupid). Maybe something to remove (or add a warning) in PHP 4.2.0 ? Derick Do not remove script language=php/script It's very useful in some cases. For example if you transform xsl/xml into html with embedded php to execute later. This is not utter crap. -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] md5sum() patch
Alessandro Astarita wrote: Il 17:25, giovedì 15 novembre 2001, [EMAIL PROTECTED] ha scritto: Then this will do the same: $sum = `md5sum filename`; Do I have to depends on the external executable? ...in my opinion is not the right way. +1 to the function -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #14042 Updated: Comment inside if statement causes parse error
You're messing with the ASP-tags. The line echo ta contains % which jumps out of PHP-mode. Then, if EOF has been reached, the brackets haven't been closed, which results in that parse-error. So, edit your php.ini and disbable asp-tags or use width=50% (which is better anyway). It's a little bit strange you can jump into php mode with '?php' and jump out of that mode with '%'. IMO there should be some check in place - so that mixing different tags is not allowed this way. Lenar -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #14036: Segfault when using multipart form data
Rasmus Lerdorf wrote: Well, file uploads do work in general in PHP 4.0.6 or the whole world would be screaming. So there is something specific to your test case or your system that is causing this. Well I'm using 4.1.0rc1 on linux 2.4.8 (debian unstable). And there was 1 case with file uploads not working (apache crashed). Since I didn't have time to test this and our customer said it's not so important to have file upload form, I removed related code and didn't test it more nor searched for more info on cause. Bud it didn't work for sure. Strange crashes (not always, let's say 1 out of 5 submits). I remember creating a very simple form to test it. And it worked 100%. So it seems the bug is dependent on how you handle that upload. Lenar -Rasmus On Tue, 13 Nov 2001, Hans Rakers wrote: As i reported in my bug report, i can reproduce this problem with 4.0.6 and current cvs. Hans Rakers At 15:18 12-11-2001 -0800, you wrote: This code has changed significantly in current CVS. 4.0.6 and 4.1.0RC1 should not have the problem. -Rasmus On Tue, 13 Nov 2001, Yasuo Ohgaki wrote: [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Linux 2.2.20 and 2.4.14 PHP version: 4.0CVS-2001-11-12 PHP Bug Type: Reproducible crash Bug description: Segfault when using multipart form data When submitting a form with enctype multipart/form-data Apache childs segfault. Weird thing is that the problem is not reproducible when compiling PHP with debugging enabled. I have tried PHP-4.0.6 and CVS snapshot php4-20020600. 4.1.0RC may not have this problem. I cannot reprocude with 4.1.0. I need to know to the script/config to be sure, though. -- Yasuo Ohgaki -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PATCH] sablotron scheme/sax handlers fix
It seems that nobody liks handling bug reports/patches regarding xslt module. Nevertheless it's buggy and partly unusable, so it would be very nice if somebody could update cvs with this patch (maybe check before, since I'm not C programmer) before next release of php. Thank you in advance, Lenar Lenar Lõhmus wrote: Hi, Since nobody responded to my bugreport about sax/scheme handlers not working in php and since i needed them in a working state I tried to understand the source and finally generated a fix. So this patch makes ext/xslt working when sablotron and scheme/sax handlers are used. Hope it finds it's way to cvs. Lenar Lõhmus [EMAIL PROTECTED] -- Lenar Lõhmus Vision Group -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] parent and grandparent functions
Hello,
Sorry to write in dev, but i consider this a weakness of php. Something
needs to be changed.
Ok, maybe thereis a solution right now existing in PHP, but i'm unaware of
it.
Skip to the problem
I have three classes:
class a {
function make() {
// some code
}
}
class b extends a {
function make() {
// some code
parent::make();
}
}
class c extends b {
function make() {
// some code
parent::make();
}
}
now the class 'c' is instantiated and the member function 'make' is called.
All works up to the point where 'b'::make calls parent::make().
It seems to call itself :(. I can understand this is logical behaviour since
it's still an instance of class c,
so parent:: is still b::, but how should I call that grandparent's make()???
This doesn't seem like a good OOP.
For example delphi's 'inherited' works relative to the class it's used in
and it is way more useful than php's parent::.
is there any elegant solution(s) to my problem?
Lenar Lõhmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] parent and grandparent functions
An update. When I hardcode the parent class name (example below) then it
works. But if I decide to change the
class inheritance hierarchy I need to manually revise all my existing
classes. So where is the flexibility?
Furthermore .. I found a note in php manual stating that in php405
get_parent_class also accepts class name string as it's
only parameter.
So when corectly passing parent class names to each make I'll be able to do
something like that:
function make($this_name) {
$parent = get_parent_class($this_name);
eval($parent::make('$parent'));
}
Unfortunately, the only thing I get form get_parent_class when calling it
with string parameter is quite empty string (and I have 4.0.5).
More. I think it would be wise to implement an class name like parent, for
example 'inherited' which calls always the real parent class
(that is the parent class of the class where such keyword is used not the
parent class of current object instance) method (or the method of
parent's parent if the method is not overriden in parent etc, generating an
error if the method is not found in entire class inheritance hierarchy)..
I hope you understood, since enhlish is not my primary language.
If you need me to elaborate a bit then ask.
Lenar
Lenar Lõhmus [EMAIL PROTECTED] wrote in message
9gpn2a$oc6$[EMAIL PROTECTED]">news:9gpn2a$oc6$[EMAIL PROTECTED]...
Hello,
Sorry to write in dev, but i consider this a weakness of php. Something
needs to be changed.
Ok, maybe thereis a solution right now existing in PHP, but i'm unaware of
it.
Skip to the problem
I have three classes:
class a {
function make() {
// some code
}
}
class b extends a {
function make() {
// some code
parent::make(); // instead write:
a::make();// hardcoded
}
}
class c extends b {
function make() {
// some code
parent::make(); // instead write:
b::make();//hardcoded
}
}
now the class 'c' is instantiated and the member function 'make' is
called.
All works up to the point where 'b'::make calls parent::make().
It seems to call itself :(. I can understand this is logical behaviour
since
it's still an instance of class c,
so parent:: is still b::, but how should I call that grandparent's
make()???
This doesn't seem like a good OOP.
For example delphi's 'inherited' works relative to the class it's used in
and it is way more useful than php's parent::.
is there any elegant solution(s) to my problem?
Lenar Lõhmus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP] parent and grandparent member method calls
yes, you were right it works (when you said it works i tested your code out
and it definetly works). but this made me more confused than i was before.
i commented in the lines in my code that earlier didn't work (replaced them
sometime with class names hard coded solution) and it still did _not_ work.
ok, made copies of files in action and started to strip them down.
First, my stripped down code that works:
?
class a {
function make($params) {
}
}
class b extends a {
function make() {
echo WORKS OK;
}
}
class c extends b {
function make($params) {
parent::make();
}
}
class d extends c {
function make($params) {
parent::make($params);
}
}
$d = new d();
$d-make(whatever);
?
now, when i remove the definition of class 'a' to another file and include
the file like this:
file1.php:
?
class a {
function make($params) {
}
}
?
file2.php:
?
include ./file1.php; // or require - no difference
class b extends a {
function make() {
echo WORKS OK;
}
}
class c extends b {
function make($params) { // this gets called forever and generating
warnings
parent::make();
}
}
class d extends c {
function make($params) {
parent::make($params);
}
}
$d = new d();
$d-make(whatever);
?
then i get message 'Warning: Missing argument 1 for make()' ... the code is
same ... but working differently.at least with my php 4.0.5. so i think this
is a bug.
that include in our system is neccessary so to the point it works correctly,
i have to hardcode class names.
and thank you scott pointing me out (and getting me confused :) ).
lenar.
scott [gts] [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
it looks like your solution *is* elegant... i tried
out your code, becuase i was astonished that such a
simple thing allegedly wasn't working... and it
did work.
below is the exact code i had in my text editor,
and it executed perfectly.
when i called $c-make(), it printed A:: MAKE.
..am i misunderstanding your problem?
?
class a {
function make() {
// some code
print A:: MAKE;
}
}
class b extends a {
function make() {
// some code
parent::make();
}
}
class c extends b {
function make() {
// some code
parent::make();
}
}
$c = new c();
$c-make();
?
-Original Message-
From: Lenar Lõhmus [mailto:[EMAIL PROTECTED]]
Sent: 20 June 2001 09:01
To: [EMAIL PROTECTED]
Subject: [PHP] parent and grandparent member functions
Hello,
I hit a wall. No offense, but this OO stuff in PHP is somehat weird, but
skip to the problem.
I have for example three classes:
class a {
function make() {
// some code
}
}
class b extends a {
function make() {
// some code
parent::make();
}
}
class c extends b {
function make() {
// some code
parent::make();
}
}
now the class 'c' is instantiated and the member function 'make' is
called.
All works up to the point where 'b'::make calls parent::make().
It seems to call itself :(. I can understand this is logical behaviour
since
it's still an instance of class c,
so parent:: is still b::, but how should I call that grandparent's
make()???
This doesn't seem like a good OOP.
For example delphi's 'inherited' works relative to the class it's used
in
and it is way more useful than php's way.
is there any elegant soultion(s) to my problem?
Lenar Lõhmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
