I have been developing a site which stores an image files binary data
inside a session variable. Initially, I was developing this site on the
following environment:
Apache-2.0.52/PHP5.0.3/Windows XP
Things worked very well, as I expected them to anyway. I would upload
images and they would be m
Long time reader, first time poster.
Rasmus, I noticed your var_dump says $x->node->title is of string(6) ...
though I count only 5. Just wondering, a simple typo or something more
involved?
Regards,
John
Rasmus Lerdorf wrote:
Sterling Hughes wrote:
Hm - that shouldn't be.
Attached is a patch which addresses array indices being out of bounds in
pcre and libxmlrpc binary searches.
John
Index: ext/pcre/pcrelib/pcre_get.c
===
RCS file: /repository/php-src/ext/pcre/pcrelib/pcre_get.c,v
retrieving
can help in data deduplication...
Thanks. John aka webautoma...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hout a webserver.
I'm using an IE activex control to display the pages generated by php, and
I'm writing a mini SAPI implementation to interface with php. Thanks for
the hard work.
John LeSueur
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
such as $thing[@0],
> $thing[@-1], etc.
I would just like to point out that the @ error suppression operator operates
on expressions. Unfortunately, that means that also using @ as a slice operator
makes the two ambiguous with each other in those contexts. The concept itself
can still w
> 2
> php > echo (a^b) . "\n";
> 3
> php >
>
> However: `☃` has a long history of being available to PHP.
>
> S
>
There’s no existing unary form of * and ^, though, so I think they’d both be
available in this context (^ is my preference).
Overloading unary & would probably also work in this context, but personally, I
think that & is too overused.
-John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t; 3
is currently valid syntax, and means
$foo ? ($bar < 1) : (2 > 3)
So there is probably some complex nesting of ?: and <:> that is entirely
ambiguous.
Not necessarily saying it can’t be done, but I think we should probably avoid
syntax with a significant chance of causin
few functions. (PR
here: https://github.com/php/php-src/pull/347)
If people are generally interested in having an array_key_(first|last|index)
implementation, I can dust off that PR, update it for master, and if we really
need an RFC, I’ll prepare one for PHP 7.1.
-John
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
omething like that. First element can
> be easily accessed with reset and each/current, but the last one is
> harder to access without modifying. So maybe it's be a good addition.
> There's a lot of time till 7.1 yet so you could definitely make a good RFC.
reset + each/current
potential security concerns? Are there any other languages that make
something like this possible?
I suspect that any code that could be “improved” with this functionality is
already in significant need of improvement by more conventional means.
-John
--
PHP Internals - PHP Runtime Develop
On Aug 14 2024, at 5:27 pm, Lanre wrote:
>
> Can you point out where either of us suggested writing PHP in another
> language? You might be mixing this up with the C11 thread, which has nothing
> to do with this. All I'm proposing is improving the current C++ support in
> the engine.
> https
}
private init() {}
}
let parent = Parent() //'Parent' initializer is inaccessible due to 'private'
protection level
let child = Parent.Child() //ok
```
Swift also has a fileprivate visibility, so the same could be accomplished with
a fileprivate init on Parent with a non-nested Child in the same file.
-John
t we can look at
correcting?
John
> Didja really?
>
> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
I swear I did.
That said, looking at that RFC it's a slightly different take than what I am
suggesting. This RFC suggests that string enums automatically implement
Stringable . I am pointing out that i
nse for it to ever return anything but that string
constant. I don't think this is something ADTs or tagged unions or anything of
the sort should play a role in deciding.
John
On Aug 16 2024, at 6:49 pm, Rob Landers wrote:
>
> That being said, I would like to be able to use | and & on integer enums more
> than I would strings as stringables. Something like “flags” mode in C#. Maybe
> even make “flag” a backing type of enums. It would make a ton of json flags
> much
ring() , would anyone have a strong objection to getting an RFC
going to get this voted on? I didn't look closely at the original PR from the
"auto implement __toString()" for string-backed enums, but I think this might
literally be a one-liner just to enable enums to implement __toString() and the
rest can be tossed.
John
On Aug 2 2024, at 4:37 pm, Bilge wrote:
> My only concern is there needs to be an alternative way to do this:
> intercepting internal calls. Sometimes, whether due to poor architecture or
> otherwise, we just need to be able to replace an internal function call. One
> example I can think of r
ackages should be
FQing their internal function calls. The natural behavior of the language
shouldn't be the insecure way of doing things for the sake of maintaining BC
compatibility with existing, insecure, code.
Cheers,
John
make it easier to perform such an attack, which
as Illija pointed out is actually making PHP slower, in the name of backward
compatibility? Defense in depth is a cornerstone of application security.
John
Forgive me, s/Illija/you :)
garding the subject at hand I've made my case here and we can agree to
disagree -- changing the function lookup order is an easy win with security
benefits and, according to Ilija, performance benefits. I think it should be
seriously considered.
John
On Aug 23 2024, at 11:49 am, Rowan Tommins [IMSoP] wrote:
>
> And most users don't object to using a leading backslash, they just (quite
> reasonably) have no idea what impact it has on the ability of the engine to
> optimise their code.
I think this is a misread, and I don't think you can ar
On Aug 23 2024, at 12:27 pm, Stephen Reay wrote:
>
> The current inconsistencies between symbol types can be avoided in userland
> in a 100% consistent way. Import or qualify the symbols you use, all the
> time, and you have 0 inconsistencies or bizarreness in terms of what it used
> when.
S
On Aug 23 2024, at 12:35 pm, Stephen Reay wrote:
>
> > would find it non-sensical that you must add a backslash for the engine to
> > do the "right thing" (in this case, optimize their code with a security
> > benefit), vs just doing the right thing by default.
>
> What do you mean by this? Wh
> What do you mean by this? What is "the right thing"?
Also, faster code vs. slower code by default is "the right thing" too.
> 1. People who don't think BC is a problem, and would like to drop
> either the global or local lookup entirely, requiring disambiguation.
>
There is also an option of swapping the priority, making local lookups
secondary to global lookups -- and to override that behavior you would require
dis
On Aug 23 2024, at 1:46 pm, Stephen Reay wrote:
>
>
> The claims about "security" because a function you defined (or included via a
> package) is resolved in place of a global one are irrelevant. If you're
> including compromised code in your project, all bets are off.
I have plenty of experie
On Aug 23 2024, at 3:41 pm, Rowan Tommins [IMSoP] wrote:
>
> None of these seem like showstoppers to me, but since we can so easily go one
> step further to "global only", and avoid them, why wouldn't we?
FWIW I'd support global only, specifically because of the point I wouldn't
necessarily w
On Aug 24 2024, at 12:49 pm, Bilge wrote:
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I
> think some of you might enjoy this one. Hit me with any feedback.
>
Seems like you are missing an option for your theme example, which would be to
simply extend the C
> If the underlying API changes the argument type, consumers will have an issue
> regardless. For those cases where the expression is simply `default`, you'd
> actually be protected from the API change, which is a net benefit already.
>
> This also protects the user from changes in the argument
t of them out for
now. To me, that basically means "default with bitwise expression support"
based on what I've seen so far.
John
On Aug 25 2024, at 11:31 am, Rowan Tommins [IMSoP] wrote:
>
>
> Even then, I look at that list and see more problems than use cases. As the
> RFC points out, library authors already worry about the maintenance burden of
> named argument support, will they now also need to question whether some
> Special-casing the T_DEFAULT grammar would not only bloat the grammar rules
> but also increase the chance that new expression grammars introduced in
> future, which could conveniently interoperate with `default`, would be
> unintentionally excluded by omission.
Forgot to add that I don't thi
g the library,
and want to support both versions, you might both not want to set the value,
and yet also care what the default value is from the standpoint of knowing what
to expect out of the function.
-John
On Aug 25, 2024, at 14:46, Rowan Tommins [IMSoP] wrote:
>
> On 25/08/2024 18:44, John Bafford wrote:
>
>> Although I'm not sold on the idea of using default as part of an
>> expression, I would argue that a default function parameter value is
>> fair game to be
() is a valid expression in
this context or a good idea for the language. The use of this proposed default
keyword must have guardrails IMO. I think my definition above is a pretty
reasonable attempt at capturing where I think the line is here and hopefully
that helps guide this discussion.
John
On Aug 25 2024, at 5:51 pm, Bilge wrote:
> If you believe I am incorrect about this, I encourage you to submit a
> (working) Bison patch to demonstrate how a restricted expression grammar
> subset can still recurse with the unrestricted superset, then we can start
> having this discussion mor
On Aug 25 2024, at 6:42 pm, Bilge wrote:
> On 25/08/2024 23:31, Rowan Tommins [IMSoP] wrote:
> > It doesn't, unfortunately, persuade me that the behaviour proposed is
> > sensible.
>
> It should. But since it has apparently failed in that regard, I suggest you
> take me up on my challenge to i
his point if some downstream caller
decided to use my default value directly or not.
You can argue if this is a good API design or not, but it was only written to
provide a real example of how pulling the default value higher up the call
chain and allowing it to be used in expressions is problematic
> From the example you gave it appears that we can have a concrete problem when:
> 1. There is a parameter with a default value,
> 2. That parameter is type-hinted,
> 3. The hinted type is declared as a union type,
> 4. An earlier version of the library initialized the default with a value
> havi
On Aug 26 2024, at 2:39 pm, Bilge wrote:
>
> I like this approach. I'm still not sure I'd want to pursue adding
> exclusions, but if we can identify something that's obviously bad and/or
> dangerous then we can consider that short list for exclusion. That is much
> more compelling than starti
On Aug 26 2024, at 2:11 pm, Matthew Weier O'Phinney
wrote:
>
> I can see a few others:
>
> - string concatenation. I might want to prepend or append a string to a
> default.
>
> - fractional or multiplicative application, e.g. for durations/timeouts.
> These might require testing for non-zero
On Aug 26 2024, at 5:57 pm, Bilge wrote:
> In case it matters, my initial inclination was also to do what some others
> have suggested, and modify the SEND opcodes so that the default is not
> actually looked up using reflection at all, but rather we just send nothing
> to the function and it
On Aug 26 2024, at 5:27 pm, Matthew Weier O'Phinney
wrote:
> You'll likely identify the increased delay in such cases. Generally speaking
> these sorts of default values don't change a ton, but it's not unlikely that
> you may say "I'd like half that delay" or "twice that delay". But a better
to json_encode(). It's the
default value of the first parameter to gettype(). Which would probably fail,
since gettype()'s first parameter doesn't have a default. I suppose this could
be solved by specifying an offset or label (e.g. as with `continue 2` in a
nested loop), but that would just make it even harder to read.
-John
> And that is how you will find that the "new" languages will "win". If we
> don't promote how modern PHP Development works, then there will be more
> "PHP, a fractal of bad design" articles to come for decades.
>
> We *must* do better than this. It probably doesn't all need to be in the
> documen
> I agree with this to a point. What if I want my newish framework listed on
> the page? What are the qualifications for being listed (or unlisted) there?
> Can anyone add their own framework?
Personally I say put the top 5 by Github stars on a page by themselves, and
have a secondary page rank
On Aug 28 2024, at 9:34 am, Larry Garfield wrote:
>
> I don't think I'd support a list of "popular" frameworks, but mentioning
> Composer, Xdebug, and PHPUnit seems a requirement for a useful modern
> tutorial.
Can you explain your position more here, what exactly is your concern (if I
captu
One thought re-reading the RFC.
abstract class Theme {
public function bar();
}
class CuteTheme extends Theme {
public function foo();
}
class Config {
public function __construct(Theme $theme = new CuteTheme()) {}
}
$a = new Config(default->foo());
In the proposed (updated) RFC would this be p
to do
it without requiring docblocks. The language providing tools for being more
explicit about intent in code is never bad.
-John
For example, if I set a temporary variable to something, and then
later in the function, reuse that same name for a new temporary but don't set
the value on all flow paths, then the value from earlier in the function leaks
through, whereas either using a constant, or a second explicit variable
definition would have exposed and/or prevented the issue.
-John
> As per my previous email to the list, I have now created the official RFC to
> deprecate calling json_serialize() on instances of classes marked with
> ZEND_ACC_NOT_SERIALIZABLE.
I would suggest we take a step back from this and look at it with a bit more of
a wider lens. It seems to me that
> So if we had a #[NotSerializable] attribute (which I agree might be a good
> idea) it would be implemented by setting the ZEND_ACC_NOT_SERIALIZABLE flag
> on a class definition, and if this RFC passes, it would automatically apply
> to json_encode() as well as serialize().
>
My mistake, I hav
On Sep 6 2024, at 2:07 pm, Claude Pache wrote:
>
>
> > Le 5 sept. 2024 à 18:03, John Coggeshall a écrit :
> >
> > > As per my previous email to the list, I have now created the official RFC
> > > to deprecate calling json_serialize()
way to ensure it.
There's obviously a question about how much juggling to allow with a scalar
type hint. IMO the obvious stuff ("36" to 36, etc.) is perfect, but passing
"foobar" or array(1,2,3) to an int should throw an error.
John Crenshaw
Priacta, Inc.
--
PHP Internal
m:
"PHP is not language X" is a terrible argument. This is a smokescreen designed
to insult the other person, belittle their concerns, and avoid discussing the
real issue. This doesn't advance the discussion at all.
Concluding that PHP is popular because you can't {insert r
ntax in the second example (using ?).
IMO allowing null should be the default unless specifically disallowed.
I far prefer the addition/use of a keyword ("notnull" or "null") to disallow
(or allow) as opposed to random symbol abuse (potential incompatibilities
notwithstanding
ny sort using a secret value unique
to the machine (or unique to the process) that is handling the request, it
would be impossible for an attacker to compute a problematic sequence of keys,
which should close the door on DoS.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Because Zend/zend_language_scanner.c is a generated file, you could exclude
it from your diff, and end up with a much smaller patch. Smaller patches
are more appealing :)
On Fri, Feb 3, 2012 at 6:47 AM, Clint M Priest wrote:
> The property accessor functionality is done and is detailed here:
> h
PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I could be wrong, but doesn't:
(header_line[i+1] != ' ' && header_line[i+1] != '\t')
access an element past the end of the header_line array on the last
iteration of the for loop? shouldn't the for loop go until header_line_len
- 1?
John
ail chain (though I could easily have missed it
entirely).
IMO we should try to focus on:
1. What are the pros vs. cons of enabling the Suhosin patch by default?
2. Why did the Debian team opt to disable it?
3. Are there better solutions that should be considered and recommended?
John Crens
uotes. This is a super common mistake with
/e, and even many veterans won't notice it (although they'll probably notice
the use of /e).
Removing this would obviously be an inconvenience for some people, but getting
your server hacked is also an inconvenience, and hackers don't gi
d
something, when you include the file APC uses the cached bytecode as long as it
is available and the file was not since modified. If the file was modified APC
recompiles it and caches the bytecode. Sounds like the same net result to me,
except that APC is less complicated, requires no code chan
RFC for replacing "errors" with exceptions a while back, but it
was a disaster (didn't even cover the (fatal) error cases, wanted to replace
all warnings with exceptions, focused on things that were already recoverable,
etc.) It was the wrong solution to the wrong problem. I don't want anything I
say here to be confused with that.
I think I do like the idea of (optionally?) replacing fatal errors with
exceptions, but only if it is a general paradigm change. If you are only going
to replace one error, then I don't like the idea because it is inconsistent and
makes core changes to support one person's use case without considering what
the overall need really is.
John Crenshaw
Priacta, Inc.
> From: Ferenc Kovacs [mailto:tyr...@gmail.com]
> Sent: Wednesday, February 22, 2012 3:55 PM
> To: John Crenshaw
> Cc: Peter Lind; Larry Garfield; internals@lists.php.net
> Subject: Re: [PHP-DEV] Exceptions for method on non-object rather than fatal
> (desired feature?)
>
&
Previous discussions have covered the probability that strict typing and
dynamic typing can't coexist, because strict typing ends up pushing itself
further up the call tree. An ini setting to change from one to the other
will not solve that problem. Not sure that it says anything about enums,
but s
> --
> Lester Caine - G8HFL
No, not really. This sort of attitude brings nothing to the table and leaves no
room for level minded negotiation. It simply derides anyone who thinks
differently in an attempt to bully other people into giving you your way.
Claiming "I'm not bein
a limited range of valid
inputs. For example, consider substr(), which will never make any sense unless
you pass a string and an integer. If you try to call substr('foo', 'bar') it's
going to have to fail, the only question is at what level and how. So called
"str
[trim]
> 2. "Strict type hinting would eliminate PHP's flexibility and take away its
> unique simplicity."
>
> I respectfully disagree. Again, let me remind you that we are *not*
> talking
> about *converting *PHP to strict type hinting. Instead, we're merely
> talking about allowing PHP develop
the typical arguments pro and con for
each of the 3. If people agree that this would be helpful, I'm willing to dig
through the archives and try to put this together.
John Crenshaw
Priacta, Inc.
derstood, and everyone's position on those
two points was crystallized. There were still a few proponents of strict
type hints, but it seemed they were willing to live with non-strict type
hints. At that point, everyone became more interested in having a 5.4, and
scalar type hints were left for a time.
Hopefully I haven't mischaracterized anyone's position, but I hope it helps
us move beyond previously trod ground.
John
crapped? Can someone clarify?
John Crenshaw
Priacta, Inc.
-Original Message-
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Sent: Monday, February 27, 2012 10:38 AM
To: Richard Lynch
Cc: Stas Malyshev; PHP Internals
Subject: Re: [PHP-DEV] bugs.php.net & php 6
Hi, Richard
rned out by strict typing debates. The words
"strong" and "strict" are basically inflammatory at this point. In the interest
of facilitating a reasonable discussion, I think we should avoid language that
is likely to cause discussion to break down.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -Original Message-
> From: John LeSueur [mailto:john.lesu...@gmail.com]
>
> Maybe this discussion should start from the end of the last discussion on
> non-strict type hints, where really smart people came up with some options to
> handle the conversion:
>
>
ly agree. E_RECOVERABLE_ERROR is the most severe that this should be
(also matches the behavior of current type hints).
> > weak int $i = "1"; // Converts to 1.
>
> Again, old-school (int) or set_type covers this.
Unfortunately it doesn't completely. Yes, behavior is the same so long as the
conversion is good, but a cast will silently accept impossible conversions,
which is not what you really want here.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Would "firm" work better?
>
> --Kris
As a working name that would be fine. Of course, if this discussion moves to a
sub-group that becomes less critical since it would be less likely for people
to jump in the middle and misunderstand the terms.
John Crenshaw
Priacta, Inc.
gn process using
Google Docs + Donedesk(our own product, but free) + Skype. This works well and
strikes a nice balance between persistent and realtime collaboration. I'm open
to other ideas, but if I had to choose how to coordinate a group to design a
single feature, that's what I would
ng" (as defined above), point them to the prior discussions on
the topic which explain exactly what the problems with this are.
John Crenshaw
Priacta, Inc.
ut the code will work and notices are usually
> suppressed
> by default (yes, I know about the RFC to change that)
If using types causes a large number of unnecessary notices that's a spec
problem. The core devs aren't going to accept that.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From: Adam Richardson [mailto:simples...@gmail.com]
On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw
mailto:johncrens...@priacta.com>> wrote:
OK everyone, it seems that some people have forgotten or missed the original
agreement that this thread started with. There is a communication disc
participate in this
process we can probably partition it by date ranges.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Tuesday, February 28, 2012 3:15 PM
To: Kris Craig
Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris
> From: Kris Craig [mailto:kris.cr...@gmail.com]
>
> I could setup a repo on Github for this if anyone thinks that would be
> helpful?
>
> --Kris
I was figuring wiki for that information, but that would limit participants to
those with editing permissions.
John Cre
No, In the example given there's an error on int $a = "1". There should be no
error because this juggles fine.
John Crenshaw
Priacta, inc.
-Original Message-
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lync
mplaint that doesn't help anyone understand why this construct is
a problem. Instead, please articulate the core problem with the proposal. In
this case a better response would be something like: "This re-opens the viral
poisoning problem with strict typing that's already be
weak int" in your proposal
(the only remaining difference being the level of error raised when it cannot
be converted, which IMO is not substantial enough to deserve a keyword.) I'd
prefer to just pick one error level to use (E_RECOVERABLE_ERROR would be the
most consistent) and keep everything simple.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hints to
something simpler (or new, like E_TYPE), but I think that might be better to
tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals
ll personally resist any attempt to submit anything that isn't substantially
different from prior proposals and/or that doesn't include solutions to the
problems previously identified.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
;t even consolidated the
historical arguments. If you create an RFC blindly without carefully
scrutinizing the prior analysis and measuring against prior arguments you'll be
the next in a long line of failures.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e same time ('foo'==0, '123abc'=123). Fixing the conversions
is a BC break though.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
inciples or tell basic users to go hang themselves. This is
mostly philosophical musing.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> From: Richard Lynch [mailto:c...@l-i-e.com]
> On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > I'm beginning to think that the type hinting question is too closely
> > related to the dirty secrets of type juggling to resolve them
> > separately. Y
From: Simon Schick [mailto:simonsimc...@googlemail.com]
>
> Hi, John
>
> Just to add an idea to yours ..
>
> Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or
> E_WARNING if we f.e. try to give a string to a method that just allows
> > > From: Richard Lynch [mailto:c...@l-i-e.com]
> > > On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> > > > I'm beginning to think that the type hinting question is too closely
> > > > related to the dirty secrets of type juggling to r
From: Simon Schick [mailto:simonsimc...@googlemail.com]
>
> Hi, John
>
> Therefore I think it would be easy to explain how a type-hint for scalar
> could work.
>
> You can explain it as saying that the following two functions should be end
> up in exactly the same
From: Richard Lynch [mailto:c...@l-i-e.com]
> On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
> >> You might consider those scripts poor programming practice. We all
> >> do.
> >> But PHP is the language of the unwashed masses, and that was, and is,
> &g
consistency vs. BC question previously worked out.
John Crenshaw
Priacta, Inc.
On 02/03/12 14:48, Anthony Ferrara wrote:
> Hey all,
>
> I know given all the discussion about this topic lately, this is a hot
> topic. But I whipped together a quick POC patch to implement scalar
&g
things could hide,
like superglobals), then if everything looks good include the file. Use a
caching system of some sort to improve performance and eliminate redundant
checks.
I seriously doubt that this would ever get implemented in the core though. PHP
has been moving away from this sort of thing (and for good reason). Attempting
a "one size fits all" sandbox in the core just doesn't make any sense.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
problems, and although I recognize the value of this sort of
functionality, the current proposal seems to mostly ignore a number of critical
problems that were raised when it was discussed on the mailing list.
John Crenshaw
Priacta, Inc.
1 - 100 of 551 matches
Mail list logo
