Stanislav Malyshev wrote:
Hi!
How can it break existing code? It's only on issue if a class is part
of a namespace, and existing code doesn't have namespaces. So it
*can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy t
Hello Stanislav,
I must be having a headache here. But there seriously seems to be a
misunderstanding.
We definitively introduced __construct as a bug fix in our language design.
And that is that you can have a function a in your class b that suddenly
becomes a constructor in the derived class
On 5/5/08, Pierre Joye <[EMAIL PROTECTED]> wrote:
> We can then even drop the old form in php 6.x. Many changes have no
> gain but make the language clearer or cleaner. It is not an objective
> change but it does help to cleanup the language.
>
> I will not die if we still support old things fo
On Mon, May 5, 2008 at 9:18 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
>
> > kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3 and
> remove in PHP 6.x.
> >
>
> There's nothing to fix, it's not broken.
Ok, point made. Once again a "you vs all other" thread, no
Hi!
kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3
and remove in PHP 6.x.
There's nothing to fix, it's not broken.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runti
Hi!
We can then even drop the old form in php 6.x. Many changes have no
gain but make the language clearer or cleaner. It is not an objective
change but it does help to cleanup the language.
There's nothing to "cleanup". You trying to prove that this form should
be removed by representing it
On 05.05.2008, at 20:51, Pierre Joye wrote:
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
It's just simple to make constructors work in the same way in
namespaces and
out of them. It would be difficult to explain why the first script
prints
"ok" and the second do
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> It's just simple to make constructors work in the same way in namespaces and
> out of them. It would be difficult to explain why the first script prints
> "ok" and the second doesn't.
It is easy to explain: "You have to use
It's just simple to make constructors work in the same way in namespaces
and out of them. It would be difficult to explain why the first script
prints "ok" and the second doesn't.
I think, we must support old-style constructors for both cases or remove
them at all, but as I said removing t
Hi!
code should be updated to use the normal constructor (which exists
since 4-5 years).
There's nothing "not normal" about using either form of constructors,
why force people to rewrite their perfectly good and working code?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Hi!
How can it break existing code? It's only on issue if a class is part of
a namespace, and existing code doesn't have namespaces. So it *can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy to do. Forcing people to rena
On Mon, 5 May 2008, Dmitry Stogov wrote:
> As we didn't drop this support yet, and it didn't work in namespaces by
> mistake I've fixed it to work in the same way as without namespaces.
>
> Removing this support won't give any speedup (except of compilation speed),
> but might break a lot of code
Hi Dmitry,
On Mon, May 5, 2008 at 8:02 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> As we didn't drop this support yet, and it didn't work in namespaces by
> mistake I've fixed it to work in the same way as without namespaces.
>
> Removing this support won't give any speedup (except of compilat
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation
speed), but might break a lot of code.
Thanks. Dmitry.
Antony Dovgal wrote:
On 05.
Hi!
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
If by old-style ctors you mean this:
namespace Foo;
class Bar {
function Bar() {/* ctor! */}
}
then I think it should be su
Pierre Joye escribió:
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
--
"Progress is possible only if we train ourselves to think about programs
without thinking of them as pieces o
On 05.05.2008 14:13, Derick Rethans wrote:
Support for old-style constructors in namespaces
Do we really want/need this?
I'm not really sure either.
5.3 seems to be perfect candidate for dropping this kind of backward
compatibility.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime
On Mon, May 5, 2008 at 12:13 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 5 May 2008, Dmitry Stogov wrote:
>
> > dmitryMon May 5 09:44:07 2008 UTC
> >
> > Added files:
> > /ZendEngine2/testsns_063.phpt
> >
> > Modified files:
> > /ZendEngine2
On Mon, 5 May 2008, Dmitry Stogov wrote:
> dmitryMon May 5 09:44:07 2008 UTC
>
> Added files:
> /ZendEngine2/testsns_063.phpt
>
> Modified files:
> /ZendEngine2 zend_API.c zend_compile.c
> Log:
> Support for old-style
Seems a little excessive to me!
On 18/07/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
I just realized that it's the first time I used a quadruple pointer.
Must celebrate.
-Andrei
On Jul 18, 2006, at 3:07 PM, Andrei Zmievski wrote:
> + zval varargs = NULL;
> + int *n_varargs = N
Hello Andrei,
oh my godlet's have a few beers on that during oscon at the oregon
brewers festival :-)
best regards
marcus
Wednesday, July 19, 2006, 12:16:22 AM, you wrote:
> I just realized that it's the first time I used a quadruple pointer.
> Must celebrate.
> -Andrei
> On Jul 18,
Sure. Starts on Thursday.
-A
On Jul 18, 2006, at 3:54 PM, Marcus Boerger wrote:
Hello Andrei,
oh my godlet's have a few beers on that during oscon at the
oregon
brewers festival :-)
best regards
marcus
Wednesday, July 19, 2006, 12:16:22 AM, you wrote:
I just realized that it's t
You're a 4 star general now ;-)
On 18-Jul-06, at 6:16 PM, Andrei Zmievski wrote:
I just realized that it's the first time I used a quadruple
pointer. Must celebrate.
-Andrei
On Jul 18, 2006, at 3:07 PM, Andrei Zmievski wrote:
+ zval varargs = NULL;
+ int *n_varargs = NULL
I just realized that it's the first time I used a quadruple pointer.
Must celebrate.
-Andrei
On Jul 18, 2006, at 3:07 PM, Andrei Zmievski wrote:
+ zval varargs = NULL;
+ int *n_varargs = NULL;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
On Tue, April 18, 2006 1:11 pm, Pierre wrote:
> On 4/18/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
>> Once again, people who upgrade to PHP 6 will either turn the unicode
>> switch and stick with it (in which case they will see "binary
>> string"
>> and "Unicode string") or they will keep the s
On Tue, 18 Apr 2006, Pierre wrote:
> On 4/18/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> > Once again, people who upgrade to PHP 6 will either turn the unicode
> > switch and stick with it (in which case they will see "binary string"
> > and "Unicode string") or they will keep the switch off
On 4/18/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> Once again, people who upgrade to PHP 6 will either turn the unicode
> switch and stick with it (in which case they will see "binary string"
> and "Unicode string") or they will keep the switch off (and will live
> merrily thereafter with "st
Once again, people who upgrade to PHP 6 will either turn the unicode
switch and stick with it (in which case they will see "binary string"
and "Unicode string") or they will keep the switch off (and will live
merrily thereafter with "string"). They won't be flipping back and
forth.
-Andrei
O
On 4/18/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Yeah I agree. OK I guess we can keep it like this.
Can we keep only "string" then? "string in non-unicode behaves exactly
like "binary string" in unicode mode.
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
Yeah I agree. OK I guess we can keep it like this.
At 10:32 AM 4/18/2006, Andrei Zmievski wrote:
I think this is a minor issue in any case, but consider this. Most
of the people who will upgrade from PHP 5 to 6 will not touch
unicode_semantics switch and it will default to Off. And then all of
I think this is a minor issue in any case, but consider this. Most of
the people who will upgrade from PHP 5 to 6 will not touch
unicode_semantics switch and it will default to Off. And then all of a
sudden they are getting messages about "binary string". I think that is
more confusing.. Especi
On 18.04.2006 21:24, Pierre wrote:
On Tue, 18 Apr 2006 10:15:42 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
Do we really need this? I'd prefer to keep "string" and "unicode"
I was asking the same thing. We should have only two names, as we have
actually only two types, binary and unicode.
On Tue, 18 Apr 2006 10:15:42 -0700
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> Do we really need this? I'd prefer to keep "string" and "unicode"
I was asking the same thing. We should have only two names, as we have
actually only two types, binary and unicode.
I'm in favour of naming it "binary st
Marcus Boerger wrote:
> Besides that unserialize would already call __autoload.
Then everything is perfect. :-)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP In
Hello Sebastian,
sure we could do but it wouldn't change anything in the bugreport.
There an interface with the same name was declared already. Besides
that unserialize would already call __autoload.
marcus
Sunday, June 6, 2004, 7:43:33 AM, you wrote:
> Marcus Boerger wrote:
>> we could add a c
Marcus Boerger wrote:
> we could add a check for every place that ends up calling object
> initialization. But you don't win anything.
As far as I understand the original bug report __autoload() is not (but
should be) called during the session deserialization. What would be
wrong with this?
At 07:31 PM 1/19/2004 +0100, Marcus Boerger wrote:
Hello Wez,
Monday, January 19, 2004, 12:15:24 PM, you wrote:
> The win32 build will correctly order extensions for internal_functions.c,
> so that solves static compiles, but that doesn't help dynamic loading
> (nor the unix build).
> Would it be
Hello Wez,
Monday, January 19, 2004, 12:15:24 PM, you wrote:
> The win32 build will correctly order extensions for internal_functions.c,
> so that solves static compiles, but that doesn't help dynamic loading
> (nor the unix build).
> Would it be ok to keep Marcus' function so that a wise extens
Wez Furlong wrote:
This is quite difficult to implement correctly, as the extension
name != module file name, and that filename is platform dependent
Hmm. Three passes should do the job: First DL_LOAD, then DL_FETCH_SYM to
determine order of init then initialize the modules. Or am I missing
somet
Bah, stupid OE.
- Original Message -
From: "Wez Furlong" <[EMAIL PROTECTED]>
To: "Christian Schneider" <[EMAIL PROTECTED]>
Sent: Monday, January 19, 2004 11:53 AM
Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
> This is qui
Wez Furlong wrote:
Even better would be to add an array of module names into the module
structure and have the ZE apply this check when it loads the module.
I think that it is reasonably important to warn the user that things
will break if we can detect it.
If there was an array of dependencies in
The win32 build will correctly order extensions for internal_functions.c,
so that solves static compiles, but that doesn't help dynamic loading
(nor the unix build).
Would it be ok to keep Marcus' function so that a wise extension can check
if things were loaded in the correct order?
Maybe adjust
Hello Andrei,
Thursday, December 4, 2003, 1:19:44 AM, you wrote:
> On Sun, 30 Nov 2003, Andi Gutmans wrote:
>> I kind of agree with Andrei here. We discussed in the past that
>> __toString() will not propogate to every place in the engine where we check
>> for IS_STRING but will only effect prin
Hello Andrei,
Thursday, December 4, 2003, 1:18:50 AM, you wrote:
> On Mon, 01 Dec 2003, Marcus Boerger wrote:
>> No, when the object does not offer a valid string conversion nothing will
>> change compared to what we had before. So the only thing done is that you
>> now can implement objects that
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> I kind of agree with Andrei here. We discussed in the past that
> __toString() will not propogate to every place in the engine where we check
> for IS_STRING but will only effect print.
> I think getting into this is a bad idea. If the old parameter pass
On Mon, 01 Dec 2003, Marcus Boerger wrote:
> No, when the object does not offer a valid string conversion nothing will
> change compared to what we had before. So the only thing done is that you
> now can implement objects that can be used as strings like simplexml_element.
> An extension like that
Hello Stanislav,
Tuesday, December 2, 2003, 10:01:40 AM, you wrote:
AK>>> but this is a whole world clearer...
AK>>>
AK>>> foreach($s->person->children as $person) {
AK>>> $firstname_text_value = $person->firstname->value;
AK>>> }
> I agree 100%. It looks cool if yo do $a = $b and behind t
AK>> but this is a whole world clearer...
AK>>
AK>> foreach($s->person->children as $person) {
AK>> $firstname_text_value = $person->firstname->value;
AK>> }
I agree 100%. It looks cool if yo do $a = $b and behind the scenes it
launches whole train of magic and runs a lot of code, but it's
I've seen this in SimpleXML, and although it's cool, I know from
experience, that almost every time you use it, is never going to work as
expected.
I know this is shorter. and cooler...
foreach($s->person as $person) {
$firstname_text_value = $person->firstname;
}
but this is a whole wo
Hello Adam,
Monday, December 1, 2003, 6:51:38 PM, you wrote:
> On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
>> AMT>> $s = simplexml_load_file('file.xml');
>> AMT>> $s->person->xsearch('/my/xpath/query');
>>
>> This makes fetch for read.
> I'm with Andi and George. We should just fix SimpleXML
Hello Stanislav,
Monday, December 1, 2003, 5:55:40 PM, you wrote:
MB>>> If you don't understand XML then it is harder to understand. If you
> Well, let's suppose I do understand XML for some measure.
hehe, good :-)
MB>>> you are now basically forced to do fucking code like DOM - thanks -
MB>>>
Hello Andi,
Monday, December 1, 2003, 5:57:11 PM, you wrote:
> Hey,
> I don't quite understand why SimpleXML can't return a string. Why does it
> need to return an object? It should know how to differentiate between
> read/write mode, and return a string in read mode and a proxy object in
> w
Hello Stanislav,
Monday, December 1, 2003, 5:51:20 PM, you wrote:
> AMT>> Are we discussing this feature's technical or aesthetic merits? Or
> AMT>> both?
> Technical.
> AMT>> foreach ($dom->getElementsByTagname('person') as $person) {
> AMT>> list($firstname) =
> $person->getElementsBy
Hi,
As an observer of this whole debate, I'd like to point out that if
__toString() will be magical anywhere, it must be magical everywhere PHP
would normally do an implicit cast, otherwise it does nothing but
confuse the issue. implicit cast to string always happens when using
string operato
On Mon, 1 Dec 2003, George Schlossnagle wrote:
> [puts on evil twin hat]
Theo?
> To play devil's advocate to the idea - the problem with it is that it
> requires a bunch of extra code when examining an unknown document.
> This is similar to the (promised by Sterling to be fixed) quirk of
> Simpl
On Dec 1, 2003, at 12:51 PM, Adam Maccabee Trachtenberg wrote:
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
AMT>> $s = simplexml_load_file('file.xml');
AMT>> $s->person->xsearch('/my/xpath/query');
This makes fetch for read.
I'm with Andi and George. We should just fix SimpleXML to return
string
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
> AMT>> $s = simplexml_load_file('file.xml');
> AMT>> $s->person->xsearch('/my/xpath/query');
>
> This makes fetch for read.
I'm with Andi and George. We should just fix SimpleXML to return
strings instead of objects when there are no descendant nodes
AMT>> $s = simplexml_load_file('file.xml');
AMT>> $s->person->xsearch('/my/xpath/query');
This makes fetch for read.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Internals - PHP Runtime Development Mailing List
To unsub
On Dec 1, 2003, at 11:52 AM, Marcus Boerger wrote:
Hello Stanislav,
Monday, December 1, 2003, 5:05:14 PM, you wrote:
DR>>> To make it simple to use? I agree with Adam here, with the new
It may make one particular case of use simple. It would make
understanding
even this case complicated, and w
On Mon, 1 Dec 2003, Andi Gutmans wrote:
> I don't quite understand why SimpleXML can't return a string. Why does it
> need to return an object? It should know how to differentiate between
> read/write mode, and return a string in read mode and a proxy object in
> write mode.
That may be a solutio
It can be resolved at compile-time.
My main problem is not with the casting operator but with auto-casting all
throughout the engine including parameter passing. I have a very bad
feeling that stuff will break such as array offset assigning.
Andi
At 04:58 PM 12/1/2003 +, Wez Furlong wrote:
It's probably a lot higher than you think, given that other
object models are likely to use a similar naming convention :-)
I still think it is a bad idea to hide methods like this for
overloaded objects; we have the cast handler and (to my eyes)
$foo = (string)$obj;
looks simpler and less magic
Hey,
I don't quite understand why SimpleXML can't return a string. Why does it
need to return an object? It should know how to differentiate between
read/write mode, and return a string in read mode and a proxy object in
write mode.
What am I missing?
I agree that we should allow for SimpleXML'
MB>> If you don't understand XML then it is harder to understand. If you
Well, let's suppose I do understand XML for some measure.
MB>> you are now basically forced to do fucking code like DOM - thanks -
MB>> no more simple.
Making particular case of XML handling simple is good if it doesn't mak
Hello Stanislav,
Monday, December 1, 2003, 5:05:14 PM, you wrote:
DR>>> To make it simple to use? I agree with Adam here, with the new
> It may make one particular case of use simple. It would make understanding
> even this case complicated, and will complicate a lot of other cases of
> which w
AMT>> Are we discussing this feature's technical or aesthetic merits? Or
AMT>> both?
Technical.
AMT>> foreach ($dom->getElementsByTagname('person') as $person) {
AMT>> list($firstname) = $person->getElementsByTagname('firstname');
AMT>> $firstname_text_value = $firstname->firstChi
What's the chance of having a __toString() in an external object model
(note the two underscores :)
Andi
At 02:26 PM 12/1/2003 +, Wez Furlong wrote:
I favour a), if you mean that (string)$com_object will work.
I'm not so bothered with userspace objects.
b) is just wrong for overloaded object
Hello Moriyoshi,
Monday, December 1, 2003, 2:56:29 PM, you wrote:
> On 2003/12/01, at 19:39, Andi Gutmans wrote:
>> At 12:50 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
>>> On Sun, 30 Nov 2003, Andi Gutmans wrote:
>>>
>>> > At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrot
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
> DR>> To make it simple to use? I agree with Adam here, with the new
>
> It may make one particular case of use simple. It would make understanding
> even this case complicated, and will complicate a lot of other cases of
> which we didn't think now.
DR>> To make it simple to use? I agree with Adam here, with the new
It may make one particular case of use simple. It would make understanding
even this case complicated, and will complicate a lot of other cases of
which we didn't think now.
DR>> overloaded objects you can finally do nice thing
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
> AMT>> I *don't* think it's realisitic to make a person explictly cast
> AMT>> $item->title to a string here. That's not SimpleXML, that's
>
> If it's not a string - definitely it does.
>
> AMT>> ConfusingXML, particularly when this works perfectly fi
AMT>> I *don't* think it's realisitic to make a person explictly cast
AMT>> $item->title to a string here. That's not SimpleXML, that's
If it's not a string - definitely it does.
AMT>> ConfusingXML, particularly when this works perfectly fine:
If you find it confusing - change API of SimpleXML s
All I want to be able to do is this:
$s = simplexml_load_file('rss.xml');
foreach ($s->item as $item) {
print htmlentities($item->title . "\n");
}
That's not *all* I want to do, but this is my three-line test case. If
we can figure out a way to make this work, then I'm a happy camper.
I *don
I favour a), if you mean that (string)$com_object will work.
I'm not so bothered with userspace objects.
b) is just wrong for overloaded objects; if we do some magic
and either hide an existing __toString() method, or call one
with the wrong parameters (it might implement one differently
to the wa
At 01:21 PM 12/1/2003 +, Wez Furlong wrote:
> WF>> The reason I mentioned this is that serialize($obj) is currently
> WF>> meaningless for COM objects, so people are using
> WF>> serialize((string)$obj) to get a string representation.
>
> I don't understand - what is the meaning of serialize((s
On 2003/12/01, at 19:39, Andi Gutmans wrote:
At 12:50 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
> >As far as I'm concerned, if you don't want your object to be
> >auomatically c
WF>> What I'm trying to say is that (string)$obj really should work (as it
WF>> does currently) for overloaded objects because they might not have a
I see where you are heading. I would say it should work for objects with
explicit cast, but not implicitly, then. Meaning, the cast opcode should
c
> WF>> The reason I mentioned this is that serialize($obj) is currently
> WF>> meaningless for COM objects, so people are using
> WF>> serialize((string)$obj) to get a string representation.
>
> I don't understand - what is the meaning of serialize((string)$obj)? What
> should it return?
Just pret
WF>> The reason I mentioned this is that serialize($obj) is currently
WF>> meaningless for COM objects, so people are using
WF>> serialize((string)$obj) to get a string representation.
I don't understand - what is the meaning of serialize((string)$obj)? What
should it return?
--
Stanislav Malys
serialize($obj) is different from serialize((string)$obj);
The reason I mentioned this is that serialize($obj) is currently
meaningless for COM objects, so people are using
serialize((string)$obj) to get a string representation.
--Wez.
> Just a moment here. You imply that serialize() would use
WF>> I'm talking about (string)$obj calling the cast handler in overloaded
WF>> objects; COM does not have a __toString() method, and we shouldn't
WF>> be cluttering up the "method-space" for overloaded objects - what
WF>> if the underlying object has a __toString() method?
If it does, it would be
I'm talking about (string)$obj calling the cast handler in overloaded
objects; COM does not have a __toString() method, and we shouldn't
be cluttering up the "method-space" for overloaded objects - what
if the underlying object has a __toString() method?
I'm not particularly worried about __toStri
I don't think casting an object to a string should work.
I don't see why this is any better than the more verbose $obj->__toString().
Can you please explain in what situation you need __toString() to be called
for SimpleXML and COM automatically and we can try and think of a solution
together. A
On Mon, 1 Dec 2003, Wez Furlong wrote:
> There is no __toString in overloaded objects; thats the reason that the
> (string) cast should work on objects.
Ah, of course :)
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
There is no __toString in overloaded objects; thats the reason that the
(string) cast should work on objects.
> > It *needs* to work so that overloaded objects (simplexml, COM etc.)
> > can have their cast handlers called.
>
> Yeah, it's pretty much needed for those extensions... though I don't
>
On Mon, 1 Dec 2003, Wez Furlong wrote:
> It *needs* to work so that overloaded objects (simplexml, COM etc.)
> can have their cast handlers called.
Yeah, it's pretty much needed for those extensions... though I don't
like these things for normal user defined objects... atleast extensions
should h
It *needs* to work so that overloaded objects (simplexml, COM etc.)
can have their cast handlers called.
Andi wrote:
> No. You would get print toupper($obj->__toString()).
> I am not sure (string) cast on objects should work.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
On Mon, 1 Dec 2003, Stanislav Malyshev wrote:
>>>And if at all we drop the auto-conversion then what we get is:
>>>print toupper((string)$obj);
>>>Wow, no more elegant php - no more typeless php.
>
>PHP was never "elegant" in this meaning - you never could do
>toupper($object) and expect somethin
>>And if at all we drop the auto-conversion then what we get is:
>>print toupper((string)$obj);
>>Wow, no more elegant php - no more typeless php.
PHP was never "elegant" in this meaning - you never could do
toupper($object) and expect something meaningful. I also don't see any
elegancy in it -
At 07:54 AM 12/1/2003 +0100, Marcus Boerger wrote:
Hello Andi,
Sunday, November 30, 2003, 12:08:33 AM, you wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
>>On Fri, 28 Nov 2003, Andrei Zmievski wrote:
>>
>> > On Thu, 27 Nov 2003, Marcus Boerger wrote:
>> > > Convert obj
At 12:54 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> I kind of agree with Andrei here. We discussed in the past that
> __toString() will not propogate to every place in the engine where we check
> for IS_STRING but will only effect print.
> I th
At 12:50 AM 12/1/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
> >As far as I'm concerned, if you don't want your object to be
> >auomatically cast to a string, you shouldn't provide a __toS
At 07:49 AM 12/1/2003 +0100, Marcus Boerger wrote:
Hello Andrei,
Friday, November 28, 2003, 1:59:35 PM, you wrote:
> On Thu, 27 Nov 2003, Marcus Boerger wrote:
>> hellyThu Nov 27 14:24:38 2003 EDT
>>
>> Modified files:
>> /ZendEngine2 zend_API.c
>> Log:
>> Convert ob
Hello Andi,
Sunday, November 30, 2003, 12:08:33 AM, you wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
>>On Fri, 28 Nov 2003, Andrei Zmievski wrote:
>>
>> > On Thu, 27 Nov 2003, Marcus Boerger wrote:
>> > > Convert objects to string if string is required by newer param
Hello Andrei,
Friday, November 28, 2003, 1:59:35 PM, you wrote:
> On Thu, 27 Nov 2003, Marcus Boerger wrote:
>> hellyThu Nov 27 14:24:38 2003 EDT
>>
>> Modified files:
>> /ZendEngine2 zend_API.c
>> Log:
>> Convert objects to string if string is requir
On Sun, Nov 30, 2003 at 01:08:33AM +0200, Andi Gutmans wrote:
> Wrong. __toString() isn't supposed to work in every case the engine expects
> a string.
> You'd probably also want $obj[3] to work as a string offset?
> In this case, maybe we should rename __toString to __toPrintable, because I
> t
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> I kind of agree with Andrei here. We discussed in the past that
> __toString() will not propogate to every place in the engine where we check
> for IS_STRING but will only effect print.
> I think getting into this is a bad idea. If the old parameter passi
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
> >As far as I'm concerned, if you don't want your object to be
> >auomatically cast to a string, you shouldn't provide a __toString()
> >method.
>
> Wrong. __toString() isn't supposed to wo
At 11:59 AM 11/28/2003 -0500, Adam Maccabee Trachtenberg wrote:
On Fri, 28 Nov 2003, Andrei Zmievski wrote:
> On Thu, 27 Nov 2003, Marcus Boerger wrote:
> > Convert objects to string if string is required by newer parameter
parsing
> > since we do this for older parameter parsing does so too.
At 04:59 AM 11/28/2003 -0800, Andrei Zmievski wrote:
On Thu, 27 Nov 2003, Marcus Boerger wrote:
> helly Thu Nov 27 14:24:38 2003 EDT
>
> Modified files:
> /ZendEngine2 zend_API.c
> Log:
> Convert objects to string if string is required by newer parameter
parsing
> since we
1 - 100 of 115 matches
Mail list logo
