Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

[Rick Widmer]

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 means, hence the RFC.


If only it were making PHP better.  It is only breaking existing code 
for no good reason.  There have been way too many such suggestions 
recently.  That is why you are getting such a strong reaction!





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Changes to SuperGlobals for PHP 8

[Rick Widmer]

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 significant BC 
change.

2. We can discuss the possibility of INI options or other mitigation
strategies for misbehaving code bases (and they do exist).
3. I'm definitely not decided on what I'd like from default session
behavior. An error isn't out of the question, for sure.


I for one thing it makes a lot of sense to make superglobals
read-only, writing to them seems more like a hack anyway and should be
avoided


wrong question!

the right questions are

* are you fored to do so
* are you harmed by the possibility

and only if you can answer both with "yes" it's worth to cosindr changes 
breaking a ton of perfect working code




What he said.  That would break almost everything I've written.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] header() removes all header of the same name.

[Rick Widmer]

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 who have responded in
this thread.


6.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Improving PHP's type system

[Rick Widmer]

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 type system of the language used by
millions. This sounds like a good description of a thesis project or a
academic proof-of-concept language, not something mature widely-used
language prizing simplicity should be aiming for. I completely agree
that *if* we added a ton of shiny things into PHP then there would be a
lot of interesting stuff to play with. I am saying that is not the
reason enough to actually add them.


Are too many of these incompatible shiny things, too fast, the main 
reason so many PHP users are on older versions?


IMHO, yes.


Rick



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Improving PHP's type system

[Rick Widmer]

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.
Maybe we gained more - I don't know yet, as most of our user base isn't
even on 5.5 by now. But it does worry me that we are not only losing it
- we seem to be actively trying to get rid of it.





I just thought that needed to be repeated!


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP7 and types - and alternatives to annotation

[Rick Widmer]

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 various changes through PHP5.x

Today much of the infrastructure to make that work is broken and
http://lsces.org.uk/wiki/bitweaver+documentation  is a starting point at
getting the material all up to date. The original documentation had a
few errors on the log file, buthttp://lsces.org.uk/bwdocs2/index.html
is the version I've been working on and is listing 3300 errors in the
documentation! The next step is to work out how to address those errors,


Phpdocumentor2?

I don't remember the details, but a single patch cleaned up a ton of 
errors for me.  I googled the error message and found a github? pull 
request or bug report.  The best answer is at the bottom of the 
discussion.  As of the last time I loaded it, about 3 months ago, I 
still had to apply the patch.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Consistent function names

[Rick Widmer]

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 is one more reason not to 
change them now!



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC-Discuss] Scalar Type Declarations v0.5

[Rick Widmer]

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 
between a web browser and a SQL database?


I think it is pretty high!


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Digit separators for numeric literals

[Rick Widmer]

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 separators for
numeric (integer and float) literals in PHP for better readability;
several other languages already support them (such as Java, Perl, Ruby,
C#, Eiffel and C++14).

Before attempting to draft a respective RFC, I'd like to get some
feedback, whether this is generally considered to be useful, which
character would be preferred (most other languages seem to allow the
underscore, but an apostroph or maybe some other character might be
reasonable as well), and which restrictions should be applied (e.g.
arbitrary use of the separator, group thousands only, etc.)

I'm looking forward to hear your opinion.  Thanks in advance.

[1] http://marc.info/?l=php-generalm=142143581810951w=2


I think it will be difficult to find a separator character that doesn't
make a mess of the grammar.

   my_func(1,999,999) obviously doesn't work
   my_func(1'999'999) as per C++14 clashes with our single-quoted strings
   my_func(1_999_999) like in ADA might work

but _999_ would need to work as well and _ is a valid char in a constant
so you can have a constant named _999_.

   - nope
   # nope
   @ nope
   ~ nope
   ! nope
   % nope
   ^ nope

We went through this for the namespace char, and there simply isn't a
typable single character left to use for something like this. _ is the
closest but it would require some changes and BC breaks which I am not
sure is worth for what appears to me to be a not-so critical feature.

Now if we went into Unicode territory, we could do it. eg.

   my_func(1 999 999) U+1680 (although it looks too much like a -)
   my_func(1 999 999) U+205F (mathematical space)
   my_func(1٬999٬999) U+066C (Arabic thousands separator)
   my_func(1·999·999) U+00B7 (middle dot)

The last one looks best to me, but we'd need a team of people working in
shifts to answer the, How do I type this? question.

-Rasmus


how about:

my_func( '1,000.04' );   //if you want to use separators there.


Rick.  Who is firmly in the camp that considers type juggling an 
essential feature of PHP.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Supports 'finally' keyword for PHP exceptions

[Rick WIdmer]

On 7/24/2012 5:45 AM, Laruence wrote:

On Tue, Jul 24, 2012 at 7:41 PM, Alexey Zakhlestin indey...@gmail.com 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 Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Make try/catch brackets optinal

[Rick WIdmer]

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 cont...@leo-peltier.fr 
wrote:


Clearly you don't work in a team or contribute to Open Source projects.
That's what coding styles are for, keeping code looking the same to make
readability easier for not-you developers.


Your team is welcome to set any standards it wants. On itself.  I don't 
believe you should change the language to enforce those standards on the 
rest of the world!


Rick


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files

[Rick WIdmer]

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';



More important include doesn't currently allow multiple parms:

   include foo.bar, 'baz';

Parse error: syntax error, unexpected ',' in bla.php on line xx




Rick


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Go for votes for the open tag-less PHP files

[Rick WIdmer]

On 4/16/2012 1:02 PM, Kris Craig wrote:

On Mon, Apr 16, 2012 at 10:31 AM, Rick WIdmervch...@developersdesk.comwrote:


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 any BC break would be extremely
minimal.  In the 10+ years I've been developing PHP, I don't think I've
ever once seen somebody include multiple scripts on a single line (I wasn't
even aware that such a thing was allowed).


See above.  It is not allowed now.


How about we just keep the parentheses optional and comma-seperate the
arguments?  For example, the require syntax could look like this:

require[(] $script_filename, $script_type = PHP_SCRIPT_TYPE_NORMAL [)];



include/require are language constructs.  They do not require () around 
the parms, and making it optional probably isn't reasonable.  OTOH, 
since it currently only allows one parm, adding a second, optional parm 
should be no problem.





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC: source files without opening tag

[Rick WIdmer]

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 should not know or care what the file extension is.  I 
won't object if you can convince autoloader authors to follow the .phpc 
convention.  Personally, once I can count on this feature, every file I 
include/require will probably be written starting in code mode and using 
the new calling convention.  Even when I use PHP to create page templates...



Additional suggestions:

Add an option so the CLI can start in code mode too.

Add another Handler to the Apache SAPI, maybe 
application/x-httpd-php-code similar to x-httpd-php and 
x-httpd-php-source, so we can configure Apache to start arbitrary file 
extensions with code mode on.  This defers setting the action for 
various file extensions to the person configuring the web server.


Other web server SAPIs will need similar treatment, but I'll leave them 
to someone with personal experience.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar-type-hinting - which way is the best to go?

[Rick WIdmer]

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 the type) with fundamental language design
principles (juggling). You need to understand the fundamental language
principles to understand why any solution MUST lie somewhere in this realm.
Remember that:
1.2 === 12;
2+2 === 4;
substr(12345, 2) === 345;

This type juggling affects the language in all sorts of ways. For example,
PHP uses '.' for concatenation (not '+' like most similar languages) which
ensures that there is no ambiguity as to whether you are operating against
the integer value or the string value. PHP is designed so that you
generally don't have to care whether a value is ACTUALLY an integer or a
string internally, it will be treated as whatever type you use it as. In
PHP int(2), float(2.0), and string(2) can generally be used completely
interchangeably with no variation in results whatsoever. When core devs say
that strict typing would make it not PHP anymore, this is what they mean;
it would badly violate this core concept. If you want scalar typing, you
need a solution that embraces this fundamental design principle.



Yeah, I don't want to start a discussion on that now nor start a (probably
already repeated) war on it, but I think those principles are dead since
very long time...


If you think that the essential core functionality of type juggling is 
dead since very long time you have no business making decisions on the 
future of PHP.  PHP without type juggling is no longer PHP!


Call my opinion extreme if you wish, but I believe Rasmus, the owner of 
the trademark on PHP, has suggested that he would not allow the name PHP 
to be used if it is removed.


If you really, really want strong type in a PHP like language, please 
fork it, rename it, and go away!  See if the market follows you or PHP.




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar Type Hinting

[Rick WIdmer]

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 string to other
types.


In fact, nearly every output from PHP is a string. Also 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 to string from other types.



$x = 1.8;
$y = 2.3;

list( $int, $fract ) = explode( '.', $x + $y );





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

[Rick WIdmer]

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

Re: [PHP-DEV] Re: Clarification on the Enum language structure

[Rick Widmer]

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-world example of its use.

http://msdn.microsoft.com/en-us/library/bb383974.aspx


It's a pretty big new concept that would need to be introduced if this
was desired: extension methods.

I think it's overkill myself. Something like this is fine:

class Grade {
enum {
A_PLUS,
A,
B_PLUS,
B,
...,
FAIL,
NOT_AVAILABLE,
}
public static function passing($grade) {
return $grade=self::D;
}
}
$grade=Grade::B;
echo Grade::passing($grade)?passing:not passing;



Shouldn't that be:

public static function passing($grade) {
-return $grade=self::D;
+return $grade=self::D;

The passing grades all appear before D in the enum, and I expect those 
to have lower values.


Also, I would probably put NOT_AVAILABLE first, since it's underlying 
value is 0.  But then the programmer isn't supposed to consider the 
underlying values...



Rick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecating global + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only

[Rick Widmer]

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 from within a function.


Rick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mail() logging for PHP

[Rick Widmer]

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 what 
would be needed.


I agree.  The most useful information you can possibly put in the header 
is the full URL of the script that sent the message.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature request

[Rick Widmer]

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. Actually, any 
assignment to it if it's not returned by-ref is meaningless, but 
syntactically ok.



foo() = 4;   results in:

Fatal error: Can't use function return value in write context in test on 
line 12.


foo()[1] = 4;   should do the same.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Seeking 'coalesce' php internal function

[Rick Widmer]

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 ];
   }

return false;
}

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Seeking 'coalesce' php internal function

[Rick Widmer]

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