Re: [PHP-DEV] RFC: Trait expects interface
I'm not convinced it does, actually. Consider the following trait:
trait PropertyCount {
public function count(): int {
return count(get_object_vars($this));
}
}
This trait CAN be used to implement the built-in Countable interface, and it might be useful to label it as such; but does it really make sense to say
that classes MUST implement that interface?
IMO yes, it does. This simplifies rules for detecting implementation of interfaces in
traits, so you don't get "yes and no" answers in that case.
I'm not really sure why would you not want this - what is the point of marking method as interface implementation, if it is not reflected by type
system in actual execution? If it does not make sense in case of your `PropertyCount`, then do not use this feature.
Even if we put it as a requirement, we can't guarantee that the class will actually use the trait's implementation of the interface, because this
would still be valid:
class Foo implements Countable {
private $whatever;
use PropertyCount {
count as getPropertyCount;
}
public function count(): int {
return 0;
}
}
It works the same for classes and inheritance - if you declare `Foo::count()` directly in class, I can always create `FooBar extends Foo` that
overwrites your implementation. But I never heard that someone complain about it, so I'm not sure why this is suddenly a problem for traits. Ensuring
that particular implementation is used is not the purpose of interfaces, it never was.
Also note that right now method signatures from trait can be changed by class,
so PHP won't complain about this:
trait T {
public function t(string $t): void {
}
}
class C {
use T {
t as tt;
}
public function t(): string {
return 't';
}
}
This proposal gives you tools to ensure that class does not mess up with method signatures expected by trait - you can create pairs of trait-interface
and require interface in trait.
--
Regards,
Robert Korulczyk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Trait expects interface
In your use cases, are these traits generally *using* the interface methods, or *implementing* them? It is both. However "implementing" case is more problematic, since "using" can be quite reliably handled by adding `assert($this instanceof LoggerInterface)` or type hints in trait methods - SCA tools should handle this and PHP will complain if interface is not implemented. But there is no easy way to say "`FooTrait::someMethod()` is implementation of `FooInterface::someMethod()`" that PHP and SCA will understand. And I think this proposal handles this quite well, since it does not introduce implicit "implements" (IMO introducing another way of "injecting" interfaces to classes will just hurt readability) - you still needs to add interface to "implements" section in class definition, but traits have more tools to define its purpose and ensure that classes have proper definition. -- Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Trait expects interface
Your other points make sense, but I don't think this one does - there are no implicit interfaces in PHP*, so all any tool cares about is: 1) Does the class declaration say that it implements an interface? 2) Does it actually contain the methods needed to do so, through any combination of direct implementation, inheritance, and trait usage? Knowing that a particular trait *could be* used to implement a particular interface without further code doesn't really tell the tool anything - it still has to resolve the list of methods on the class itself, and test those against the "implements" clause. You're talking about classes that use traits, but I'm talking about traits themselves. If I open a class in editor, there is a straightforward way to check if specific method is implementation of an interface - check interfaces implemented by class and if one of them have this method, then this method is implementation of this interface, and editor can properly mark it and handle navigation between implementation in class and declaration in interface. So even if I have a big project, you need to only load a subset of classes used by this project in order to find methods that are implementations of interfaces in this particular class. If I open trait in my editor, it is a lot more complicated. Editor needs to scan the whole project, find all classes that use this trait, find all interfaces that are implemented by these classes, and then find matches. And you may still end up with confusing results, because if you have class `A` that implements `FooInterface` and uses `FooTrait`, and also class `B` that uses `FooTrait`, but NOT implements `FooInterface`, then if you ask if `FooTrait::someMethod()` is implementation of `FooInterface::someMethod()`, the answer is "yes and no". Also, I'm not sure how it works now, but about 2 years ago I got rid of most of traits in one project, because navigation between trait and interface worked so badly in PhpStorm, that it was easier to deal with code duplication than broken "implements" detection. At the same time navigation between classes and interfaces worked without any problem. -- Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Trait expects interface
> For point 1, we already have that. It's called abstract methods in traits. This is a solved problem that requires no further resolution. At best
it would be a shorthand to copying a few methods from an interface into the trait and sticking "abstract" in front of them. I really don't see a need
for that.
You can say exactly the same about traits in general - you don't need traits at all, since you can copy method implementation into multiple classes,
in the same way as you're proposing to copy abstract methods declarations. But traits are implemented and they're useful - they reduce the amount of
code duplication, which means less work and a smaller surface for errors. It is the same case for this proposal - if you don't need to copy
method declarations from an interface, that means less code duplication and possible errors. It should also make it easier for SCA tools to understand
the code since they no longer need to know the whole project to understand that method from trait is implementation of method from interface (which is
really tricky right now since it depends on context - trait can at the same implement and not implement the interface, because it depends on class
where it is used). And finally, you could use `{@inheritdoc}` in some meaningful way in traits - right now there is no straightforward way to inherit
phpdoc from the interface, and often this is what you want to do.
--
Regards,
Robert Korulczyk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property accessors
W dniu 04.05.2021 o 18:32, Marco Pivetta pisze: > I'd strongly advise killing by-ref array push there: it's an acceptable > limitation, for the amount of benefit we get :P > In fact, people doing `__get` now are already familiar with "Indirect > modification of overloaded property" (https://3v4l.org/6dTXK) They are familiar, but this is not a reason to cripple property accessors concept with the same limitation as `__get()`. "Indirect modification" is really annoying, and using reference to bypass it looks more like a dirty hack than real solution. If we can avoid "Indirect modification" for implicit accessors without involving references, then it is definitely worth it. And this is important for explicit accessors too - in my case like 90% virtual properties are some kind of conversion between string and array, where getter returns array generated from string. It would be great to handle this too, even if it will be only syntactic sugar, where `$object->property['key'] = 'value';` will be equivalent of this dance: $temp = $object->property; $temp['key'] = 'value'; $object->property = $temp; Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
> $foo[$key1] has to be read to determine if it's already an array, and if it > has the key $key2, in the same way that in $foo[$key1]++, $foo[$key1] has > to be read to determine if it's already an integer and what it's value is. $foo[$key1] needs to be read only to obtain previous value, type is irrelevant (obviously you will get error if types does not allow for such operation, but it has nothing to do with accessing uninitialized variables/keys). You can't increment $foo[$key1] without knowing current value of $foo[$key1] - you need to read it first. But you don't need to know previous value (or its type) to overwrite it (it does not matter what is $foo[$key1] value if you do `$foo[$key1] = 1` - it works similar to `$foo = 1`); Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
> Why? If "assume $key2 exists as a key and is an integer" is so bad that PHP > should halt my program, why should "assume $key1 exists and is an array" > be perfectly OK? Warning is triggered by reading non-existing key, not assigning value to it. In `$foo[$key1][$key2] ??= 0` you never try to read non-existing key. > Please can you show me a bug that adding this line has avoided? I don't doubt > that the same warning saves bugs in other scenarios, but in this > scenario, the logic is unambiguous, and any additions are just to suppress > unnecessary errors. Well, then let's say that it is "lesser evil" - one additional line is better than ignoring reading uninitialized values. And IMO it is not a "problem" that would justify introducing special syntax for saving one line in such niche case. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing fundamental language behaviors
> Upgrading the ~68,000 open source plugins available on wordpress.org > <http://wordpress.org/>, thousands of commercial plugins, and and an untold > number of custom-developed bespoke plugins and custom themes is where the > concern lies. Many of these are ticking bombs - unmaintained extensions with possible security issues. Right now the biggest problem of WordPress ecosystem is quality of community extensions and themes. Cutting of all old and unmaintained extensions may be not that bad... Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
W dniu 12.09.2019 o 22:45, Rowan Tommins pisze:
> On 12/09/2019 15:43, Robert Korulczyk wrote:
>> One additional line will make your code much more obvious and easier to read
>> and understand:
>>
>> $i ??= 0;
>> $i++;
>
>
> I don't find this code at all obvious:
>
> foreach ( $something as $foo ) {
> $i ??= 0;
> $i++;
> }
That is because it does not make sense. You should initialize $i before loop,
since it does not need a loop at all (and you probably don't need ??= here):
$i ??= 0;
foreach ( $something as $foo ) {
$i++;
}
> Even using ??= the initialise-everything-before-use version looks like this:
>
> $foo = [];
> foreach ( $something as $key1 ) {
> foreach ( $somethingElse as $key2 ) {
> $foo[$key1] ??= [];
> $foo[$key1][$key2] ??= 0;
> $foo[$key1][$key2]++;
> }
> }
Actually you need only one additional line:
$foo = [];
foreach ( $something as $key1 ) {
foreach ( $somethingElse as $key2 ) {
$foo[$key1][$key2] ??= 0;
$foo[$key1][$key2]++;
}
}
> Again, the values are confusing: the end result will never contain an empty
> array at the first level, and will never contain a 0 at the second level.
It does not look confusing. You have two lines, for two intents - start
counting from zero and increment counter on every loop iteration. If one
additional line is to much for making your code less ambiguous and more
bug-free, then I won't even try to change your mind.
Regards,
Robert Korulczyk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
> But, if you're dealing with a counter, then, the intent is that you are > going to start counting at 0 and increase it. This is not that clear as you may think. Several questions may come to mind when you will see incrementation of non-existing variable/key. Is it a bug and this should be initialized with a different value than 0? Maybe a mistake on copy? Maybe a typo? One additional line will make your code much more obvious and easier to read and understand: $i ??= 0; $i++; Your code is not only for compiler/parser, but also for humans. Expressing your intentions clearly is important - the less ambiguity the better. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
> Good for you! Come take a stab at my legacy project. It's horrendous. We have > some files where using PhpStorm's automatic formatting actually caused > stuff to break. So, you can see why I might be a little reticent to depend on > an automated tool to change my php tags. I'll let you start with a 12k+ > line file of spaghetti code. This file contains a lot of functions (not OO) > used across the legacy parts of the application. As such, it's included at > the top of pretty much every PHP page. So, make sure you don't leave a typo, > because it'll break the entire application! I know how painful could be maintaining legacy code, but did you tried to run php-cs-fixer against this 12k+ file with PHP-spaghetti and report some actual issues? You're spending time theorizing how automated tool can break your legacy code, but it would be far more productive if you spend it on actual tests - this would give us very valuable insights how serious this problem is. Right now these are nothing more than *speculations* based on usage of *completely different tool* for *completely different task*. Please, don't treat it as some hard argument. > While you are at it, you can explain to my executive team (I don't work for a > software company) why it's worth putting in the time to modify all > these "don't touch unless it's an emergency" legacy files to upgrade PHP when > the current version seems to be working fine from their perspective. Sure. It would be something like: "Hey, it's *emergency*!" ;) > That's another difference I've seen from the two sides of the argument. Those > in favor of removing them usually say things like "It doesn't seem like > a big deal to me" or "I converted a project and it was really easy" or > "People shouldn't be using short tags anyway, so who cares." While those > against removing them usually say things like "I can see how this could be a > huge problem for a large number of users" or "This could definitely block > a lot of people from upgrading in a timely manner." This is one side of the coin. I'll show you another: I gave a real-world example that short open tag could lead to serious fuckup and be undetected for quite a long time. I also gave an example of how easy is to accidentally introduce short open tags in your code. There are other people who also treats short open tags as dangerous feature and security issue. Despite this, I can read multiple times that "short open tags are no-issue" or "there is no gain in removing short open tags". In counterargument for this RFC you can read that "Deprecating short tags, as illustrated in this counterargument, brings us *virtually no value at all*.". There is no difference between both "camps" - both are focusing on their perspective and their arguments, while underestimating problems and arguments of other "camp". For you existence of short open tags is minor issue, for me migrating to `http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
> While possibly a bit hyperbolic, most of the arguments basically come off > that way to me as well. I've definitely viewed most of what you've said in > that manner. I guess we're in some kind of limbo where half of the people do not consider problems which short open tags create as serious, and other half does not consider BC break implications as serious. I already migrated some quite big legacy apps from `http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
> This discussion has gone out of sanity levels the moment people started to > state that short tags is one (of the many) > things PHP has why new programmers and companies don't pick the language or > why colleagues laugh at you and is a > blocker of new bright future etc. and now in this moment this is a do or die > situation otherways next year everyone > will be writing in javascript. No one said that (except you). But current reaction for this RFC could be depressing. I'm using PHP for quite a long time and I really hoped that someday we'll be able to get rid of all (or at least the most of them) the traps and annoying little things from the old days. That doesn't sound realistic anymore... > Except there are 4-5 functions which do the same not to mention `` backtick > syntax (can't there be an accident mixing those with single quotes?). I was talking about all these functions that allows to execute shell commands. What is the point of disabling only one of them? I thought that the problem is in functionality, not in the name :P >> `` is intended usage of short open tags. > > On this I could also say that recommendations are to store all credentials > outside webroot, I'm afraid you don't understand the problem. Having such code outside of webroot does not help you much if this file will be included from another file (which uses `http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
W dniu 14.08.2019 o 14:14, Reinis Rozitis pisze: > Depends on how you look at if exec($_GET['param']) is a language > responsibility or programmers? Please, let's keep this discussion at some level of sanity... You basically need stick to static HTML if you're considering possibility of such exec() usage as a security issue. They're at least 3 main deferences between short open tags and exec-like functions: 1. exec-like functions have their purpose without any straight-forward alternative, while `` is intended usage of short open tags. 3. Because of point 2, there is no IDE or editor which will generate code like `exec($_GET['param'])`, while there is at least one popular IDE which will generate code with short open tags. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
> Sure those are important - I was just pointing out that the "security card" > is questionable since the language has more dangerous features > which ask for the user to be careful and responsible about them rather than > making everything foolproof and accident-free. Honestly, I don't see how allowing exec/passthru/proc_open is a security risk. These are just tools. We're talking about programming language - if you're running PHP script as user X you should expect that it could do anything that user X can do. If you don't trust this script, just don't run it - disabling exec/passthru/proc_open does not change much since PHP is powerful enough to hurt you badly without executing any shell commands. If you think that disabling exec function will protect you from malicious scripts, then you have real security problem related directly to your environment and completely unrelated to PHP (it is OS responsibility to disallow access to part of the system, which should not be accessed by a particular program). > Considering the current RFCs has it really been decided as "don't use it" > (when/where?)? https://www.php.net/manual/en/language.basic-syntax.phptags.php "PHP also allows for short open tag http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
W dniu 14.08.2019 o 12:09, Reinis Rozitis pisze: > It's questionable that a misconfigured environment is a "security" risk > caused by language rather than ignorance of the administrator. This is not about misconfigured environment. This is about accidental usage of *language* feature, which *by design* can lead to code leaks (so application bug, not misconfigured environment). Clearly not a language problem that it has dedicated feature to shoot yourself in the foot... > On that matter you could ask why are all the exec/passthru/proc_open etc > functions/features are allowed by default while every other guide on hardening web suggests those to be disabled (added to disable_functions)? These methods have their purpose (pretty important BTW), short open tags is just "don't use it!!!" feature. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecate PHP's short open tags, again
W dniu 14.08.2019 o 11:09, Christian Schneider pisze: > Am 14.08.2019 um 10:39 schrieb Peter Kokot : >>> The best counterargument I can give against "cleaning up" is that it takes >>> energy away from actual new features, even if it's just the mental energy >>> of monitoring and responding to long threads like this one. >> >> Code is like a garden. If there are unwanted weeds and nobody cleans >> them up, the flowers don't shine and grow as they should. Cleaning of >> the weeds is just as important as new features. A bit less but >> important. > > Going with your analogy: Some things (like short open tags) are that > individual small flower in the corner of the garden which does not multiply. > We already spent way too much time discussing it, the rest of the garden > needs water and the gardeners are fighting over a dandelion. A bike-shed > discussion at its worst: No real gain but everybody has an opinion. > Real cleaning up, now that's where it gets interesting. And those discussions > tend to be more productive even recently. > > Oh and: I'm very much afraid the OP was trolling and succeeded in getting > people to react, so please, please let this particular thread die :-( > > - Chris > > It is surprising how thing that is considered by one to be a security risk, is treated as nothing relevant by others. This dichotomy is quite disturbing - in what case removing security risk is "no real gain"? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> Disabling short tags now is done with "an explicit directive" (there has to > be a specific ini file with a specific setting 'short_open_tag = 0'). > Isn't this the same "situation when you create a separate file with an > explicit directive"? No, it's not. `php.ini` is outside of project responsibility - as a developer you don't really configure this in any way, your application does not have any explicit directive to disable/enable short open tags. You just accidentally using feature that could lead to code leak. In your example with `engine` directive you explicitly disable PHP engine by creating dedicated file for that purpose - there is no way do to this by accident and then does not notice it. > If a coder (or IDE) has written ' unless tested the effect (a part of code not being parsed/executed) will be > exactly the same if the feature suddenly disappeared (unless the additional > checks in the 'v2 RFC' which on the other hand would make the engine a > tiny bit slower but probably have to be implemented to avoid such accidents). At least the this behavior will be consistent - you will not have cases when code works fine on one environment and leak on another. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
> I'm not sure what you're saying here exactly, but if you are suggesting > that PHP.future, whatever this future version number is - is going to be a > strictly typed language, with total disregard for BC /../ I'm suggesting that PHP could stop worrying about "super legacy code which uses short open tags and nobody wants to touch it" and move on. Code that nobody wants to touch can just use PHP LTS and PHP project could focus on programmers and actively developed projects. > Whether it's a fork or LTS - this is a *radical* duplication of effort. Bigger than creating P++ and having two different and competing languages? I highly doubt. Also, the LTS line could (and probably should) be sponsored. For example, most of BC breaks does not seem to be a problem for OSS. This is mostly a problem for companies with big and legacy applications, who don't want to spend money on upgrading them. If BC breaks are really such a big problem for thousands of companies, there should be no problem to find founders to pay ~1 developer for maintaining LTS line and backporting security fixes. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> I did mention such example with the 'engine' setting ( > https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's > PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik > it's sapi specific) but technically it can happen just in one "hard to > notice" subdirectory/tree. This does not explain how someone could use that feature *by accident*. I gave an example where you can use short open tags by accident, and it is really easy (the most popular IDE sometimes generates code with short open tags) and hard to notice (it is not easy to spot a difference between `http://www.php.net/unsub.php
Re: [PHP-DEV] Bringing Peace to the Galaxy
> I think it should also be pointed out that there's nothing stopping anyone > from forking PHP into a new project as Zeev described and maintain feature > parity. As I understand, the reason something like this hasn't happened > already is because it would involve a ton of work and nobody wants to deal > with it. But if you or anyone else does manage to put a team together and > make something like this happen as a separate project, I'd certainly have > no objection. It does not need to be a fork. AFAIK there is no technical obstacle to extend lifetime of particular version on PHP and create some kind of LTS line. For example, PHP 7.4 could be supported for 10-20 years (probably with security patches only), so everyone who has "legacy - do not touch it!" code can stick to 7.4 line. Everyone else could just move on and use PHP 8 with all new features and BC breaks. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> Argument for "only a particular code path in a particular environment" is > somewhat weak because in that case why does even ' .user.ini' feature exists > (especially in apache sapi where you can even do engine = 0) as it also can > lead to wildly different language behaviour? Can you give an example where using `.user.ini` may create unexpected and hard to notice code leaks? Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> I'd say this is not really a language concern and more tooling and testing > problem. It's a class of a genuine mistake everybody does from time to time > - be it wrong PHP tag, HTML tag or closing } added on the wrong line > resulting in a logical error. This is a direct consequence of the language having settings that cause the same code to be interpreted (and works perfectly fine) in one environment and be displayed in other (without any warning). This is not the same as a typo in HTML tag or logical error in code. This is literally a tool for shooting yourself in the foot - it exists, but no one should use it. And it is still really easy to use it by accident. For example, this is what PhpStorm generates when you try to inline-comment tag with short echo: Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> Many people have talked about the potential impacts of keeping short tags. > I have yet to see anyone give an actual example where they have been > negatively impacted by their existence. I've given you my personal story of > how removing them will negatively impact my company. I welcome anyone that > can provide an actual incident where the existence of short tags hurt them, > or, the continued existence is likely to have a large negative impact on > them in the future. I was bitten by short open tags. Despite the "no short open tag" policy in our app, one occurrence of `http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> PHP is, after all, built almost entirely on extensions. Those extensions can > either be there, or not, enabled in the INI, or not. Do we consider code > written containing functions from mysqli, gd or zip (just to name a few) to > be non-portable because we can omit them from the INI (or just not install > them). These are completely different things. In case of extensions, you can check whether the extension is installed, you can react on lack of it, and you can require extension as part of composer constraints (sometimes you can just use polyfill). And at worst case, you will get a fatal error that will tell you that there is something wrong with your code/environment. Neither of it is true for short tags - your code is just silently displayed. And you can't do anything about it, because you're code is no longer a code. > IMHO short tag removal has one major thing going for it, consistency, and by > extension, predictability. > > That's it. For me, the main reason to remove short tags are code leaks. As long as there will be an option to disable short open tags support, there will be code leaks. Now there is a chance to remove one source of WTFs in PHP and end this code leaks problem once and for all. The migration may be problematic for fraction of applications, but at least this is a one-time process, well documented and preceded by a long deprecation period. The alternative is current state when code leaks just unexpectedly pop out without any warning and explanation (exception "It's PHP, deal with it"). Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> Turning it on permanently would also solve the problem Well, yes, although it creates "another way of doing the same thing". So far PHP was on a way to remove redundant tags. Permanently enabling of short open tags looks like a move in the opposite direction. Personally, I'm surprised by the controversy around this change. So far it was an obvious anti-pattern for me, and never seen anybody who was aware of the consequences of using On 4/11/2019 1:12 AM, Robert Korulczyk wrote: >>> Sorry for the sarcasm, please don't consider this as a personal attack. The >>> whole community (not just you) considers short open tags poison because not >>> XML-compatible... >> >> This is rather removing another trap from the language. As long as short >> open tags exist and depend on INI directive, there will be bugs and source >> code leaks after moving application to a different environment. Using > over > external tool to enforce this. > > I wouldn't say it is the ONLY safe way. Turning it on permanently would also > solve the problem and there's also allowing ' as a permanent always-on option. (Native XML compatibility is a complaint, > not a requirement of a language. XML is also basically dead in my corner > of the PHP universe, only ever cropping up on very rare and very confused > occasions.) > > It's going to be interesting to see how many people who rely on and *prefer* > using short open tags in internal systems come out of the woodwork when > PHP 7.4 and 8 drops. Maybe I'm the only one who likes saving a few > characters here and there and thinks code is more readable without the > verbose tag. > > The vote is on the knife's edge of passing/failing at the moment and could go > a couple of unusual directions as already noted elsewhere. This is > probably the most interesting RFC *vote* to happen in a long while. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... This is rather removing another trap from the language. As long as short open tags exist and depend on INI directive, there will be bugs and source code leaks after moving application to a different environment. Using Finally!!! everybody will be able to parse my xml files with embedded > php1!1 if I ever wrote one!!! > > Sorry for the sarcasm, please don't consider this as a personal attack. The > whole community (not just you) considers short open tags poison because not > XML-compatible... while they use stuff like twig, which is also not > XML-compatible. > > This is just beyond my understanding. > > But sure, let's keep vilifying this kind stuff and pretend they are the > root cause of PHP's bad rep. > > Sorry again for the negativity. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mixed type-hint
> Could you clarify on a use-case for changing the semantics of `mixed`? For example storage which does not allow to store null. Like simple cache which treats null as "miss", so it is not able to cache null as value. Obviously it is not a deal breaker and use case is quite rare anyway, but this is just example when mixed type-hint may work as actual type-hint, not just replacement for PHPDoc or equivalent of... nothing. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mixed type-hint
Sounds like an arbitrary interpretation. Treating `?mixed" as "top type" (including null) would be more practical and consistent with other type-hints. Regards, Robert Korulczyk W dniu 08.02.2019 o 12:47, Marco Pivetta pisze: > `mixed` is the "top" type, which means that it contains anything at all. See > https://en.wikipedia.org/wiki/Top_type > > On Fri, 8 Feb 2019, 12:45 Robert Korulczyk <mailto:rob...@korulczyk.pl> wrote: > > What definition? > > Regards, > Robert Korulczyk > > W dniu 08.02.2019 o 12:37, Marco Pivetta pisze: > > Mixed includes null by definition. > > > > On Fri, 8 Feb 2019, 12:21 Robert Korulczyk <mailto:rob...@korulczyk.pl> <mailto:rob...@korulczyk.pl > <mailto:rob...@korulczyk.pl>> wrote: > > > > > Without this, the mixed type-hint is basically meaningless noise, > is it > > > not? About as effective is a doc-block? > > > > This mixed type seems to be meaningless by design since its main > goal is to work the same as if it was no type-hint at all... > > > > Another thing is that including null as part of mixed is not very > pragmatic - mixed could be used to disallow null, so it will actually work > for type > > check. > > > > > > > > Regards, > > Robert Korulczyk > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mixed type-hint
What definition? Regards, Robert Korulczyk W dniu 08.02.2019 o 12:37, Marco Pivetta pisze: > Mixed includes null by definition. > > On Fri, 8 Feb 2019, 12:21 Robert Korulczyk <mailto:rob...@korulczyk.pl> wrote: > > > Without this, the mixed type-hint is basically meaningless noise, is it > > not? About as effective is a doc-block? > > This mixed type seems to be meaningless by design since its main goal is > to work the same as if it was no type-hint at all... > > Another thing is that including null as part of mixed is not very > pragmatic - mixed could be used to disallow null, so it will actually work > for type > check. > > > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mixed type-hint
> Without this, the mixed type-hint is basically meaningless noise, is it > not? About as effective is a doc-block? This mixed type seems to be meaningless by design since its main goal is to work the same as if it was no type-hint at all... Another thing is that including null as part of mixed is not very pragmatic - mixed could be used to disallow null, so it will actually work for type check. Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC Weakrefs
> I can't really think of another name ... it's ... a weakref ... It is actually "weak reference", so why not WeakReference? Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
> Just to be sure you don’t miss the herd that this elephant is concealing: > > In addition, you *must* forbid unset() on those properties... Shouldn't we delegate the whole problem to object type resolving and make it more strict? Right now properties are not guaranteed at all - you can have `Foo` class with `$bar` property, but it does not mean that instance of `Foo` will actually have this property. The current implementation of typed properties seems to be pretty consistent with this. Type check gives you nothing as far as the object's properties are concerned. But if `$foo instanceof Foo` or `function (Foo $foo)` will test that `$foo`: 1. is an instance of `Foo`, 2. has all properties defined in `Foo`, 3. all typehinted properties are initialized, then the problem will basically disappear - you can protect yourself from propagating uninitialized object by typehints or type checks (which you would probably do anyway). And you still can create an uninitialized object for lazy initialization or whatever you want. -- Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
