pass NULL, it fails on the grounds that it isn't a ZObject.
Also,
Could someone explain the purpose of the zend_parse_method_parameters
function as opposed to using the zend_parse_parameters?
Thanks
Bob Silva
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
parameter in C.
I'll keep playing around with parameter combinations and see what works.
Thanks
Bob Silva
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 27, 2005 12:06 AM
To: Bob Silva
Cc: internals@lists.php.net
Subject: Re: [PHP-DE
ook a bit to debug since it is kinda outta step with the way Zend
handles zvals elsewhere.
BTW Marcus, nice work on the SPL stuff.
Bob
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 27, 2005 11:40 AM
To: Rob Richards
Cc: Bob Silva; inte
#x27;d prefer
not to have this constraint).
Thanks
Bob Silva
few ideas that have to do with looping through ce->parent and
zend_call_function.
Was wondering if you guys can offer some of your experience on how you would
approach this problem.
Bob Silva
give me if its crude, but it appears to work.
Bob
-Original Message-
From: Bob Silva [mailto:[EMAIL PROTECTED]
Sent: Friday, October 28, 2005 7:35 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Follow the object constructor chain ... options
What would be the suggested method of simula
> Sent: Saturday, October 29, 2005 3:58 AM
> To: Bob Silva
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Follow the object constructor chain ... options
>
> Hello Bob,
>
> why so complex and potential wrong?
>
> zend_class_entry *ce = Z_OBJ_CE(object);
>
ible in the engine is out of my range of knowledge.
Bob Silva
> -Original Message-
> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 29, 2005 4:19 PM
> To: Sebastian
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] what happened to that
L PROTECTED]
> Sent: Saturday, October 29, 2005 6:17 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] what happened to that new isset() like language
>
> Bob Silva wrote:
> > This makes perfect sense (to me at least):
> >
> > $localvar = isset($_REQUEST['g
Hi,
I have an internal function defined that returns an array zval:
zval *pow_zstring_internal_split(Z_STRVAL_P(ivalue), separator, count, 0
TSRMLS_DC);
When I call it like this, return_value is NULL in userland.
return_value = pow_zstring_internal_split(Z_STRVAL_P(ivalue), sepa
Please take under consideration this patch to fully utilize cast_object
handlers in the new parameter parsing API.
The old parameter API forced the called function to validate and convert its
arguments using the convert_to_* functions.
The convert_to_* functions make use of cast_object handlers if
to turn it into a
PECL extension.
Why program if you can't have fun doing it?
Bob
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 04, 2005 12:29 AM
> To: Bob Silva
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [
ple that are looking for a
strongly typed PHP may find it useful once I complete the rest of the object
framework. Next up is Collections. Again, I really appreciate you taking the
time to reply to my questions and point me in the right direction.
Bob
> -Original Message-
> From: M
e at work, so it would have to wait till Monday).
>
> (IMHO, I still think a core String class would be very useful. There are
> many extensions that provide both a procedural and OOP interface. Take for
> example SQLite. You can either use the sqlite_* functions or use the
> SQLiteDa
I destruct the objects myself before replacing the property (Array)
with the new one?
Depending on the answer, what is the process to destruct an object? Just
ZVAL_DEL_REF it and let the engine GC do the rest?
Thanks
Bob Silva
y extension is
dependent on it.
On a side note, are there instructions on how to PECL'ize an extension so I
can release a first revision?
Thanks
Bob Silva
> -Original Message-
> From: Lukas Smith [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 15, 2005 12:44 PM
f the skeleton
extension as a starting point. Sara's articles are good for understanding
the ZVAL's usage within PHP. Also, looking at some of the newer extensions
like SPL are good starting points to get some of the base concepts down.
Good luck, it isn't so hard once you get
Hi Steph,
Maybe in section 4, explain what the result of the change is. You explain
what was wrong in the past, but don't really cover what the new behavior is.
Bob
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 17, 2005 9:11 PM
> To: internal
is_ref? Aren't objects treated as is_ref natively throughout the
engine? Or is this just old code from PHP 4 days that is still hanging
around?
Thanks for the understanding.
Bob Silva
le of the section indicates it was the first preference.
Thanks
Bob Silva
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 22, 2005 2:45 PM
> To: Matthias Pigulla
> Cc: internals
> Subject: Re: AW: [PHP-DEV] PDM Meeting No
p;& memcmp(fptr->common.scope->name, ce->name)) {
string_printf(str, " inherited from %s", fptr->common.scope->name);
}
string_printf(str, " ] {\n");
Not sure if this works in all situations, I'll leave that for you guys to
determine if you think this
Whoops, that memcmp should be a strcmp.
> -Original Message-
> From: Bob Silva [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 22, 2005 8:19 PM
> To: 'internals'
> Subject: [PHP-DEV] Reflection API idea
>
> Here's an idea for the maintainer of the
Nope, sorry, I'll do my homework next time.
Bob
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 23, 2005 12:39 AM
> To: Bob Silva
> Cc: 'internals'
> Subject: Re: [PHP-DEV] Reflection API idea
>
&g
EAR is let off the hook, as am I and many other developers who have
existing classes that will conflict with any core objects in the future.
Bob Silva
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 25, 2005 11:28 AM
> To: Christia
27;s just
plain awkward IMO.
Bob Silva
> -Original Message-
> From: Christian Schneider [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 25, 2005 4:42 PM
> To: Marcus Boerger
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out
&
that aren't bound to the funkiness of using PEAR and all its dependencies
like PEAR_Error (which is my own personal reason for not giving PEAR a
second look).
Bob Silva
> -Original Message-
> From: Gareth Ardron [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 25, 200
ndication to me
that more things need to be worked out before the first core class is
"officially" released.
Bob Silva
> -Original Message-
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 25, 2005 8:50 PM
> To: internals@lists.php.net
&
ason enough for such an awkward syntax. Any core functionality that uses
globals now that is moved to an object will require code modifications
anyways, so I don't think thatÂ’s a valid argument for the need of namespace
constants.
Bob Silva
> -Original Message-
> From: Jessie Hernande
Very good points Kevin since I was accused of wanting to turn PHP into C++
earlier just for not liking the \ separator. I suppose the person that
selected the -> object operator had the same intentions :)
Bob
> -Original Message-
> From: Kevin Brown [mailto:[EMAIL PROTECTED]
> Sent: Satur
ch will ever be accepted if we don't have agreement of
what namespaces should do and not do.
Bob Silva
-Original Message-
From: Jessie Hernandez [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 8:03 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PHP 5.1 (Or How
Just as easy
namespace Foo
{
class Foo {
const XYZ = 42;
}
class Bar
{
const = Foo::XYZ;
//...
}
class Baz
{
const = Foo::XYZ;
//...
}
}
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, Novemb
Can someone explain why you wouldn't want private and/or protected classes
within a namespace? I imagine it would be due to problems with
implementation... thanks for an explanation.
Bob
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 12:
when it was first tried in
the early 5.0 development.
Bob Silva
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 2005 2:43 PM
> To: Bob Silva
> Cc: 'Jessie Hernandez'; internals@lists.php.net
> Subject: Re: [PHP-DEV]
Looking for some feedback on what the expected behavior should be for class
and/or constant ambiguity within namespaces. For instance:
Classes.php:
namespace A {
const FOO = 123;
class Bar { . }
class FooBaz { . }
}
namespace B {
const FOO = 456;
class Bar { .
If Mike doesn't want to use namespaces, then Mike shouldn't use Jessies
package.
Bob
> -Original Message-
> From: Bart de Boer [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 30, 2005 11:45 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Re: Desired namespace behavoir
>
> >>
ara's articles on zend.com to understand the zval structure and
parameter parsing api, once you have these down the rest flows pretty well
even without a background in C.
Hope this helps,
Bob Silva
> -Original Message-
> From: Sara Golemon [mailto:[EMAIL PROTECTED]
> Sent: Th
36 matches
Mail list logo
