""Marcus Boerger"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> helly Wed Feb 15 21:34:21 2006 UTC
> +static inline text_iter_obj* text_iter_to_obj(zend_object_iterator *iter)
> +{
> + static text_iter_obj adr;
> + static int ofs = (char*)&adr.iter - (char*)&adr;
> +
> + return (t
""Marcus Boerger"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> helly Wed Feb 15 21:34:21 2006 UTC
> +static inline text_iter_obj* text_iter_to_obj(zend_object_iterator *iter)
> +{
> + static text_iter_obj adr;
> + static int ofs = (char*)&adr.iter - (char*)&adr;
> +
> + return (
At 00:39 17/02/2006, Sara Golemon wrote:
I gave this some thought as I was designing the overloading approach. I
didn't go there because I actually wanted to allow asymmetry between the
operands as sometimes communative properties don't apply cleanly. Most
obviously in the case of sub/div ops, b
At 02:39 PM 2/16/2006, Sara Golemon wrote:
I gave this some thought as I was designing the overloading approach. I
didn't go there because I actually wanted to allow asymmetry between the
operands as sometimes communative properties don't apply cleanly. Most
obviously in the case of sub/div ops,
I've been in a discussion about class derivation depth and its effects
on the speed of method calls (i.e.: slower). I was wondering if anyone
had come across work (not necessarily for PHP) about class unrolling.
Thanks.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Just thought I'd chime in here with an example that seemed relevant:
cout << "foo" << "bar" << endl;
cin >> input;
Here, << and >> have nothing to do with bit-shifting and have different
meanings. So, maybe one can't assume that '<' and '>' always have to apply
to the typical mathematical ope
Marcus,
one last question ...
> You should never touch the data member of that iterator
does this mean that i should make a copy of whatever i get from
the get_current_data() handler ? There seems to be a bit of inconsistency
in dealing with the current element in the iterators For example, the
> Here, << and >> have nothing to do with bit-shifting and have different
> meanings. So, maybe one can't assume that '<' and '>' always have to
apply
> to the typical mathematical operations (e.g. $pacman < $ghost).
>
That's one reason (one which lends credibility to the overloading kills
readabi
I understand. Aren't you slightly worried about the implications of
making it possible for x>y to have a different meaning than y
In languages where operator overloading is supported, it comes hand
in hand with strict typing, which wouldn't allow for different values
for x>y and y
Zeev
At 19
>
> I am not a big fan of operator overloading because after years of C++
> development I came to the conclusion that the syntactic sugar it
> provided was not worth the debugging hours lost due to hidden magic
> happening. It actually makes it hard to understand certain code when
> you're just re
I am not a big fan of operator overloading because after years of C++
development I came to the conclusion that the syntactic sugar it
provided was not worth the debugging hours lost due to hidden magic
happening. It actually makes it hard to understand certain code when
you're just reading i
> >Enter PECL/operator, which tries to implement operator overloading
> >for objects (and does a decent job at that). In the interrest of
> >ease of use and consistency, every overloaded binary operator is
> >[meant to be] left associative. This is, in the expression expr1
> >op expr2 expr1 g
At 19:23 16/02/2006, Sara Golemon wrote:
Hi, purely selfish request here, I'd like to make a minor change to
the parser... Just a bitty one... You won't even feel it...
Currently, when the parser encounters: expr1 > expr2 it quietly
(and reasonably) switches it around to expr2 < expr1 so th
Hi, purely selfish request here, I'd like to make a minor change to the
parser... Just a bitty one... You won't even feel it...
Currently, when the parser encounters: expr1 > expr2 it quietly (and
reasonably) switches it around to expr2 < expr1 so that is can reuse the
ZEND_IS_SMALLER op.
On Thursday 16 February 2006 13:45, Jochem Maas wrote:
> if that is the logic being applied in the engine then one might to wonder
> why a function such as array_merge() was changed to emit a warning when any
> of it's arguments are not arrays (whereas sometime in the past it used to
> swallow [and
Morten Fangel wrote:
On Thursday 16 February 2006 12:39, Antony Dovgal wrote:
bar = 1;
var_dump($a);
?>
This code is much simpler, huh?
Yeah, I must have been blinded by the lights. It merely resembles
$foo['bar'] = 'baz';
Where $foo is cast as an array without the need to do $foo = array();
Looks good.
On 2/15/06, Jared Williams <[EMAIL PROTECTED]> wrote:
>
> > > > stream_close can return any value it likes... however, it
> > is ignored
> > > > and php_userstreamop_close always returns success to the streams
> > > > layer.
> > > > This is a bug, but should be simple to fix. (voluntee
On Thursday 16 February 2006 12:39, Antony Dovgal wrote:
> $a->bar = 1;
> var_dump($a);
> ?>
> This code is much simpler, huh?
Yeah, I must have been blinded by the lights. It merely resembles
$foo['bar'] = 'baz';
Where $foo is cast as an array without the need to do $foo = array(); first.
So I g
On 16.02.2006 14:32, Morten Fangel wrote:
Hi,
Look at the following example:
---
bar->baz = 'blah';
}
}
$foo = new Foo();
print_r($foo);
?>
--
It results in:
---
Foo Object
(
[bar] => stdClass Object
(
[baz] => blah
)
)
---
$a->bar = 1;
var_dump($a);
?>
Thi
Hi,
Look at the following example:
---
bar->baz = 'blah';
}
}
$foo = new Foo();
print_r($foo);
?>
--
It results in:
---
Foo Object
(
[bar] => stdClass Object
(
[baz] => blah
)
)
---
Foo->bar is never declared as anything but "public" and is therefor
"type-less"
20 matches
Mail list logo
