on't ask me - it's
> somewhere on my TODO list - but i also haven't had the time yet).
I tried FDO with gcc 4.4 on phc generated code, but not on the PHP
interpreter. I've not looked at other compilers either.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
mpelling reimplementation must reimplement large portions of this.
Its no small challenge.
In short, I believe the lack of great speedups from other PHP
implementations (including my own) can be attributed at least
partially to the implementation difficulty and under-specification of
PHP the languag
er on the performance effects of PHP's
memory allocator, which might also interest you.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e nature of
PHP comes from an optimization called "compiled variables". CVs point
to symbol-table entries, but without them, I'm not sure whether we
would still call PHP a register machine. Any thoughts?
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP
emble an AST walker.
I hope I answered what you were looking for. I'm not certain about a
few of my answers, since I've really avoided the interpreter in my
work, but I think most of it is OK.
Best of luck,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or 1
This worked for me, with your commands and program. Since its a linker
error, it seems likely that you haven't installed libphp5.so properly.
You didn't indicate that you ran make install, did you? If so, you may
want to verify that there is a libphp5.so in /usr/local/lib, and that
the patch that
Ilia currently has is close to ideal (the strict semantics are trivial
to understand, the weak ones are the same as whats already here).
Naturally, I might change my position upon seeing the new RFCs.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Devel
ons on the argument that they arent required to
use it. If its in the language, they are required to learn it.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with this logic.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y it might derail what
we have now, but those are not good reasons to stop the discussion.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s that it introduced a new 3rd set of rules, and
this set is not intuitive but rather slightly subjective (reasonable
people might disagree on whether a bool should be weakly converted to
an int, for example). The strict type checks are at least simple, and
the current weak ones are what people ar
)
- write an RFC
- wait for Lukas to finish what he's doing
- new vote, more options (5.3.x/5.4/6.0, Lukas'/yours, make it clear
what we're voting for)
Thanks,
Paul
> On 7-Jul-09, at 7:07 PM, Paul Biggar wrote:
>
>> 2009/7/7 Johannes Schlüter :
>>>
>>
have to vote against it, and urge others to do the same, until
the entire mess is rectified.
Ilia, I respect the work you have put into this, but I would ask you
to withdraw the patch and the vote until these things have been sorted
out.
-1
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
o you intend to use
it?
> Finally I would like to ask to rename this entire feature (including what we
> currently already have) to "type checking" or something other than "hint" in
> the documentation.
Seconded.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
fixed, I think the better option is to ruin things for people calling
things Bool, rather than compromising the feature. (I am assuming that
people are still able to call things \mynamespace\bool -- if not, that
changes things).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals
se
> of a week.
Because nearly everyone wants it, and people think it might actually
get in this time. It was never rejected, people simply couldnt agree
on what it was they wanted, so it never got in. Nearly there,
though...
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Ru
this before. Please roll it into an RFC so we
can think about it (FWIW, the idea that newer version control systems
will somehow change everything makes little sense, so I think a lot of
detail is required here).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the default.
However, it had barely any support, whereas there was great support
for strict by default.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
quot;)
return T_ARRAY;
}
+("bool"|"boolean") {
+ return T_BOOL_HINT;
+}
+
+("string"|"binary"|"unicode") {
+ return T_STRING_HINT;
+}
Someone asked on your last patch about that "unicode", with relation
to 5.3. I think i
rict type
> checking only approach.
I can't see the difference between your proposal and the conclusion I
reached yesterday?
(which was that there is a near consensus around strict checks by
default, with casts allowed with some syntax).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
for the weak check. The idea
would be that if you hinted "(int)", you could be guaranteed that you
got an int. The syntax was suggested (I believe, it wasn't my
suggestion) to look like casting.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime
w_null;
zend_bool pass_by_reference;
zend_bool return_reference;
I think you could make this work for 5.3, if it used the old
"zend_bool array_type_hint". A zend_bool is 8 bits, so that's plenty.
It would be a little bit messy, but I'm fairly confident it c
Ilia Alshanetsky
>
> P.S.
>
> It should be noted that this is not the first idea for type hints, that
> credit goes to Hannes Magnusson who had posted a similar patch on the
> internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
> hinting patch for PHP
Hi Ilia,
On Thu, Jul 2, 2009 at 3:35 AM, Paul Biggar wrote:
> Thanks to Ilia for getting to ball rolling on scalar type hinting.
> I believe I have a solution that caters to each crowd, without being
> too complicated.
My impression is that there only minor support for the "flex
trict as default doesn't seem appropriate in php. But if it does,
> this syntax could be interesting:
>
> function($quantity)
> function(int $quantity) STRICT type
> function(~int $quantity) paul's (S) casting
This is also a nice, internally-consistent syntax.
If you h
ween
the term "type hinting" and "strict interfaces". I would be happier if
you renamed your patch "optional strong scalar type checking", which
is what it is.
I have described a system that allows "strong type checking", "type
hinting", and "typ
On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote:
>
> On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
>> I think you might not have read what I suggested (it is different than
>> the one I emailed to you privately). What you want is fully supported.
>> If you must be pas
bout it changing PHP, or about libraries
using strict type hints. We are worried that libraries will use no
hints, because the ones on offer are not useful to them.
Please, take a read over my full proposal. I think you'll find it that
it supports everyone's features without compromise.
Th
, therefore the type hints are not
checked, and this is fine.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
w.zend.com/
> (408)253-8829 MSN: s...@zend.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-> MyObj = FAIL
* This is a suggested semantics for (H)
Whatever is passed will be cast to whatever you ask for, using
existing casting rules, even if thats stupid.
* This is a suggested semantics for (H)
If you ask for X, it must be X, except:
object with __toString() -> string = string
Anything else is FAIL (which I believe is an E_RECOVERABLE_ERROR).
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Jul 1, 2009 at 10:53 PM, Hannes
Magnusson wrote:
> On Wed, Jul 1, 2009 at 23:36, Paul Biggar wrote:
>> On Wed, Jul 1, 2009 at 10:23 PM, Hannes
>> Magnusson wrote:
>>> On Wed, Jul 1, 2009 at 23:07, Paul Biggar wrote:
>>>> So, what you're saying i
On Wed, Jul 1, 2009 at 10:23 PM, Hannes
Magnusson wrote:
> On Wed, Jul 1, 2009 at 23:07, Paul Biggar wrote:
>> So, what you're saying is, the patch already handles coercion? If
>> that's the case, then problem solved.
>
> The patch offers scalar type _hinting_. Not t
ly fixed.
>
>
> zend_parse_parameters(... abcdefg)
> is the same as
> function($a, $b, $c..) { $a = (int) $a; $b = (string) $b; $c = (array) $c...}
So, what you're saying is, the patch already handles coercion? If
that's the case, then problem solved.
(But I didnt think
se to do so. (ie reject non-numeric
>
> That (coercion) is what internal functions do, but not what the proposed
> patch does (except for "numeric" hint).
Right. I think we're arguing on the same side. I'm just saying that if
the manual says 'int', we should be
ject non-numeric
strings for ints).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ena wrote a type
> hinting patch for PHP that is available on wiki.php.net.
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ecific stuff. You're not
compiling here.
- use SCCP for constant propagation. Use the DCE algorithm from
"Engineering a Compiler" by Cooper/Torczon.
Anyway, it sounds like you really know what you're at. You must have
been studying. What texts are you using? If you don't ha
Hey Graham,
Sorry for the delay, I meant to send this over the weekend.
On Thu, Jun 25, 2009 at 2:50 AM, Paul Biggar wrote:
>
> When I say model, I mean that we "abstractly" "interpret" the program.
> Its like we're interpreting it, but we don't have the ac
that describe the general approach, try
http://portal.acm.org/citation.cfm?id=178264 and
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.52.2637.
(FYI, people without ACM access can nearly always find those papers by
googling the title).
Paul
>
> Nuno
>
--
Paul Biggar
would only take about an hour, I think).
I think that's probably enough for now. I'll talk about those 3
analyses tomorrow. Questions and feedback are welcome (especially if I
didn't explain clearly enough - academic stuff can be tough to explain
to a lay audience).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
p
> size:
> loop: 0.00489 sec (100%)
> spl: 0.76226 sec (15588%)
> DIFF: 0.75737 sec
That is interesting. Alexander is making a place for microbenchmarks,
so we might copy this at some point.
Thanks,
Paul
> Am 21.06.09 20:49 schrieb "Paul Biggar"
#x27;G';
> }
>
> $iterator->next();
> }
>
> $e = microtime(true);
>
> $ti = round($e-$s, 5);
>
> $diff = round($ti/$tl*100, 0);
>
> print "spl:\t$ti sec ($diff%)\n";
> print "DIFF:\t".($ti-$tl)." sec\n";
> flush();
>
>
> ?>
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
alling
$reduce->set_phc ("phc --include") it would work, but I haven't tried
it.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Jun 10, 2009 at 11:10 PM, Paul Biggar wrote:
> I wrote a tool which automatically. It uses the delta debugging
I sent this prematurely. It should read
"I wrote a tool which reduces test cases automatically."
> algorithm, but is very much faster than delta, since it knows
rally. Please report any problems to me.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Sebastian,
On Sun, Jun 7, 2009 at 6:56 AM, Sebastian
Bergmann wrote:
> Paul Biggar schrieb:
>> They have a paper on PHP memory usage.
>
> Link? I am collecting papers that deal with PHP at
> http://delicious.com/sebastian_bergmann/academic_paper+php
This is great. Below is
BM Toyko researches who work on (or maybe close to)
Project Zero will be there, and might have interesting ideas. They
have a paper on PHP memory usage.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Ralph,
On Fri, Jun 5, 2009 at 5:59 PM, Ralph Schindler wrote:
> Similarly described in this bug:
>
> http://bugs.php.net/bug.php?id=42106
You might also find this relevant: http://bugs.php.net/bug.php?id=44462
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Intern
Hi Graham,
On Fri, Jun 5, 2009 at 12:03 PM, Paul Biggar wrote:
>> Why not start off with the big stuff, dataflow. I personally believe that
>> working out good data flow for PHP is key to getting good optimizations. But
>> you are right, its a very tricky thing to do
ore the 47:00 mark (slides at
https://www.cs.tcd.ie/~pbiggar/paul_biggar_google_18_mar_2009_notes.pdf).
That highlights most of the problems, and vaguely hints at their
solution. We can go into much greater detail on the solutions after.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Develo
nto $foo " is not safe, as GLOBALS['foo'] may not be
the same variable as $foo ($GLOBALS may be unset, and indeed, there
may be good reasons to do so).
I'm also wondering what the optimizations are on fcall? I couldn't make it out.
That's quite a lot, but its every
On Tue, May 26, 2009 at 7:31 PM, Hannes Magnusson
wrote:
> On Tue, May 26, 2009 at 20:21, Paul Biggar wrote:
>> "The link below to the Oliver document appears to be broken. Here is
>> one that works: http://citeseer.ist.psu.edu/oliver93decision.html";
>
> That lin
On Tue, May 26, 2009 at 7:31 PM, Hannes Magnusson
wrote:
> On Tue, May 26, 2009 at 20:21, Paul Biggar wrote:
>> "The link below to the Oliver document appears to be broken. Here is
>> one that works: http://citeseer.ist.psu.edu/oliver93decision.html";
>
> That lin
elow to the Oliver document appears to be broken. Here is
one that works: http://citeseer.ist.psu.edu/oliver93decision.html";
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi folks,
On Tue, May 5, 2009 at 6:19 PM, Davide Mendolia wrote:
> contribute to php-benchmark
> http://cvs.php.net/viewvc.cgi/php-benchmarks/
>
> My first proposal(raytracer) was committed by Paul Biggar
Do I need to vouch for this? If so, vouched.
Thanks,
Paul
--
Paul Big
Hi folks,
On Tue, May 5, 2009 at 6:19 PM, Davide Mendolia wrote:
> contribute to php-benchmark
> http://cvs.php.net/viewvc.cgi/php-benchmarks/
>
> My first proposal(raytracer) was committed by Paul Biggar
Do I need to vouch for this? If so, vouched.
Thanks,
Paul
--
Paul Big
generating any code that binds to that definition since
> such code would not be cacheable.
>
> These are three independent challenges, without overcoming each of them I do
> not see how virtual table would be helpful.
Yes. As I replied to Dmitry, I clearly wasn't thinking when I
sugg
of dynamic issues anyway. E.g. parent class may be
> changed or loaded from different file.
This is what I'm getting at. How can the parent class be changed? I
can see that it might be deferred, but I don't see how it can be
changed once it's set.
Thanks,
Paul
--
Paul Bigga
is not. I don't know what I was
thinking.
So it looks like the best way forwards is still the OP's patch?
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that almost anything else would be better (including the OP's patch).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
se the
recompilation techniques that Self had. You can use lookup caches,
which is exactly what the original patch was.
FWIW, since PHP has a static inheritence chain, the best approach
seems to be to build a virtual dispatch table, instead of a hashtable
for functions. However, there might be some
the bug. I expect they'll be back to me within a day or
two, if you prefer to wait for further confirmation.
FWIW, I like the new patch better than my hack. However, I don't
understand the how it works from the comment (that bit of acinclude is
very shoddily documented in general).
Hi folks,
Could I get someone to look at http://bugs.php.net/bug.php?id=47468?.
It includes a patch which is confirmed to fix the problem.
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
extensions which don't have to be rebuilt per-PHP version.
>> This is similar to JNI.
I'm working on this a little more atm. When you were considering it
before, was anything committed to paper/email? If so, I would be
interested to see any thoughts or discussions.
Thanks,
Pau
2009/4/1 Johannes Schlüter :
> Hi,
>
> On Wed, 2009-04-01 at 16:16 +0100, Paul Biggar wrote:
>> I think that to handle more complex cases we need the kind of
>> information which makes it straightforward to easily generate code to
>> make a seamless interface between C a
ppreciate it.
> This API would need to be designed in great detail and we would need to make
> sure it is long lasting.
I could not agree more.
> My 2 cents.
> Andi
Thanks for the input, the more the merrier :)
Paul
>
>> -Original Message-
>> From:
2009/4/1 Johannes Schlüter :
> Hi,
>
> On Wed, 2009-04-01 at 14:24 +0100, Paul Biggar wrote:
>> > Moreover, in your example in the wiki you don't include how you would do
>> > parameter parsing. Or do you rely on the code generator to look at the C
>> &g
ly), please encourage the
>> student to look at this. Finally, if anybody is interested in helping
>> mentor this as part of the GSOC, I'd be grateful for the help (I have
>> to start writing my thesis soon).
>>
>> Thanks,
>> Paul
>
>
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
SPL (reserved for SPL)
PEAR (reserved for PEAR)
PECL (reserved for PECL)
Though we could add a simple check to the parser, I see no real need
if we make this list conspicuous enough. Once the users have been
warned, we are in a better position to administer their kick to the
nuts.
Paul
--
Paul Big
it late, there are only 3 days left to apply), please encourage the
student to look at this. Finally, if anybody is interested in helping
mentor this as part of the GSOC, I'd be grateful for the help (I have
to start writing my thesis soon).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.co
ion?
>
> Because false is not an error condition. It's a legitimate value, which can
> be normal answer for many functions.
Is this not the case for NULL?
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
m interested in the design decision). If FALSE is the error
condition, whats the point in a separate NULL error condition?
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Contributing benchmarks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
sing
> null would be best treated as the same as passing nothing?
NULL is a value. There is no way to tell that when you pass NULL, you
actually intended to pass nothing and use the default value.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Developme
x an
expression, but currently PHP can only index variables. Personally, it
seems like a bug, but I'm not sure whether or not there's consensus.
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
already, but not so lucky fining anything
> useful for newbies like myself.
It looks like http://developers.facebook.com/phpembed/ will give you
what you're looking for.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
w you get on,
Paul
On Wed, Sep 10, 2008 at 10:39 PM, Santi Saez <[EMAIL PROTECTED]> wrote:
> Jani Taskinen escribió:
--
Paul Biggar
[EMAIL PROTECTED]
R_VERSION).bundle: $(PHP_GLOBAL_OBJS)
> $(PHP_SAPI_OBJS)
> $(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS)
> $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o)
> $(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) -o $@ && cp $@
> libs/libphp$(PHP_
ees, as you say,
at great expense. I am hoping that the third will be casting, which
provides guarantees, at no call-time expense.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ammers have. I still wouldn't
> like it too much but at least it would make sense :)
As I read it, these convert the parameter to the expected type, if it
is not already, and fail when this is not possible. All thats missing
is scalar and numeric to be consistent with the is_*(), and its
perf
sistent" to replace "I like it",
except in the sense that I like consistency. It makes no sense to find
that you do not have an int, when you specify you must. I very much
mean consistency, and do not have a preference for the approach,
except that only one seems perfectly consist
s should mimic this behaviour. Not doing so would
be very inconsistent, and so confusing.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
appropriately. I would settle for the current proposal, but if
you're going to make the language weakly-typed, which it is, it is
more appropriate to keep this in line with the rest of the language.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mai
dicated on the IS_LONG
type only.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
trict.
> > > Otherwise, it makes more sense to not use it.
> > >
> > > Examples, patches and tests: http://wiki.php.net/rfc/typehint
> > >
> > >
> > > --
> > > Regards,
> > > Felipe Pena.
> > >
> > &g
; --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
your suggestion clearly
is. However, it is more consistent than, and therefore preferable to,
the current patch.
Thanks,
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ous patch,
> and now it is using only the "(type)" notation. Hence, that
> implementation doesn't make any BC break.
>
>
> Examples, patches and tests: http://wiki.php.net/rfc/typehint
>
>
> Thanks.
>
> --
> Regards,
> Felipe Pena.
>
>
ch
does not include time spent incrementing and decrementing reference counts. As
a result of the re-use of the PHP run-time, phc is afflicted with the same
problem.
Thanks in advance,
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscr
On Dec 22, 2007 12:02 AM, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> 2007/12/21, Paul Biggar <[EMAIL PROTECTED]>:
>
> > > 4) find all function calls (not method calls) which are not keywords
> (array,
> > > isset, unset, list, etc) and prefix them wit
t be more complicate than
> it seems if the method has to be careful to avoid creating possible name
> clashes.
>
> If anyone has a comment on this, I'll be more than grateful if you share.
If you need any advice, on this, please let me know.
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Stanislav wrote me a very useful reply to my CV questions. I wonder if
anyone has time to give me a quick note on backpatching, and what that
is?
On 9/23/07, Paul Biggar <[EMAIL PROTECTED]> wrote:
> What is backpatching?
> Is it related to compiled variables, or are they differ
single CV for each $a in a scope, or is there one per
bytecode operand? In other words, in a function which uses $a a lot,
does it look it up for each bytecode which uses $a, or only once for
that function?
Thanks for the quick response,
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP
r are they different concepts?
Why was backpatching necessary?
Is this performance related, and what performance impact does backpatching have?
Thanks in advance,
Paul
--
Paul Biggar
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
95 matches
Mail list logo
