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
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?)
>
&
> --
> 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
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.
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
types and there's just some unexpected data loss even
E_RECOVERABLE_ERROR is too much IMO; E_WARNING or E_NOTICE would be more
appropriate. IIRC it also failed conversions too aggressively.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
reak.
One might argue that it should always have given a notice, but it didn't, so
it's a change, and a BC break. Pick your poison.
John Crenshaw
Priacta, Inc.
> > > 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
#x27;t need "just a scalar,
but any scalar will do". Most functions need something specific, like a string,
or a number. sqrt('foo') doesn't make any sense, it needs a number, not just a
scalar.
John Crenshaw
Priacta, Inc.
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.
way adding new error
types would not need to be considered a BC break.
John Crenshaw
Priacta, Inc.
opens a bunch of new problems that I don't see
a way to resolve. The reason for selecting this syntax was to avoid a BC break
from reserving some new keywords. I don't really see this as a good trade.
As for the automatic casting functions, I like the concept, but some serious
pr
> Ok, with Hannes help I have the RFC up now.
>
> https://wiki.php.net/rfc/changes_to_include_and_require
WRT tagless files, in addition to the issues already raised by others:
- What about script execution? You'll still need a shebang (linux) or to
register the extension (Windows). Having a spec
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>
> John,
>
> On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw
> wrote:
> > A good number of issues with the current proposal were raised during the
> > discussion on the mailing list. I don't feel like digg
ping me understand your concerns. I only wish they
> could have been shared more clearly at the POC phase so we could have avoided
> this altogether...
>
> Thanks,
>
> Anthony
I'm sorry for not raising the concerns well enough earlier.
John Crenshaw
Priacta, Inc.
igned
with some seriously robust type juggling on scalars. Any typing proposal that
wants to actually pass a vote is going to have to allow appropriate implicit
conversions from string to other types.
John Crenshaw
Priacta, Inc.
that failure to account for
type juggling in any such proposal is a deal breaker. For many users these
inputs can and will trickle down through the code and eventually cause
frustrating failures if not handled intelligently. You don't have to love it,
but basically if you want a typing proposal to have any chance I think you'll
have to support it.
John Crenshaw
Priacta, Inc.
rocess of improving the typing in PHP.
John Crenshaw
Priacta, Inc.
ng keywords such as "string", "int", "float" -
> that's what the major releases are for. When you introduce ANY keyword there
> is a
> possibility that someone is using it and it will break his application. It's a
> risk, yes. But now days refactoring instruments are very good and changing
> class
> name thought out the project is no big deal really - just make sure people are
> informed.
I think we all mostly agree on this point. Reserving these and other keywords
isn't going to be a major hangup.
John Crenshaw
Priacta, Inc.
ll and what doesn't.
>
> Adam
Agreed. I've been advocating the collection and organization of information
from prior discussions for a while. If there is good stuff to learn from
discussions in similar languages we should look over that too. The primary
barrier I see here is time. Looking over all this will take a lot of work.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ext to __toArray in terms of the level
of usefulness (maybe even beats it.) isset() can always be used to determine
whether something was ACTUALLY set to a non-null value, and to some extent
there is already a semantic problem anyway since things like if("0") resolve to
false.
John Cr
assumed that all references were out unless stated otherwise we could
avoid reserving an "out" keyword, and only add "inout", which is unlikely to
conflict with stuff.
Like I said, no attachment to this at all. My gut tells me I may have missed
something really stupid here. Just brainstorming.
John Crenshaw
Priacta, Inc.
we always allow null to be passed (whether we allow it to juggle, or allow
actually passing a null value through), since the inputs used in these cases
would almost always either be null, or already have a matching type (in the
case of inout). This edge case may have edge cases though...
Jo
ciple.
>5. Boxing based type hinting:
This is a hack that's been proposed before, but you don't need to look very far
to see why this ultimately breaks down badly. Even aggressive casting additions
to the language would not make this work particularly well. Anyone who's ever
tried to create a class wrapper for a scalar in C++ (which probably includes
the core devs) is not likely to be down with this idea.
John Crenshaw
Priacta, Inc.
ages.
The question shouldn't be "should we add a cooler short tag?". The question
should be "What needs to be done to make PHP an industry leader in template
languages again?".
My two cents,
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> yes, i am not able to stop calling people to lazy writing whitespaces in front morons
The constant personal attacks are a violation of the mailing list rules. Nobody
likes getting this in their inbox. Please let's keep this civil.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP
d ideas if you say freindly "not a godd idea"
Wow. I'm honestly shocked. That's the crux of it isn't it? Trouble is that this
sort of response violates the rules of the mailing list; rules that we all
agreed to. It also isn't going to go over well with the type of people you have
here. This is not a productive communication tactic, this is bullying. If you
are unwilling to be civil and rational I have to ask, why are you even here?
John Crenshaw
Priacta, Inc.
the behavior of any existing code. Some other options that
might make sense:
lint (like command line)
end_code (similar to command line, corresponds with begin_code (also command
line))
args (also command line)
Any PHP_INI_ALL directives
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
truly incapable (both in action and by his own admission) of
communicating in a civil way. We don't need this here. There have been multiple
requests for him to stop from multiple people and it's not getting any better.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Dev
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki
> There were full of embedded PHP pages 10 years ago.
> Only template pages require embedded PHP script now.
There are legions of sites that use PHP "on the metal". No framework, no MVC,
no CMS, just direct code files mi
From: Tom Boutell [mailto:t...@punkave.com]
> 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
From: Tom Boutell [mailto:t...@punkave.com]
>
> 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
> I'm not sure what you mean by this
From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki
>
> Hi all,
>
> This is the RFC as in the title.
> Although it's not a direct security measure, but it's related to critical
> security problem prevention.
>
> If you are not familiar to how to execute arbitrary PHP co
t;
Anyone who says this is wrong. Ruby is in fact far less secure, because it
doesn't even have cursory escaping functions and a variety of unpredictable
behaviors (implicit returns) can lead to wild results.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
g comparison). Still, I think it is interesting because it actually
divines the real meaning. The intent of the above code is obvious to a
developer, and something like this could bring that understanding to the final
result. This specific concept has issues, but maybe it gives someone else a
more practical idea.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the sense that you
can't safely use both in the same code base. Unfortunately this will not be
clear to anybody at first, which will lead to mass proliferation of .phpp
libraries which are like poison to any unsuspecting PHP user foolish enough to
try to use one. This isn't just a
Sent: Friday, April 13, 2012 3:39 PM
> On Fri, Apr 13, 2012 at 12:12 PM, John Crenshaw
> wrote:
> > > >
> > > > On top of this, there's an argument that you're not addressing: most
> > > > template engines in PHP either directly consume PHP t
doesn't look like PHP OR
JSON, and is likely to cause confusion. If [a=>$b] is the only syntax people
can agree on, I can live with that, but IMO that syntax will actually create
MORE confusion than just allowing pure JSON (opinion informed by trying to get
new devs up to speed on a proje
s the door open for internal changes if they're really needed,
but basically suggests against it.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: Wednesday, June 01, 2011 7:08 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-
sy.
1. The most readable format is pure JSON
2. The most familiar format is pure JSON (because these same developers are
almost certainly already using it in their jQuery code)
3. The most compact format is pure JSON
4. The format most consistent with other languages is JSON
John Crenshaw
Priacta
x27;: strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
};
Because of the clear readability difference I'll take anything, but JSON would
be much better than just an "
nd the PHP-like => syntax)?
Individual projects could gravitate to the format that makes the most sense on
a case by case basis.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Sean Coates [mailto:s...@seancoates.com]
Sent: Wednesday, June 01, 2011 6:09 PM
To: Anthony Ferrara
Cc:
ony", what they mean is "an object/array with the
following structure/values", because that is what the encoding really
represents.
John Crenshaw
Priacta, Inc.
-Original Message-
From: dukeofgaming [mailto:dukeofgam...@gmail.com]
Sent: Wednesday, June 01, 2011 6:52 PM
E_NOTICE. The current conversion is so completely useless, that whenever it
happens, it is almost certainly an error. Any implicit conversion here would
perpetuate problems in code that was probably wrong in the first place.
John Crenshaw
Priacta, Inc.
-Original Message-
From: John
AJAX",
regardless of the fact that almost nobody ACTUALLY uses XML as the transfer
encoding. Who cares? "JSON" is the best word available. Unless you can suggest
a better word to differentiate this format from the others (one that isn't
designed to insult anyone who disagre
heritance question.
IMHO this should wait until we can address some of these items. Otherwise the
feature is just a halfbaked not-so-short shorthand for constants.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ine here is that enums become a
hinderance to inheritance unless they can be extended. If an enum can't be
extended, it is effectively final, regardless of whether that is actually
helpful.
John Crenshaw
Priacta, Inc.
From: Dennis Haarbrink [mailto:dhaarbr...@gmail.com]
Sent: Friday, June
This is a moot point. You wouldn't send that to json_decode. You would send it
to json_encode. In other words json_decode({"yay": "ä"}) is totally wrong in
the first place, because json_decode requires a string, not an object.
John Crenshaw
Priacta, Inc.
-Original
also chaotic.
(Who can call for a vote? How? When is it final? Who can vote? How do they
vote? How much is each vote worth? Is a simple majority or super majority
needed?)
John Crenshaw
Priacta, Inc.
-Original Message-
From: Philip Olson [mailto:phi...@roshambo.org]
Sent: Saturday, June
think of one.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Johannes Schlüter [mailto:johan...@schlueters.de]
Sent: Saturday, June 04, 2011 8:46 PM
To: Pierre Joye
Cc: Patrick ALLAERT; PHP Development
Subject: Re: [PHP-DEV] [PATCH] Notice on array to string convertion
On Thu, 2011
whether it is helpful to developers using these systems, but not in terms of
whether anyone wishes these systems would go away (because they won't).
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From: David Muir [mailto:davidkm...@gmail.com]
On 06/06/11 17:48, Tom Samplonius wrote:
>> Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply
> I don't know if this is really the case.
The problem is much larger than most of us would probably like to believe. Some
of the
y what is being returned.
No offense to anyone who loves currying, but I don't see why this should be
implemented. There are plenty of good options available for achieving identical
or better results without modifying the language.
John Crenshaw
Priacta, Inc.
$e2, $e3)) { ...
Disagree. This feels very obtuse. I wouldn't expect this construct to work at
all, and even if it did, it is highly ambiguous (I.E. at first I thought you
were intending to grab 3 entries at a time, rather than extracting entries from
a second array).
John Crenshaw
Priact
this type of implementation can be very flexible
and tailored to specific application needs in a way that a language level
implementation can't (for fear of bloat).
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From: Hannes Landeholm [mailto:landeh...@gmail.com]
Sent: Tuesday, June 07, 2011 11:50 AM
To: John Crenshaw; internals@lists.php.net
Subject: Re: [PHP-DEV] Inline constructing/cloning and inline foreach listing
On 7 June 2011 15:53, John Crenshaw
mailto:johncrens...@priacta.com>>
stops the discussion from moving forward,
but if a userland implementation is needed to demonstrate why a parser level
implementation isn't, I can throw together something basic, or at least some
pseudo-code.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing
is generally totally unacceptable.
Also, I'm inclined to agree that bundling won't have a large effect on whether
hosts include certain modules; in my experience they seem to be fairly
aggressive about culling modules that they don't like, or don't think will be
useful.
John Crens
, any code that expects long to hold more than 4 bytes is
fundamentally broken. See
http://stackoverflow.com/questions/589575/c-size-of-int-long-etc#answer-589684
and http://jk-technology.com/c/inttypes.html#limits
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailin
e to make long longer and leave int in place is a bit of a
historical deviation. The "int" type was always redundant, and previously it
was int that moved, and the other types remained reliable. In any case, the
stdint header should address the problem so long as it is used.
John
ntil the developer finally realizes
that they have a string and not an array. Errors like this are probably far
more common in most projects than the need to iterate a string, so making this
change hurts debugging in the common case, for the sake of syntactic sugar in
the rare case. Not a good trade.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
acters assumption (which is
wrong) will also be, by far, the most common. Supporting that most common case
when moving to PHP 6 would require breaking the binary case (which was the only
properly written code in the first place.) On the other hand, supporting the
binary case means breaking
the utility
> in it would be)...
I think this does what you want:
function utf8_str_split($s)
{
return preg_split("/(.)/u", $s, null, PREG_SPLIT_DELIM_CAPTURE |
PREG_SPLIT_NO_EMPTY);
}
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
will have to strip out anyway to fix their bug?
If string iteration needs to be addressed in the core (and IMO it doesn't
because it can be handled at the script level, but if it does) why not use
iterator classes? This gives the same functionality and prevents the language
from encouraging hidden bugs.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
isn't meeting your needs, you'll
get to go through the wonderful process of trying to convert all of your legacy
data to UTF8.
Single byte just doesn't cut the mustard anymore, especially on the web. The
world is too small. We should be trying to move PHP *away* from this, not
towards it.
John Crenshaw
Priacta, Inc.
> From: Pierre Joye [mailto:pierre@gmail.com]
> > On Tue, Jun 21, 2011 at 4:38 PM, John Crenshaw
> > wrote:
>
> > This mindset is fundamentally broken. You can call it a byte array all you
> > want, but the truth is that 99.999% of the time, when a develop
; doing exactly what it is suppose to do here and I wouldn't want it any
> other way.
Agreed. Although I generally favor the idea of strong scope, it isn't practical
to implement in PHP. It isn't sensible because PHP doesn't require explicit
variable declaration, and
meaningful warnings when you didn't intend to iterate the
string (by far the more likely scenario)
2. The ability to easily fix your code when you decide that a universal
character set really is valuable
3. The ability to clearly see the intent of the code
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
because it would make it easier to parse the
error from the output buffer.
Of course, in this case I see no reason why the error trap couldn't set
html_errors at the same time as it sets display_errors and error_prepend_string.
John Crenshaw
Priacta, Inc.
aking it similar in badness to if statements without braces. IMO the
current syntax for inline functions is perfectly sufficient, even for the PLINQ
example given earlier, and has massive advantages over this one in terms of
readability, affordance, flexibility, and language clarity.
John Crenshaw
Priac
conceive of any acceptable reason for the error described here. Even
though the change was certainly well intentioned, it clearly didn't account for
the possibility of unusual but valid coding situations (such as mocks and other
code generation tactics that should be able to reasonably depend on consistent
language behaviors).
John Crenshaw
Priacta, Inc.
1 - 100 of 103 matches
Mail list logo
