che to be cleared out in case memory is getting low.
>
>
>
> Thoughts?
>
>
>
> Thanks,
>
> Software Developer
>
> Nathan Bruer
>
>
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ay to
> implement. Maybe also "autoboxing" is the wrong word, as this RFC simply
> suggests to map primitive types to some objectual syntax.
>
> == References ==
> This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of
> nicer syntax.
>
> [[
>
an excellent attitude!
>
> I'm all for fixing broken stuff. Now if only we can find more people that
> actually fix stuff and less people that have time to post xkcd comics?
>
>
> ---
> Sherif,
> The always happy, never grumpy guy...
--
Tom Boutell
P'unk Avenu
ntained by the PHP community. I'm not sure if what's in
the PHP tarballs is different from what's on bitbucket and to what
degree.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
If symbols could use the sign bit or otherwise distinguish from typical integer
keys one would have some hope of meaningful debugging output. I don't think it
makes sense to mix integer keys and symbol keys but being able to differentiate
them for debugging purposes would be great. However since
Sure. I wasn't asking for myself but rather in the context of how
close 5.3 is to being reasonable to deprecate.
On Mon, Dec 10, 2012 at 3:55 PM, Pierre Joye wrote:
> hi,
>
> On Mon, Dec 10, 2012 at 9:52 PM, Tom Boutell wrote:
>> Has APC's PHP 5.4.x support matured yet
(Really shouldn't run 5.4, rather)
On Mon, Dec 10, 2012 at 3:52 PM, Tom Boutell wrote:
> Has APC's PHP 5.4.x support matured yet to the point where folks are
> comfortable there's no environment in which you really shouldn't run
> 5.3?
>
> On Mon, Dec 10,
ing 5.3.3 I don't see how doing anything besides
> going into "bugfix mode" is going to benefit those users, or is there a
> 6.4 planned?
>
> Greetings,
> Florian
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
gt;> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >>
>> > I agree. This would definitely be a nice feature to have, at least for
>> the
>> > Windows build.
>> >
>> > --Kris
>>
>>
>>
>> --
>> Pierre
>>
>> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
le PHP with it?
>>
>> Good luck.
>>
>> P.S. I'm not a GD developer.
>
> Hi Alexey,
>
> I just tested it on PHP 5.4.4 on OSX and I can confirm, that the issue is
> still present.
> (used font: Open Sans Regular/Bold/Italic, screenshots:
> htt
act - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>
>
>
> --
>
t;>
>>>> I think those who never want to use it (PHP 6 purists) shouldn't have
>>>> to have their binaries bloated by legacy code. It would also mean that
>>>> the legacy implementation can be developed away from the new core, and
>>>> not have any (negative) influence on it.
>>>>
>>>>
>>>> --
>>>> PHP Internals - PHP Runtime Development Mailing List
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Heh... passing a little judgment there on the design of frameworks,
ORMs, etc. are we?
On Wed, Jul 4, 2012 at 10:41 AM, Rasmus Lerdorf wrote:
> On 07/04/2012 07:37 AM, Tom Boutell wrote:
>> Hmm, but the stat=0 optimization is a major one; a cache that didn't
>> offer it wo
;> would be the ability to drop all the #ifdef checks for the different
>> engine versions since we would obviously only need to support the
>> current one.
>
> We will still have to support current supported versions via PECL.
>
>
> Cheers,
> --
> Pierre
>
>
the case.
>
> I for one would like to kill all the legacy features or too specific
> features which are really unusable by any common developers.
>
> Other developers may disagree but it makes very hard to maintain APC.
>
> Cheers,
>
>> 2012/7/3 Tom Boutell
>>
>
On 07/03/2012 07:13 AM, Tom Boutell wrote:
>> This one:
>>
>> *** glibc detected *** /usr/local/bin/php-cgi: double free or
>> corruption (out): 0x7f9d6ce2c080 ***
>> === Backtrace: =
>> /lib/libc.so.6(+0x77806)[0x7f9d679be806]
>> /li
h build
of PHP 5.4.4 and apc installed immediately thereafter via pecl.
Is this fix actually released yet?
Thanks.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
would be highly useful.
>
> try {
> require( 'path/to/file.php' );
> } catch ( PARSE_EXCEPTION $e ) {
> // some logging then pretty death
> }
>
> Most of the time you'd never want to resume after such an
> exception Most of the time.
>
> In any ev
>>>>> think of adding generator support to PHP.
>>>>>
>>>>> If you don't know what generators are you should have a look at the
>>>>> "Introduction" section in the above RFC or in the Python documentation
>>>>>
(I'm not questioning that APC makes an enormous difference. That's
painfully obvious from 100 miles away on our servers (: )
On Thu, May 24, 2012 at 11:23 AM, Tom Boutell wrote:
> I've seen this statement before about the impact of caching the actual
> compilation (or m
>
> The savings from parsing is chump change compared to disk I/O.
>
> It's also trivial chump change to implement.
>
> Ever ounce counts :-)
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www
at 11:18 AM, Mohammad Saleh
>> wrote:
>> >
>> > All,
>> >
>> > I was looking for a standard benchmark script that I could run with and
>> > without apc caching to see the general gains.
>> > Is there something that is used by
ndard benchmark script that I could run with and
> without apc caching to see the general gains.
> Is there something that is used by the internals team for such tests?
> If not, are there any recommendations?
>
>
> Thanks,
> Mohammad
>
--
Tom Boutell
P'unk Avenue
2
nch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
t;> properties would have to be stored in a key/value form internally...
>>> but if you look at modern PHP software, dynamic properties is actually
>>> something very few people use.
>>
>> This is not true.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
n
all that close of course.
On Mon, May 21, 2012 at 3:25 PM, Tom Boutell wrote:
> Thanks for clarifying that. Sounds like a huge win.
>
> On Mon, May 21, 2012 at 3:13 PM, Gustavo Lopes wrote:
>> On Mon, 21 May 2012 20:47:51 +0200, Rasmus Schultz
>> wrote:
>>
>>
properties (i.e. assigning undeclared properties) or
> if it otherwise requested. Otherwise, they're stored in an array.
>
> --
> Gustavo Lopes
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
ect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
This whole business of bending over backwards to prevent injection of php when
apache is misconfigured just encourages apache misconfiguration IMHO. Smart
people are protecting you, you don't have to do these things right, don't worry
about it!
Sent from my iPhone
On May 5, 2012, at 1:50 PM, "
t; On Tue, Apr 24, 2012 at 4:00 PM, Tjerk Meesters
> wrote:
>>
>>
>> On 25 Apr, 2012, at 5:42 AM, Kris Craig wrote:
>>
>> > On Tue, Apr 24, 2012 at 1:10 PM, Tom Boutell wrote:
>> >
>> >> * The RFC starts off immediately talking about file
t;
>> https://wiki.php.net/rfc/phpp
>>
>>
>> I also want to know if this is sufficient to satisfy some of the concerns
>> that have been raised about being able to implement this into existing
>> frameworks that use a more "tangled" architecture.
>>
>
at needs clarifying:
>
> https://wiki.php.net/rfc/phpp
>
>
> I also want to know if this is sufficient to satisfy some of the concerns
> that have been raised about being able to implement this into existing
> frameworks that use a more "tangled" architecture.
>
> Thanks! =)
t switches behavior, you then get a portability problem --
> code runs fine in one context, but not the other.
>
> --
> Matthew Weier O'Phinney
> Project Lead | matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.c
y habit to get into.
>
> One idea for everyone on the list is a kind of self-imposed list posting
> quota. For every commit, bug comment, doc contribution, infrastructure
> contribution you make you get a post to the list.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime D
I think updating your RFC to cover the broad points that have changed
is worth it, even if small differences will continue to be expressed
about the syntax.
2012/4/16 Kris Craig :
>
>
> 2012/4/16 Tom Boutell
>>
>> Kris, you have been talking recently about allowing for a mod
esn't
>> sound
>> useful to me, but I'd be willing to put it in if enough of you wanted it.
>>
>>
>> PHP_SCRIPT_TYPE_CODE_FILE (PHP_SCRIPT_TYPE_NORMAL &
>> PHP_SCRIPT_TYPE_TAGLESS)
>>
>> - The entire script is assumed to be PHP cod
other hand
> if the vote is negative, we can save a significant amount of time and
> effort, and can concentrate on more plausible subjects.
>
> Cheers,
>
> Arpad
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Dev
s probably time to write an updated version of your RFC so
we can figure out if we're developing common ground here.
2012/4/16 Kris Craig :
>
>
> 2012/4/16 Tom Boutell
>>
>> Also, Kris's proposal requires that an additional flag be tracked all
>> the way down th
This has been added in version 1.1.1 of the
source_files_without_opening_tag RFC:
https://wiki.php.net/rfc/source_files_without_opening_tag
On Mon, Apr 16, 2012 at 5:25 PM, Tom Boutell wrote:
> I think the 'as' solution is smart.
>
> On Mon, Apr 16, 2012 at 3:54 PM, Kris Crai
clude 'foo', $someThing));
>>
>> Or is this a one-argument include and should be interpreted as
>>
>> func((include 'foo'), $someThing);
>>
>> In my eyes such an ambiguity renders any proposal to add another
>> argument to include complet
does an image with embedded tags uploaded through a
> security hole) .
> It's clean (although some BC break would occur, but I think it's minor),
> simple and 100% voluntary. Any decently written 3rd party library will work
> without any modification (well, removing trailing ?> is a matter of simple
> script if required, but I haven't seen people putting ?> in the end for
> years).
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that were loaded before this .phpp file are still permitted to
load things, including when acting as autoloaders on behalf of .phpp
code... my head hurts. This cannot be the cleanest way to solve the
problem.
2012/4/16 Tom Boutell :
> Oh I see. Yes, this is one of the reasons I don't li
compromise, one that will get
us what we want (an ever increasing percentage of .phpp files) without
making enemies and generating opposition along the way to that better
place.
On Mon, Apr 16, 2012 at 9:24 AM, Arvids Godjuks
wrote:
> 16 апреля 2012 г. 16:09 пользователь Tom Boutell написал:
>
&g
These tools already strip wrote:
> I posted the bellow text in other thread, but i should have it post here,
> so i'm reposting it to this thread.
>
> Well, it's time for me to remind about the techique many use (and some
> frameworks provide it out of the box) - the application file concatinati
We could vote on whether we like the idea in principle, with the condition that
the final proposal pass separately as a fully detailed rfc. That way you are
telling the authors of these rfcs whether to keep trying and in what direction,
but you are not forced to accept the end product. I would w
net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
at 1:28 PM, Tom Boutell wrote:
> Wouldn't this be a significant performance hit when multiplied by
> every class file in a project?
>
> On Fri, Apr 13, 2012 at 10:15 AM, Matthew Weier O'Phinney
> wrote:
>> On 2012-04-13, David Muir wrote:
>>> On 13/04/12 14:
| matt...@zend.com
> Zend Framework | http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The meaning is unclear, and it doesn't let you specify error reporting.
Sent from my iPhone
On Apr 12, 2012, at 9:37 PM, Yasuo Ohgaki wrote:
> 2012/4/13 Arvids Godjuks :
>> Well, i can say that any template engine that is not a pure php extension
>> does template inclusion via an include of a f
If this is a pecl module library developers cannot use it and trust that on php
5.n, it just works. That would fork the language in an undesirable way. It
should be a core feature, no ini flag, no sometimes-there module.
Sent from my iPhone
On Apr 12, 2012, at 10:00 PM, Yasuo Ohgaki wrote:
>
as PHP_. No reason this couldn't be deviated from, as
>> UPLOAD_* and ZEND_* have their own spaces, but INCLUDE_* seems pretty
>> generic to reserve and seems safer under PHP_* to me. This is a small
>> detail I don't feel strongly about, but it is a detail that should be
>> considered.
>
> Yeah, i'm not sure. Would like for more people to chine in. Its more
> cosmetic though. I just would prefer it not to be sinething like:
> PHP_INCLUDE_PURE_PHPCODE. It's a lot to type! Also long keywords make
> it difficult to stick to 80 characters per line.
>
> Luke
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be safe.
I wasn't aware of those guidelines. This makes sense to me.
PHP_INCLUDE_ONCE, then?
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ip has already sailed with regard to having a .php frontend. If you don't
> wany any .php frontend in your code, then simply don't use a library that
> relies on it. Simple as that. If you so want to include the library, then
> simply make sure that there are no .php/HTML fro
|
> [Included .php/HTML Script]
> | |
> | |
> {Included .phpp Script} [Included .php/HTML Script from
> Framework/Library]
This is convoluted and forces me to write a .php frontend. Surely that
is not your goal.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
wi
On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott wrote:
> - I would like to see an INCLUDE_SILENT method to prevent warnings from
> being thrown with include/include_once statements. Currently doing
> something like @include "/path/to/file.php"; not only hides these
> warnings, but warnings/errors/noti
Think through what will likely happen in the real world under various
proposals, and not just what would be most pure (:
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
original new require_path keyword with a second,
optional parameter to the standard include/require family of keywords
* Replaced an array of options with a bitwise OR of options
* Changed the proposed filename extension from .phpc (which apparently
is in use somewhere, maybe?) to .phpp ("p
one can have so much free time in his hand to write such
> useless things.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://w
Yes, those points (keep the same keywords, optional second parameter,
OR'd constants) have been made a few times, and I plan to edit the RFC
accordingly.
On Tue, Apr 10, 2012 at 10:53 AM, Luke Scott wrote:
> Tom,
>
> On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote:
>
>> T
" first part can be approved sooner than the second, or maybe the entire RFC
> would not be approved because the second.
>
> On Tue, Apr 10, 2012 at 9:35 AM, Tom Boutell wrote:
>>
>> An important clarification: the RFC has two parts, NOT two options.
>> Yasuo Oh
sing way to put forward a concept the original author does not
agree with.)
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
There is probably a performance hit there when your view offers a lot
of methods, but that is nevertheless a very clever solution (:
On Mon, Apr 9, 2012 at 9:51 PM, Jared Williams
wrote:
>> -Original Message-
>> From: Tom Boutell [mailto:t...@punkave.com]
>> Sent: 0
On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott wrote:
> Given that an autoloader just has the class name with the attached
> namespace, how is it to know whether or not to load a .php file or a .phpc
> file? I'm not going to add a stat in my autoloader (file_exists) just to
> check for the existence o
On Mon, Apr 9, 2012 at 8:27 PM, Luke Scott wrote:
> Tom,
>
> On 4/9/12 4:47 PM, "Tom Boutell" wrote:
>
>>Let me be very clear about that... I am NOT proposing that >the top be mandatory in a file loaded in code mode! I don't want to
>>type it ever ag
Let me be very clear about that... I am NOT proposing that wrote:
> On 4/9/12 3:53 PM, "Tom Boutell" wrote:
>
>>I see why you want to allow >mode,' rather than disallowed in code mode. But your purpose is to
>>allow legacy code to be autoloaded without knowing
f your comments are pretty close to alterations I plan to
make to the RFC.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I see why you want to allow wrote:
> Tom,
>
> On 4/9/12 3:17 PM, "Tom Boutell" wrote:
>
>>My original goal was to stop typing >includes at the top. I think it's entirely reasonable to achieve it
>>with an option to the require keywords for this purpose a
; in a file in pure code means only one > at the top.
>>
>>
>> A flag on require/include is acceptable to me, as long as the default
>> mode is configurable in the php.ini file (when none are specified).
>
>
> Perhaps we should split that into a separate RFC? I.e
I'm not sure you're wrong about this, but it's definitely an ironic
suggestion (:
On Mon, Apr 9, 2012 at 5:22 PM, Kris Craig wrote:
>
>
> On Mon, Apr 9, 2012 at 2:03 PM, Tom Boutell wrote:
>>
>> As others explained before the RFC was drafted, file extensions
t; a template engine will be met with a veto by the core developers, or maybe
> even another suggestion by the trademark owner of PHP that he will not allow
> the PHP name to be used on such a language.
>
>
>
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Agreed, I will respond only on the RFC thread.
On Mon, Apr 9, 2012 at 4:45 PM, Kris Craig wrote:
>
> On Mon, Apr 9, 2012 at 4:11 AM, Pierre Joye wrote:
>>
>> hi!
>>
>> On Mon, Apr 9, 2012 at 12:48 PM, Tom Boutell wrote:
>> > I agree, which is why the
ature X in this code, which doesn't exist in version Y anyway,
so I may as well take advantage of not having to type wrote:
> From: Tom Boutell [mailto:t...@punkave.com]
>>
>> On Mon, Apr 9, 2012 at 12:43 PM, John Crenshaw
>> wrote:
>> > interoperability is som
for long (:
On Mon, Apr 9, 2012 at 1:49 PM, Matthew Weier O'Phinney
wrote:
> On 2012-04-09, Tom Boutell wrote:
>> There's a reason I didn't try to kick this out as a fully formed RFC (:
>>
>> The choice of @ is a nonstarter, yes. I forgot that > start co
rrors by the actual file -- I think we can all
> agree @include is counter productive since it does much more that
> suppress warnings thrown by include (even parse errors!).
>
> Luke
>
>
>>
>> -ralph
>>
>>
>>
>> On 4/9/12 12:23 PM, Tom Boutell w
On Mon, Apr 9, 2012 at 12:43 PM, John Crenshaw wrote:
> interoperability is somewhat reduced in the sense that all 3rd party code
> would have to be checked for the http://www.php.net/unsub.php
Also, your objection - that 'require_code' is confusing - would most
likely be an issue for a handful of people who write autoloaders.
Those clean PHP class files are almost always autoloaded.
On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell wrote:
> I see what you're saying, but
at
seems like a very hard sell.
On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott wrote:
> On Apr 9, 2012, at 9:16 AM, Tom Boutell wrote:
>
>> It sounds like you are proposing to gradually kill the use of PHP for
>> templating entirely, which I don't think is something people would
hat is at least how I would prefer the "code" mode as most
> non-template files only start with compatibility.
>
> If you must add keywords it should be something like require_template
> NOT require_code/require_file. Templates are the exception, not the
> norm.
>
> Luke S
There's a reason I didn't try to kick this out as a fully formed RFC (:
The choice of @ is a nonstarter, yes. I forgot that wrote:
> -1.
>
> PHP doesn't need more magic.
>
> On Mon, Apr 9, 2012 at 4:53 PM, Nikita Popov
> wrote:
>>
>> On Mon, Apr 9, 2
John, please take a look at the RFC:
https://wiki.php.net/rfc/source_files_without_opening_tag
I am not proposing any backwards-incompatible changes that would
affect existing code. Code that isn't interested need not ever take
advantage of the feature and can interoperate with code that does. I
reasonably expected
implode() to call the usual PHP function and not a method. Plus it's
probably a real pain to implement in general.
Thoughts?
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
implement and focus on the case where it
bugs me (creating libraries of class files), but I'd be happy to see a
way for .phpc to be the entry point / frontend controller / standalone
script as well. As you say it must be done with SAPI options (the CLI
included), not hardcoded file extension che
ing out in "PHP mode" so the opening true);
In addition, a convention (not a requirement checked by the code)
would be encouraged: PHP source code files without an initial https://wiki.php.net/rfc/source_files_without_opening_tag
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
I think separating these rfcs makes sense, thanks.
Sent from my iPhone
On Apr 9, 2012, at 2:17 AM, Yasuo Ohgaki wrote:
> Hi Tom,
>
> It's better to distinguish security related issue and others.
> Therefore, I listed Moriyoshi's proposal to RFC list and put
> my proposal in it. His proposal is
Craig wrote:
> Tom,
>
> On Sun, Apr 8, 2012 at 4:14 PM, Tom Boutell wrote:
> Thanks. However, would you please fix the summary on the RFC's page to
> match the summary in the actual RFC? As you have written it, it
> implies that support for not the case.
>
> As for
n when
> set specificaly and it would break if something set differently. PHP just got
> rid of it and you want to introduce a new optional feature that will change
> how PHP behaves.
>
> 09.04.2012 9:03 пользователь "Yasuo Ohgaki" написал:
> Hi,
>
> 2012/
I agree, there should be no limiting of unrelated language features to
half-protect people who can't plan where uploads go.
Sent from my iPhone
On Apr 9, 2012, at 6:11 AM, Ferenc Kovacs wrote:
>
> On Sat, Apr 7, 2012 at 10:48 PM, Yasuo Ohgaki wrote:
> Hi,
>
> The only valid reason for remov
> I prefer to use switch, since security countermeasure is
> better to be enforced by switch.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
>
>
> 2012/4/9 Tom Boutell :
>> Moriyoshi was kidding, as near as I can tell (:
>>
>> To take
gt;> source files without an opening >>
>>> https://wiki.php.net/rfc/source_files_without_opening_tag
>>>
>>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure
>>> what the requirements are to get it added to the "Under Discussio
gt;
> As I mentioned already, injecting malformed PHP scripts into files
> is too easy compare to other languages. This could be improved
> by simple modification and we can maintain compatibility with it.
>
> I don't see anything wrong here.
>
> Yet another PHP script injection example.
> There are many applications that store user inputs in $_SESSION.
> Attacker can inject PHP script into $_SESSION, then locally include
> it. This is easy since attacker knew their session ID and path to
> session file is can be guessed easily. All attacker has to do is
> finding a vulnerable include()/require() to attack.
>
> Regards,
>
> --
> Yasuo Ohgaki
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
req by posting the RFC here, so go
> ahead and add it. In the future, remember there's also an "In Draft" status
> for RFCs that haven't been announced here yet. :)
>
> On Apr 8, 2012 9:32 AM, "Tom Boutell" wrote:
>>
>> I have written an RFC
ssion"
session and get the ball rolling formally. Please enlighten and I'll
do whatever is required.
Thanks!
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Thanks, I have access now.
Do I need to have a patch in hand before publicizing an RFC?
On Sun, Apr 8, 2012 at 10:56 AM, Ferenc Kovacs wrote:
>
>
> On Sun, Apr 8, 2012 at 4:22 PM, Tom Boutell wrote:
>>
>> Hi folks, I'm attempting to create an RFC on wiki.php.net bu
Hi folks, I'm attempting to create an RFC on wiki.php.net but I don't
get a "create this page" button. Is this the right place for me to
start an RFC? Thanks.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime De
This is an attempt to protect people who have written inherently insecure code
anyway. One should never do a dynamic require to any untrusted location, if
ever at all, yes?
Sent from my iPhone
On Apr 8, 2012, at 8:00 AM, Ángel González wrote:
> 2012/4/8, Yasuo Ohgaki:
>> 2012/4/8 Ángel Gonzá
I will. And thanks for your work maintaining gd- I should have mentioned that
earlier.
Sent from my iPhone
On Apr 7, 2012, at 12:47 PM, Pierre Joye wrote:
> hi Tom,
>
>
> On Sat, Apr 7, 2012 at 3:26 PM, Tom Boutell wrote:
>> Now that the flamewar has died down a little
Sent from my iPhone
On Apr 7, 2012, at 11:46 AM, Luke Scott wrote:
> On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote:
>
>> That's a good point too.
>>
>> I think this is a better proposal:
>>
>> include_code, require_code, and require_code_once would work
hells
> hwo they have to work if there is a whitespace before
> #!/bin/sh? what have you got as answer there?
>
> again: please leave the world in peace with your poorly
> thought proposals - and yes this is a really polite answer
> compared with the thoughts running through my mind
&
aders available that honored it, freeing end-user developers
from thinking about it. It becomes self-contained, and people who are
writing old-school .php standalone scripts or pages are entirely
unaffected.
On Sat, Apr 7, 2012 at 9:50 AM, John Bafford wrote:
>
> On Apr 7, 2012, at 09:39, Tom
mention the possibility of including URLs. There
> is no such thing as file name extension in URLs. Thus your idea should be
> forgot. Personally, I really think 1st of April is like continuing in the
> internals mailing list...
>
> 2012/4/7 Tom Boutell
>>
>> Now that the fl
1 - 100 of 156 matches
Mail list logo
