De : Andrea Faulds [mailto:a...@ajf.me]
I’d thought of doing this before, but the backwards-compatibility cost is too
high.
It is a BC break, I agree, but would the impact on PHP community be so high ? I
have never seen any PHP code which would rely on function/class names
I just read Nikita's RFC on deprecated features for PHP 7.
Couldn't we go this way and use his process ? add to his list the fact that
functions, classes, and namespaces can be declared and used/called with
case-sensitivity mismatches ? This would become clearly known by
everyone. Then, as any
De : Pierre Joye [mailto:pierre@gmail.com]
Anyone dying while waiting to see PHP having case sensitive symbols
handling should go ahead with a RFC.
For those interested, I just created a PR to raise an E_STRICT message on class
and function/method case mismatch :
De : Dmitry Stogov [mailto:dmi...@zend.com]
Please take a look into the patch
https://github.com/php/php-src/pull/970/files
This real changes are in zend_types.h, the rest is renaming that in most
cases makes code cleaner.
zend_array didn't change its binary representation, but now
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
On Tue, Feb 3, 2015 at 2:00 AM, François Laupretre franc...@tekwire.net
wrote:
Opening the vote for :
https://wiki.php.net/rfc/cyclic-replace
I guess you mean discussion?
Actually, I wanted to open the vote
De : Xinchen Hui [mailto:larue...@php.net]
I don't understand how you can delete the resource if you remove the
handle from the zend_resource struct. Or would you store the index
elsewhere ?
if you use HashTable , yes, it's hard to get rid of it, but we can
hidden it from user land..
De : Cesar Rodas [mailto:ce...@rodas.me]
I have a doubt, is it efficient include/require files from a source
different than the real file system a stream wrapper class? My
question is, would the op-code cache work as it would when reading a
file form the filesystem?
I understand your
De : Dmitry Stogov [mailto:dmi...@zend.com]
The idea of that RFC was an ability to have zero-cost assert().
DbC is a much more bigger feature, it is interesting, but requires significant
work.
I agree. My suggestion was just to consider assertions as part of this future
work (by using 'dbc'
De : Dmitry Stogov [mailto:dmi...@zend.com]
Hi Yasuo,
You probably talk about https://wiki.php.net/rfc/expectations
I wasn't the author of idea, I just helped with thoughts and implantation.
I think it may be useful for PHP7.
In accordance with Yasuo's suggestions, couldn't we consider
De : Xinchen Hui [mailto:larue...@php.net]
furthermore, I'd like to discuss remove the handle in zend_resource struct..
it may breaks some usage (use resource as long/double/string)
case IS_RESOURCE: {
char buf[sizeof(Resource id #) + MAX_LENGTH_OF_LONG];
int
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.
Cheers
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi,
Opening the vote for :
https://wiki.php.net/rfc/cyclic-replace
This RFC adds support in str_replace() and str_ireplace() for the
combination of
(string needle, array replace). In this case, each occurrence of the needle
is replaced with an element of the 'replace' array.
Cheers
François
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Thank you for your time. It's based on annotation approach. This kind of
implementation requires a lot of work...
I have an idea of a way to do it with limited work. Most important, everything
would be in an
+1
-Message d'origine-
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part
de Adam Harvey
Envoyé : vendredi 6 février 2015 02:23
À : Andrea Faulds
Cc : PHP Internals
Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 6 February 2015 at 04:14, Andrea Faulds
Hi,
De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
Envoyé : vendredi 6 février 2015 19:22
À : Dennis Birkholz
Cc : PHP internals
Objet : Re: [PHP-DEV] Design by Contract
Hi Dmitry,
So, can we start drafting out some things?
Simple questions would help everybody to
De : Pierre Joye [mailto:pierre@gmail.com]
What do you think about the creation of an example extension covering
almost everything one would do in an extension?
The class, methods or functions do not have to be useful but to have simple
clear examples to display the differences with
De : Pierre Joye [mailto:pierre@gmail.com]
Not sure it will help. It is really about showing cases for deref,
duplicate, convert, iterate, etc. The zpp, return values or
functions/class/methods declaration are really the easy part here.
I understand. I thought it would be a nice way to
Hi Dmitri,
Yes, unfortunately, PHP features not compatible with the PHP 5 interpreter will
be harder to adopt for most developers, even if they are not technically BC
breaks.
I agree with your POV, as I now think that it shouldn't be included in the
core, provided we have the needed hooks. I
De : Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Don't we already have this problem with chrooted FPM? I haven't tested it
more recently, but last time I tried, opcache would fail to invalidate the
cache
after updating the file. Worked fine with a non-chroot environment. Not
sure if this is
De : Dmitry Stogov [mailto:dmi...@zend.com]
Yeah, this may work.
The only problem, that it looks not native and defines additional language
for constraints.
I don't talk it's wrong. Both approaches may make sense, but of course, we
have to select one.
Yes, it makes phpdoc more tied to
Hi Dmitry,
De : Dmitry Stogov [mailto:dmi...@zend.com]
Following our conversation, I tried to imagine how DbC should look like in
PHP from user perspective. Finally, I was influenced by the semantic
proposed in D, and syntax proposed for Java. So, these are my initial
thoughts:
Please have
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
We don't have to integrate DbC into phpdoc. phpdoc may have integration of
new DbC syntax.
I think it's helpful even if phpdoc copies post/pre condition as document.
There are too many possibility for DbC syntax.
De : Stanislav Malyshev [mailto:smalys...@gmail.com]
Adding another concept, not changing the existing ones. And really,
it's just simplifying what is already present via is_typename()
runtime checks, making our lives a little bit easier.
There's a very big difference between allowing to
De : Pierre Joye [mailto:pierre@gmail.com]
Yes, it makes phpdoc more tied to the engine but is it a problem ?
And here I have to jump in and say: don't.
And remind about one of the exact purposes of annotations.
Sorry, I am not sure I understand.
If you're talking about the link
De : Dmitry Stogov [mailto:dmi...@zend.com]
I don't like phpdoc approach because we have to define, parse and compile new
syntax for constraints.
Would constraint be able to call other functions? include external php files?
etc?
There are 2 sort of constraints :
- declared types with a
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
How about alternative way that turn 'require' into non embedded mode by INI
switch?
A big NO for me, as I am using 'include/require' in a lot of programs to
include template files containing mixed text/php contents.
De : Ivan Enderlin @ Hoa [mailto:ivan.ender...@hoa-project.net]
Exactly, phpdoc is used as annotation (or comments with some similar
syntax) but is definitively not aimed to be annotations.
Exact. Annotations !== comments. Because PHP has no annotation system,
we used to use comments for
Hi Yasuo,
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Do you think of any negative impact on PHP if we implement D like
in{}/out{} which allow any PHP syntax?
Can you please give your opinion about the BC break a D-like syntax would
introduce ? It is
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Personally, backward compatibility is not too important.
PHP5 is dead by PHP 7.2 release... This is the reason why.
It's only 3 years later, only 2 years later after PHP 7.0 release.
That's where we disagree, as I
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Since people's preferences are diverse. It might be a good idea having
pre-vote
for designs, then we may have final vote with single design.
We need some consensuses even for pre-vote.
What do you think?
What I
De : Jordi Boggiano [mailto:j.boggi...@seld.be]
Envoyé : dimanche 8 février 2015 19:12
À : internals@lists.php.net
Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints
On 07/02/2015 01:08, Sebastian Bergmann wrote:
On 02/06/2015 10:22 PM, Nikita Popov wrote:
After much initial reluctance,
De : Andrea Faulds [mailto:a...@ajf.me]
Instead, I’m wondering if the following might be better:
?php strict
Which would be used like so:
?php strict
function foobar(): int {
return 1.0; // error!
}
It’d be a per-file directive, so there’d be zero mixing
De : Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Doesn't this imply that path is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option
De : Andrey Andreev [mailto:n...@devilix.net]
I seem to have missed the new parameter (and constants) addition
during the discussion ... sorry to say this, but that one would
probably fail the RFC.
Mmh... I don't like the idea of adding a parameter but several people argued
that we needed a
De : Dan Ackroyd [mailto:dan...@basereality.com]
This is pretty horrible and should be fixed by making sure that
constructors either return an object or throw an exception.
Additionally the exception policy for core (that was previously
discussed here:
De : a...@adamharvey.name [mailto:a...@adamharvey.name] De la part
I'm happy to update the manual, but I think I'd want more of a
consensus (not necessarily a formal RFC, but at least a straw poll)
for soft deprecation (to reuse the term we used for mysql_* before
it started generating
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
Given the ability to write foreach ( $foo as $key = $value ), I'm not
sure adding a variant syntax of for ( $key in $foo ) has that much value
for PHP.
+1. Useless and ambiguous.
--
PHP Internals - PHP Runtime Development Mailing List
Hi,
On Sun, Jan 4, 2015 at 1:57 AM, Sara Golemon poll...@php.net wrote:
On Sat, Jan 3, 2015 at 3:42 PM, Nikita Popov nikita@gmail.com wrote:
Or maybe be more explicit and use cstr for C strings. (For symmetry
the
zend_string type could become zstr.)
I personally prefer cstr/zstr for
De : Andrea Faulds [mailto:a...@ajf.me]
I don’t really agree here. For some reason we have this tradition of not using
exceptions for “procedural” stuff. That sort of makes sense for functions, but
classes are “OOP” and therefore I don’t see a good reason why they
shouldn’t throw exceptions.
Hi,
Here's a function definition :
#PHP proto: int newt_centered_window ( int $width , int $height [,
string $title=null ] )
return_type: int
arguments:
width:
type: int
height:
type: int
title:
type:
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
Ohgaki
Both D and Eiffel evaluates all contracts defined in parents/interfaces.
That's not what I understand about pre-condition inheritance in D (check
Hi Lester,
All of the current demands ... and I think they are demands! ... stamp
on past history and load even more work on everybody to have to support
all these new features. Even if dbc is wrapped in comment blocks to hide
it it's potential presence in third party parts of a project means
Hi,
De : Arvids Godjuks [mailto:arvids.godj...@gmail.com]
The 0.1 RFC version was mentioned a lot as a good compromise by many
people
and had major support.
Maybe someone competent could pick it up, make necessary adjustments
that
where required and let people vote on it? Start with
Hi,
De : morrison.l...@gmail.com [mailto:morrison.l...@gmail.com] De la part
Also, I know people REALLY want scalar types in PHP 7.0 but honestly
all we need to do is reserve the keywords so there is no BC impact and
then we can do it at any point during the PHP 7 lifecycle. This is my
Hi Tim,
As I already told you, you should proceed step by step. Implementing immutable
properties *and* removing constants is just a too big step. And, IMO, one may
pass, while the second one has no chance, especially if you propose to remove
PHP constants as well as class constants, without a
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
ini_set(coercion_reporting, COERCION_ERROR); // Fail in case of
potentially bad coercion
foo(7);
// int(7)
foo(7);
// int(7)
foo(7 dogs);
// Catchable fatal error: Unsafe coercion transforming 7 dogs to 7.
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
What if we defined the types as names in the \PHP namespace, but defined
a slightly different algorithm for resolving typehints vs other uses:
function foo(\PHP\types\numeric $a) // unambiguous but unwieldy
function
De : Zeev Suraski [mailto:z...@zend.com]
That means that 42 can coerce into int, and 42.2 can coerce into float,
and int can coerce into float - but not vice versa.
I was wondering : should we systematically reject float to int, or should we
accept it when range fits and fractional part is
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
The biggest advantage, IMHO, is that you get the exact same result whether
you do:
foo((int) $value);
or:
foo($value);
... whatever the mode you are in.
Wrong. Parameter parsing rules are much more restrictive than
Hi Guilherme,
De : guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
orm(
[
new OneToOne(Address),
new JoinColumn(default, default, default, default, CASCADE)
]
)
public $address;
Why not :
orm([
'OneToOne' = Address,
'JoinColumns' = [
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
They'd use whatever (non-reserved) namespace the implementer wanted.
e.g.
namespace Symfony\Component\TypeChecking;
basicType nonNegativeInt extends PHP\types\int {
public function isValid(int $value) {
return $value =
De : Andrey Andreev [mailto:n...@devilix.net]
If we still see that employing the strict(er) rules is very noisy with
internal functions, a more appropriate option may be introducing new
types
into ZPP, that would correspond to the new rules we introduce in the
userland type hints, and
De : Zeev Suraski [mailto:z...@zend.com]
Even though that's not what I meant when I sent my proposal in the
morning,
Sorry, I was not clear enough : it was my position only.
I've been wondering about the same thing (also with the feedback from
Dmitry). Can go an extra step from both
De : Lester Caine [mailto:les...@lsces.co.uk]
Returning 'not-zero/empty' as true and 'zero' as false is one of the
natural things to use in PHP and I don't think any other language has
that flexibility?
You didn't read it right.
I was talking of conversions *from* bool, not *to* bool. (int
HI Dmitry,
Question : in which scope do you evaluate the PHP expression ?
Example :
DbC.requires($a 0);
DbC.ensures(__RETURN__ 0);
function foo($a)
{
...
How can you know from this that the first expression must be evaluated at
function entry, that the second one must be interpreted when
De : Lester Caine [mailto:les...@lsces.co.uk]
My current practice up until now has been to use 'return false' when an
action failed, but the main return would be a number of records or
string of data. So you are now blocking that activity ... I'm reading to
right, but you are not thinking
De : François Laupretre [mailto:franc...@php.net]
This way, the user can write :
function convertToInt(string $number): int! { - int! instead of int
if (!preg_match((^[0-9]{1,17}$), $number)) {
throw new InvalidArgumentException(Supplied argument is not a valid
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
Golemon
1. Tighten up the type coercion for the 1000 dogs case although we
have to look at whether there is a problem with some database APIs
returning space-padded fields so 1000 would now break.
Hopefully
Hi,
Starting making the strict mode weaker is nonsense. It is not just Rasmus'
example. Which exception do you authorize then ? Would you define a third
'pseudo-strict' mode ? And about static analyzers, will they be 'pseudo-strict'
too ?
No, if you want strict, it can only remain purely
Hi Tim,
I imagine you're proposing to drop class constants only, not PHP constants ? If
you want to drop PHP constants, stop wasting your time on this :)
While that's the place to discuss it before you start an RFC, the concept is a
little short.
Could you give at least syntax examples and,
Hi Dmitry
De : Dmitry Stogov [mailto:dmi...@zend.com]
I would propose exactly Andrea's 0.1.
Most people were agree to support weak type hints by default.
This proposal won't prevent feature addition of optional strict type hints.
All are tired from endless arguing.
Yes, but that's not
De : Philip Sturgeon [mailto:pjsturg...@gmail.com]
I know it is very easy for people to say Well, that v0.3 that I
didn't like has been withdrawn, so let's just crack on and do some
other new thing.
It's not so easy. It would be easier to do as you suggest. And you can still do
it in your
De : Pavel Kouril [mailto:pajou...@gmail.com]
Hello,
I know this is probably a pretty unpopular opinion in PHP (based on
the replies I got in the other thread), but different values for
parameters should be IMHO solved by method overloading and such.
The question is not that it's
De : Lester Caine [mailto:les...@lsces.co.uk]
On 17/02/15 18:33, François Laupretre wrote:
What does this mean in your case ? Just that, as long as the feature is not
available, your function won't have an explicit return type. Period. And,
please, don't change false to 0 ;).
I simply
Hi Alexander,
De : Alexander Lisachenko [mailto:lisachenko...@gmail.com]
This RFC consists of two parts: parsing API and parser extension API. Last
one can be rejected, however it can be perfectly connected with annotation
RFC (if AST will be used as values)
Parser extension API is great.
De : Lester Caine [mailto:les...@lsces.co.uk]
On 19/02/15 04:44, Dennis Birkholz wrote:
I just saw the reddit where you mention that v0.4 is practically
abandoned now, so I will just renounce my previous mail!
DO NOT USE OTHER CHANNELS!
Agreed.
And the RFC was not abandoned at all. I
as so important.
Regards
François
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
Envoyé : jeudi 19 février 2015 11:07
À : franc...@php.net; Sara Golemon
Cc : PHP internals
Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
Le Thu Feb 19 2015 at 00:38:25, François Laupretre franc
Hi Lester,
I didn't add restrictions specific to number representation in the draft
ruleset yet, becausen while I think that's an important point, I didn't have
time to study it in depth.
I know you're an expert on this as you continuously (rightly) raised the point.
So, can you elaborate on
De : Matteo Beccati [mailto:p...@beccati.com]
The new methods are:
* ReflectionFunctionAbstract::hasReturnTypeAnnotation()
* ReflectionFunctionAbstract::getReturnTypeAnnotation()
* ReflectionTypeAnnotation::isInstance()
I agree Reflection must support hinting but annotations, int the PHP
Hi Dmitry,
In my mind, annotation syntax was one level lower, dealing with strings of
unknown syntax, not PHP expressions. Something like :
'*' whitespaces '@' STRING free-string-up-to-eol
This supports :
* @requires $a 0
But also :
* @statement INSERT INTO ?? VALUES (13, 'Phoenix', 'AZ',
De : Pascal Chevrel [mailto:pascal.chev...@free.fr]
Does it mean that in your mind the founders of the PHP language
(basically Rasmus/Zeev/Andy) have a veto right on any RFC just because
they are the founders, like in a company with shareholders? If out of
100 votes for a feature, 97 were
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
Saying that's enough isn't even a productive comment. Enough what?
What is it you are asking to happen next?
Maybe an initiative to write an RFC about the rules we should follow when
writing to the list. People who agree could show their
Hi Levi,
Just my opinion :
Add 'resource', 'object', 'scalar', 'mixed', 'numeric'
Remove 'double' (avoid this alias if we decide to encourage 'float' everywhere)
Not sure we'll use Boolean and integer but reserve also.
Hope 'null', 'true', and 'false' can technically be used as type hints. If
De : Pierre Joye [mailto:pierre@gmail.com]
Such as? Competition is good and my past experiences is that in cases
like this one, it is nearly an utopia to think that the other party
will actually try to reach your needs. So the only way to actually get
a RFC representing what you want to
De : Zeev Suraski [mailto:z...@zend.com]
If we do implement the single-mode, stricter-than-pure-weak and
weaker-than-pure-strict ruleset, we could introduce a new set of conversion
functions, along the lines of safe_int(), that would follow the same rules
as the corresponding type hints
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
However, “123” is exceptional. It’s redefining an integer as “ an
integer or a string comprised wholly of digits without leading zeroes,
with an optional leading hyphen, and representing an integer up to
PHP_INT_MAX”
Add leading zeros, and
Hi,
Octal is something that can often be miss converted since it IS the same
as an integer with only a '0' in front in PHP. But that is not something
that can be fixed with the current proposals?
What do you propose ? Considering leading zero as octal indicator is not an
option, IMO. If you
De : Robert Stoll [mailto:p...@tutteli.ch]
Strict mode is useful in the sense that it prevents unnecessary implicit
conversions (which are costly) and it improves readability.
Following an example:
function foo(string $x, int $y){
bar(1);
return strstr($x,hello, $y);
}
function
Hi Andrey,
De : Andrey Andreev [mailto:n...@devilix.net]
I too am curious about the potential issue with 123 to 123
specifically, although it could be seen as a subset of another problem
that is solved with strict hints - numeric-character string
identifiers being erroneously treated as
De : Benjamin Eberlei [mailto:kont...@beberlei.de]
nested can be done in any way, its a statement so the following would work:
orm(new JoinTable(['joinColumns' = [new JoinColumn('id', 'other_id')]]))
Dmitry is planning compile time evaluation, which is probably the only way to
do it if we
De : Andrey Andreev [mailto:n...@devilix.net]
Consider the following signature:
function foo(int $bar) {}
In the case of a *string* representation of a hexadecimal number, the
following would error only on the last iteration with a weak hint, and
on the very first if it was a strict
Hi Nikita,
I don't like the way this is heading with regards to internal functions.
Apart from better inter-compatibility, the primary appeal of Andrea's
proposal was that we have the option to make not only userland function
calls strict, but internal ones as well. With these modifications
Hi Michael,
The case of null is a little special.
As a type hint, we need it for return and union types only.
Considering union types, they were clearly left out of scope for 7.0 and I
personally won't propose pre-defined union types before the general case for
unions is designed. Conversion
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
That's precisely the case for every existing user-defined function.
Switching to PHP 7 won't suddenly add type hints to every function in
every library and every existing bespoke code base, so there is no way
to avoid that thought process.
De : Leigh [mailto:lei...@gmail.com]
Can we keep a 0) of reserve names for future use in-case of RFC
failure option.
Reserving names is only needed as long as we keep keywords sharing the same
naming space as classes. This is a mistake from the past and, as long as we
keep it, each new
Hi Bishop,
De : bishop.bett...@gmail.com [mailto:bishop.bett...@gmail.com] De la part de
Bishop Bettini
THING 1: Hints are just is_* wrappers
Wrong. Only *strict* types are.
THING 2: Hints are truthy callables
function my_mixed($m) {
return (null === $m || is_string($m));
}
Hi Dmitry,
Right. That’s what I got from your last reply. But my question was about
another post where you are talking about ‘compile time evaluation’ of
expressions, which is different from the bare key/value storage I understood
first, and poses the problem of compile time evaluation
De : Lazare Inepologlou [mailto:linep...@gmail.com]
So, yes it would be nice null not to be included in scalars. Instead, we
could have a union type like scalar? = scalar|null
That's roughly the idea. However, IMO, the general mechanism for union types
needs to be defined before we start
De : Pádraic Brady [mailto:padraic.br...@gmail.com]
Careful, it helps not to call folk radicals if you intend to pursue
a compromise with them ;).
Sorry, english is not my native language, and 'radical' may be offensive.
I was just looking for a word for people who consider providing two
If I understand Dmitry correctly, this would be stored as the compiler internal
representation of the 'new Entity(foo)' code, but this wouldn't be executed
until an external mechanism decides to do so. So, this is PHP code and it is
compiled and stored in memory besides the function opcodes,
[mailto:patrickalla...@php.net]
Envoyé : jeudi 19 février 2015 13:46
À : franc...@php.net; Sara Golemon; PHP internals
Objet : Re: [PHP-DEV] Scalar Type Hints v0.4
Le Wed Feb 18 2015 at 19:10:08, François Laupretre franc...@php.net a écrit :
De : Patrick ALLAERT [mailto:patrickalla...@php.net]
The biggest
Hi Sara,
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara
Golemon
So, if you'll permit me to summarize your message. The following
would be palatable to you?
* Lossless coercion. This would sit somewhere between strict types
and weak types as lossy conversions
De : Rowan Collins [mailto:rowan.coll...@gmail.com]
I would like to propose that the error given for an undefined constant
should be raised from E_NOTICE, probably to E_RECOVERABLE_ERROR, in
PHP 7.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi,
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
I would like to propose that namespaces, functions, and classes become
case-sensitive (constants are already case-sensitive). Actually, I never
understood why they are case-insensitive. Even if the
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
Mixing both, having some types on the left and others on the right,
seems like another inconsistency in the language
design to me.
These inconsistencies exist for two reasons:
- Opposition to doing it the
De : Dan Ackroyd [mailto:dan...@basereality.com]
However I think there is a strong risk of people having to give a
reason why they voted no being abused, particularly if it is shown
while the voting was taking place, as people could be harassed for
choosing an 'invalid' reason to reject the
De : Xinchen Hui [mailto:larue...@php.net]
we used to use lval of zval as a handle to access resource type..
but now, we introduced a new type IS_RESOURCE, which make the
handle(id) sort of redundant .
Wrong. The IS_RESOURCE type has nothing to do with PHP 7. Only zend_resource is
-Message d'origine-
De : p...@golemon.com [mailto:p...@golemon.com] De la part de Sara Golemon
So, I've been meaning to propose something *like* this, but with a few
key implementation detail differences:
1) Create the notion of Persistent User Functions/Classes/Constants/etc
2)
De : Pierre Joye [mailto:pierre@gmail.com]
2. We have no easy way to actually release and deploy adhoc scripts,
used by a given extension
For 2., it is one of the thing I can imagine implementing in pickle.
Or even better add it a s part of the build scripts and macros. Either
will
De : Pierre Joye [mailto:pierre@gmail.com]
Even better than a server side hook, far less intrusive and rejecting
a commit when CS are broken before it even gets applied locally sounds
like the best solution so far.
If it is technically possible, I think we need both.
Local-side
1 - 100 of 415 matches
Mail list logo
