On 9/16/2017 3:50 AM, ilija.tov...@me.com wrote:
That’s fine, I have no problem with feedback. I changed my mind once other
people pointed out the flaws in my thinking. Politely.
Sorry for spending my free time thinking about how to make PHP better. I’m not
claiming to be an expert in any mean
On 7/28/2017 10:42 AM, li...@rhsoft.net wrote:
Am 28.07.2017 um 18:21 schrieb Kalle Sommer Nielsen:
2017-07-28 17:11 GMT+02:00 Sara Golemon :
I'm sure there will be many strong opinions on this, but let's move
this to a new thread. :D
1. This would be an 8.0 change as it does represent a sig
On 10/20/2016 4:58 PM, Guy Marriott wrote:
FWIW Yasuo, I also think this is a bad idea. If you remove the ability to
set cookie _headers_ with the header function then the function needs a
more appropriate name - perhaps headerExceptCookie.
That makes 5 people opposed - 100% of the individuals w
On 4/19/2016 5:10 PM, Stanislav Malyshev wrote:
In general, improving the type system provides a much more interesting and
practical playground for any kind of tool that would rely on static
That's my point - "more interesting playground" does not sound like a
reason enough to mess with the ty
On 4/19/2016 2:41 PM, Stanislav Malyshev wrote:
I try to share my worry that
some of the things being proposed include seriously complicating PHP's
conceptual model while serving at best infrequent use cases. Simplicity
is a virtue, and we have already lost significant amount of that virtue.
Mayb
On 7/13/2015 4:36 AM, Lester Caine wrote:
Coming from a background of 'traditional' php design, all of my code and
the libraries I use are documented via phpdoc style annotation which the
IDE picks up, and phpdocumentor1 produced a good API description. This
was also a GOOD basis to tidy up the v
On 3/11/2015 8:08 PM, Lester Caine wrote:
Personally I just want to keep the current name set and so the sheer
volume of changes proposed is a big kick in the face to me.
YES!
The time to make such a change to the names is about 1998 or maybe 2000.
Every person who learns the current names i
On 2/18/2015 7:44 PM, Rasmus Lerdorf wrote:
On 02/18/2015 06:07 PM, Christoph Becker wrote:
Hi internals!
A while ago a question was asked on the php-general mailing list with
regard to digit seperators in numeric literals[1].
IMHO it might be a useful enhancement to allow such digit separator
On 2/18/2015 6:33 PM, Christoph Becker wrote:
It seems to me you're thinking too much (maybe only?) about "database
types". IMHO PHP can be used more versatile, and there might be issues
which are exemplified in the RFC[1]:
Maybe PHP can be more versatile, but what percentage of PHP code sits
On 7/24/2012 5:45 AM, Laruence wrote:
On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin wrote:
On 24.07.2012, at 15:20, Laruence wrote:
Will it work without "catch" in your implementation?
nope for now.
but if it is needed, I can implemente it
Yes, please.
--
PHP Internals - PHP Runtime
On 7/20/2012 7:51 AM, Léo Peltier wrote:
>
Enforcing coding style should be forbidden.
YES!! I just thought that needed to be repeated!
On Fri, Jul 20, 2012 at 3:51 PM, Léo Peltier
wrote:
Clearly you don't work in a team or contribute to Open Source projects.
That's what coding styles
On 4/16/2012 1:02 PM, Kris Craig wrote:
On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmerwrote:
More important include doesn't currently allow multiple parms:
include "foo.bar", 'baz';
Parse error: syntax error, unexpected ',' in bla.php on line xx
Regarding include/require, I agree that a
On 4/16/2012 3:31 AM, Arvids Godjuks wrote:
That's sad really, to be honest.
I wonder if people even use this:
echo include 'foo.bar', 'baz';
Probably not, Try it! you get:
1baz
It actually works more like
echo (include "foo.bar"), 'baz';
than
echo include( "foo.bar"), 'baz';
On 4/9/2012 2:41 PM, Kris Craig wrote:
Honestly, I would suggest just getting rid of "Option 1" altogether. It
would end up over-complicating this to such a degree that any usefulness it
might serve would be considerably diminished.
As for embedded HTML, if you allow the ?> tag in these .php
Option 1: Introduce require_path
I think require_code is a better name. Parm 1 isn't a path, it is a
file, so require_path seems wrong to me.
I'd prefer a 'start in code mode' optional second parameter to
include[_once] and require[_once].
Option 2: Filename Convention
The PHP engine sh
On 3/17/2012 11:46 PM, Marco Pivetta wrote:
Thank you for clarifying some things :)
4. Strict weak type hinting:
This realm is the most likely to succeed because the core already does
something like this for internal functions (via zend_parse_parameters).
This balances utility (enforcing
On 3/7/2012 8:48 PM, John Crenshaw wrote:
In fact, nearly every input to PHP is a string. This is why PHP was
designed 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 stri
On 2/28/2012 2:58 PM, Kris Craig wrote:
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
still on the fence).
It this is an error, it is no longer PHP.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 2/18/2011 9:28 PM, Ben Schmidt wrote:
I did some research on methods in enums and discovered that there is
some usefulness to the idea - I wouldn't go so far as to say that they
would be needed, but C#, for example, allows you to create extension
methods for enums and MSDN has a decent real-wo
On 12/9/2010 9:53 AM, Andrey Hristov wrote:
.
fixing a design flaw of the past, evolution in other words.
Global and $GLOBALS are not a design flaw! They are a carefully thought
out technique to insure that you do not shoot your self in the foot by
accidentally accessing a global variable
Stut wrote:
Cracking point. Putting the domain in a header would make this far more
useful, and I don't think that's too much info to include in a header.
Ideally it would be the full URL, and I have to say that I don't think
that's too much information for a mail header, and it's exactly wh
Richard Lynch wrote:
How many sysadmins and other decision-makers out there aren't adopting
PHP5.x, much less 6.x, because we've changed too many things too
quickly in BC-incompatible ways?
*THAT* is what is slowing the adoption rate, not the applications
developers not WANTING to use the bet
Stanislav Malyshev wrote:
I'd say expression(f()[1]) means $tmp = f(); expression($tmp);
unset($tmp); which here means:
$tmp = foo();
$tmp[1] = 4;
unset($tmp);
which is meaningless but should work. IIRC the engine can make free's at
the end of expression, so it shouldn't be big problem. Actu
D. Dante Lorenso wrote:
No, that doesn't address the problem. See this:
print @ifsetor($x, $y, $z, "dante")."\n";
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
D. Dante Lorenso wrote:
Eric,
This reply is too basic and is not the answer. The problem is more
complex then you have grasped.
function ifsetor() {
$args = func_get_args();
$count = count( $args );
for( $i=0; $i<$count; $i++ ) {
if isset( $args[ $i ] )) {
return $args[ $i ];
25 matches
Mail list logo
