Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
On Fri, Nov 7, 2014 at 3:50 AM, Stas Malyshev smalys...@sugarcrm.com wrote: I find it very hard to accept this particular argument. Honestly, I find it hard it too. The reason I started this is that I tried to do something like $foo instanceof $bar-getClassName() and I got a syntax error. It looks very straightforward and it should be the expected behavior, except that it doesn't work. So this is the main reason I started thinking about this: it's an improvement that aims readability and easiness. Now, I'm sure you can agree with me that it's way better than having a variable holding the class name. --- Daniel Ribeiro http://danielribeiro.org
Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
On Thu, Nov 6, 2014 at 1:01 PM, Stas Malyshev smalys...@sugarcrm.com wrote: You could of course require the expression to always be enclosed in (), but that produces weird syntax where some forms of instanceof work without () and some only with (). Given that you can easily assign your value to a variable, is it worth it? Also, you can always use is_a($foo, $bar-getClassName()). This is exactly what I'm doing right now, requiring the expression to always be enclosed in parenthesis. I think it's way better to be able to do this instead of creating temporary variables just to assign a class name. Also, is_a, since it's a function, is significantly slower than instanceof, which is a construct (but of course you already now that). Daniel Ribeiro http://danielribeiro.org
Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
On Thu, Nov 6, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote: Perhaps, dare I say it, we should merge the constant and class namespaces in PHP7? Those are perhaps the least likely to conflict. It’d mean we could handle instanceof expressions, and we wouldn’t need to use ::class. Hi Andrea! I'm not sure I understand what you mean by don't need to use ::class. Currently, we can only use the class constant itself, like $foo instanceof stdClass or a string representation of that class' name. Concerning the parenthesis, I agree they shouldn't be treated differently, but as for now they are. Daniel Ribeiro http://danielribeiro.org
Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator
On Thu, Nov 6, 2014 at 3:49 PM, Andrea Faulds a...@ajf.me wrote:
By merging the symbol tables, you could reference classes like constants
(perhaps it’d return some sort of ReflectionClass-like thing?):
$x = SomeClass;
$foo = new $x;
Currently, because SomeClass above would resolve to a constant, you have
to use the weird pseudo-constant ::class:
$x = SomeClass::class;
It also would mean instanceof could accept arbitrary expressions, as
there’d be no syntactic ambiguity:
class Foo {}
const Bar = ‘Foo';
$x = (new Foo) instanceof Bar; // works (Bar resolves to ‘Foo’, valid
class name)
$x = (new Foo) instanceof Foo; // works (Foo is a class)
const Foo; // Not allowed, conflicts with class
Yeah, that makes perfect sense.
Also, I just realized that HHVM accepts expressions wrapped in parenthesis.
I might need to take a look at how it's done there.
Daniel Ribeiro
http://danielribeiro.org
[PHP-DEV] Allow arbitrary expressions when using instanceof operator
Good morning, internals! I would like to present to you an idea that I have for a syntax improvement for PHP. The basic idea is to allow arbitrary expressions when using the instanceof operator. Currently, the second operand can only be a constant reference or a string: $foo instanceof stdClass; What I want to implement is the ability to allow arbitrary expressions on the second operand, so instead of having to write something like this: $className = 'stdClass'; $foo instanceof $className; We could write something like this: $foo instanceof ($bar-getClassName()); I've been working with Nikita Nefedov on this improvement, and we managed to reach a very simple way to implement it, and it looks pretty good so far. Currently, I don't have a VCS account, and eventually I want to open a formal RFC for this, but I first wanted to discuss this with you guys to see the impressions on it and suggestions as well. Regarding BC breaks, there would be none from what I can see so far - hopefully someone more experienced will be able to point my any. So, what do you think? Cheers! Daniel Ribeiro http://danielribeiro.org
[PHP-DEV] Re: Allow arbitrary expressions when using instanceof operator
Oh, and thanks to @SaraMG for pointing me to the write direction on writing an e-mail to the internals :) Daniel Ribeiro http://danielribeiro.org On Thu, Nov 6, 2014 at 11:41 AM, Daniel Ribeiro drgom...@gmail.com wrote: Good morning, internals! I would like to present to you an idea that I have for a syntax improvement for PHP. The basic idea is to allow arbitrary expressions when using the instanceof operator. Currently, the second operand can only be a constant reference or a string: $foo instanceof stdClass; What I want to implement is the ability to allow arbitrary expressions on the second operand, so instead of having to write something like this: $className = 'stdClass'; $foo instanceof $className; We could write something like this: $foo instanceof ($bar-getClassName()); I've been working with Nikita Nefedov on this improvement, and we managed to reach a very simple way to implement it, and it looks pretty good so far. Currently, I don't have a VCS account, and eventually I want to open a formal RFC for this, but I first wanted to discuss this with you guys to see the impressions on it and suggestions as well. Regarding BC breaks, there would be none from what I can see so far - hopefully someone more experienced will be able to point my any. So, what do you think? Cheers! Daniel Ribeiro http://danielribeiro.org
[PHP-DEV] Thoughts on the PHP.net website
Good evening, Internals! *Disclaimer: *I wanted to bring this discussion inside the internals mailing list not only because of the fact that the PHP.net website's source code on GitHub doesn't have issues enabled, but especially because I think it's part of the PHP environment, just like the spec or the actual C code itself. You all know the http://php.net website and it's source code https://github.com/php/web-php. It comes to my attention that this source code is pretty much a very good example of how *not *to build websites in PHP — the source code predates the PHP 3 days, but that's just one of the problems. I'm not go further into the details of the problems we actually have inside that code, as they are very obvious and the source code speaks for itself — of course, if needed, we can discuss this in more detail later. What I wanted to know from you is: would it be interesting if we started a complete rewrite of the website, not only for actually improving it, but also for making it serve as a reference for people to see how the PHP environment has evolved and what are the good practices we use these days for building websites? Cheers! Daniel Ribeiro http://danielribeiro.org
Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL
Nice work man, it looks really good. Daniel Ribeiro http://danielribeiro.org On Tue, Oct 14, 2014 at 3:41 PM, Kévin Dunglas dung...@gmail.com wrote: Hi, I opened a PR making FILTER_VALIDATE_URL more strict and more compliant with standards: https://github.com/php/php-src/pull/826 Can anyone review (and merge) this patch? Thanks! -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
Re: [PHP-DEV] idea: implement a Comparable interface
Its kinda useless feature for PHP. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2013/5/7 Nikita Popov nikita@gmail.com On Tue, May 7, 2013 at 6:17 PM, Thomas Anderson zeln...@gmail.com wrote: It'd be nice if, when doing $objA $objB, that that'd invoke $objA-__compareTo($objB) or something, much like Java's Comparable interface. Do you have examples of what this would be useful for? The two things that come to mind are DateTime (which can do this anyway as it's an internal class) and classes for bignums or something like that (which are probably also better implemented internally). So I'm not sure how much use there is for this. Nikita
Re: [PHP-DEV] idea: implement a Comparable interface
To me, it sounds that those extremely specific cases ask for a extremely specific compareTo(stdClass) method. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2013/5/7 Stas Malyshev smalys...@sugarcrm.com Hi! I wrote https://wiki.php.net/rfc/comparable a couple of years ago — there's a patch there that would probably still apply without too much work to master. About the only difference was that I didn't double underscore the magic method (in line with both Java and PHP interfaces like Countable). Overriding and isn't the biggest issue, even though BC issues with conversions may definitely be a surprise. Bug biggest one is ==, which may have a lot of very non-trivial effects if you make == return equals when other functions (such as searches, hashes, etc.) may treat them as not equal. It is quite a complex thing which is rife with unexpected side effects, so I think it would be better if it were explicit. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DateTime improvement
People tend to desire API changes that go on the same directions they are going. That's nature... Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2012/12/11 Stas Malyshev smalys...@sugarcrm.com Hi! As Nikita says, from an ORM perspective, an object is always immutable (at least with current implementations I know of), and that's because they can simply use the object hashes to identify two different objects. Why for ORM Date is even an object? In most databases, date is a basic value type, and should be accepted by value, not as a complex object. So, it should also be identified as the value - for number 1, you do not need additional identity or hash except it being number 1, same should be for dates. I don't believe (at all) in if you don't need it mutable, don't use modify() oroverride modify(). If the API is there, people will use it. We tried to implement an immutable DateTime in userland, but it doesn't work out well... Why it doesn't work well and why PHP needs to be changed because of it? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improve DateTime Class
I agree with Christian in the sense that the readability gets compromised. But I also think that a custom DateTime class should solve the problem properly, since readability is not a general requirement. My solution for that problem would be to create that extension and have those nice methods on it, but not to modify the core, though. Like Nikita well said, DateTime object is not an object we can simply dive into modifying it without having some really bad side effects. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2012/12/10 Marco Pivetta ocram...@gmail.com It's just a matter of getting used to it IMO. I am not sure if you can simply modify its public properties, but if that's the case, that should handle your problem. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] SplDoublyLinkedList missing insertBefore/After
It would be an awesome feature, indeed. Daniel Ribeiro Gomes Pereira Twitter https://twitter.com/#!/drgomesp | Facebookhttps://www.facebook.com/profile.php?id=10407054469 | LinkedIn http://www.linkedin.com/pub/daniel-ribeiro-gomes/21/414/39 iPhone: +55 (48) 9111-0931 2012/11/29 Levi Morrison morrison.l...@gmail.com On Thu, Nov 29, 2012 at 4:38 AM, Rafael Dohms lis...@rafaeldohms.com.br wrote: I have just noticed that the current SPL inplementation of a DoublyLinkedList does not include methods to insert nodes into the middle of the list (insertBefore, insertAfter). After mentioning it I ran into a few people and other outbursts on the internet of more people who saw this and complained about it. I found a bug from 2009 (https://bugs.php.net/bug.php?id=48358) which mentions the case and has no Core response at all. I ask two questions: 1) Why was this bug never replied to, is there some reason these methods should not be implemented? 2) Is anyone willing to put up a patch for this? I imagine that if you are familiar with C and PHP source this is a quick implementation as its standard logic documented everywhere. I am creating a library in PHP code that includes a linked list with this feature ( https://github.com/morrisonlevi/PHP-Datastructures/blob/master/src/Spl/LinkedList.php ). I'd love for you to use it while you wait for the core to be patched and give me some feedback. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
