Hey Anthony,
thanks for your work and I think it’s a very good idea. I thought very much of
it during the last days and I start to see its merits. So, good thing. I would
prefer ~Type for syntax over Type though, but that's just a minor detail.
cu,
Lars
Am 25.06.2013 um 17:57 schrieb Anthony
Hi Anthony,
I really like the idea. But I'd prefer the following syntax:
public function __construct(~HttpKernelInterfaceForClientIp $parent) {
$this-parent = $parent;
}
Reasons:
* A passed object does not have to explicitly implement the interface, but
only implicitly
Stas et al,
So, the question of what is the difference between the two errors
remains unanswered. If the whole diff is that one of the errors has word
recoverable in the message, it's not substantial difference at all and
one that does not require new syntax and big change in the language.
On Thu, Jun 27, 2013 at 10:35 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Stas et al,
So, the question of what is the difference between the two errors
remains unanswered. If the whole diff is that one of the errors has word
recoverable in the message, it's not substantial difference at
I agree the use-cases are slightly weak. This is a draft RFC. It's supposed to
help identify
the areas where we can improve it. Help identify use-cases. Help dig it out.
I think Ralph has the right idea:
register_compatible_types($yourType, $myType);
A better name might be (only for
On Thu, Jun 27, 2013 at 10:54 PM, Laruence larue...@php.net wrote:
On Thu, Jun 27, 2013 at 10:35 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Stas et al,
So, the question of what is the difference between the two errors
remains unanswered. If the whole diff is that one of the errors has
Laruence,
I missed one thing here, it should be:
why we need such feature that only a few people need it, and will
also make reset people confused, and most of other language doesn't
have it, and using it will make things a little mess(and low
performance vs pure interface)?
I've proven
wow... why did this just become a measuring contest. Do we need to go
recruit people interested and attach their resume's?
I'll just toss in I am interested in this. Comparing to current methods of
doing this sort of things(because if you're denying it exists in the wild,
lets open up some of
2013/6/27 Anthony Ferrara ircmax...@gmail.com
Stas et al,
So, the question of what is the difference between the two errors
remains unanswered. If the whole diff is that one of the errors has word
recoverable in the message, it's not substantial difference at all and
one that does not
On Thu, Jun 27, 2013 at 11:25 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
I missed one thing here, it should be:
why we need such feature that only a few people need it, and will
also make reset people confused, and most of other language doesn't
have it, and using it will
On Wed, Jun 26, 2013 at 5:02 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Florin
Could you please point out what happened in the past 5 months in PHP
that changed the landscape so drastically as you say? And don't
mention folks reinventing the wheel in OOP because that's not news :)
The
Laruence,
so are you saying, that check every method's signature of a class is
*faster* than just check interface?
Yes, yes I am saying that. And yes, the numbers show that.
Think about it for a second. When you implement an interface, at compile
time the compiler must loop through and check
On Thu, Jun 27, 2013 at 10:50 AM, Florin Patan florinpa...@gmail.comwrote:
On Wed, Jun 26, 2013 at 5:02 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Florin
Could you please point out what happened in the past 5 months in PHP
that changed the landscape so drastically as you say? And
On Thu, Jun 27, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
so are you saying, that check every method's signature of a class is
*faster* than just check interface?
Yes, yes I am saying that. And yes, the numbers show that.
Think about it for a second. When you
On Fri, Jun 28, 2013 at 12:20 AM, Laruence larue...@php.net wrote:
On Thu, Jun 27, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
so are you saying, that check every method's signature of a class is
*faster* than just check interface?
Yes, yes I am saying that. And
...
group of people are mostly solved already). The average framework core-dev
(like Symfony or ZF) isn't going to get *much* benefit out of this either
(it can help in some areas, and they will use it, but it's not solving
major problems). The Drupals, Magentos and Fuel CMS's of the world. The
On Fri, Jun 28, 2013 at 12:30 AM, Laruence larue...@php.net wrote:
On Fri, Jun 28, 2013 at 12:20 AM, Laruence larue...@php.net wrote:
On Thu, Jun 27, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
Laruence,
so are you saying, that check every method's signature of a class is
Laruence,
previous test script only measure the last all, although that,
interface already won with complex arguments signatures...
here is a fixed one: https://gist.github.com/laruence/5877928
run 3 times:
$ sapi/cli/php /tmp/2.php
Interface in 1.7314801216125 seconds,
On Thu, Jun 27, 2013 at 6:38 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
...
group of people are mostly solved already). The average framework core-dev
(like Symfony or ZF) isn't going to get *much* benefit out of this either
(it can help in some areas, and they will use it, but it's
Hi!
I'm assuming that you do know the difference between
E_RECOVERABLE_ERROR and E_ERROR. And the difference is not trivial...
Could you please explain what is the non-trivial difference relevant to
this case and how it is relevant? Could you also explain why making
undefined function produce
Stas,
On Thu, Jun 27, 2013 at 1:18 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
I'm assuming that you do know the difference between
E_RECOVERABLE_ERROR and E_ERROR. And the difference is not trivial...
Could you please explain what is the non-trivial difference relevant to
this
Hi!
No, my point was that you pulled the card those languages don't have
these structural typing thigns. And I showed one reason they don't.
Sorry, it was you who pulled the card of other dynamic languages have
duck typing. I have showed that what other dynamic languages have and
what they
Hi,
On Wed, 26 Jun 2013 02:57:46 +0400, Stas Malyshev smalys...@sugarcrm.com
wrote:
That means all you really need is to call method named get, regardless
of what it actually does. Usually the code doesn't work this way - you
expect something to actually happen if you call get(), something
Hi,
As I see it, adapters not only serve declaration purpose, they also can
adapt the method and param names and even alter or tune the execution flow.
Imagine this simple case:
You have a protocol Duck with method walk() with few concrete
implementations. Later you have another instance of
Stas and all,
But instead a fatal protocol does not match error will be thrown. The
difference?
A recoverable protocol does not match error. And the difference is that the
check is pushed to the caller as opposed to within the function.
It gives the ability for a method to be defensive by
On Wed, Jun 26, 2013 at 4:28 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Stas and all,
But instead a fatal protocol does not match error will be thrown. The
difference?
A recoverable protocol does not match error. And the difference is that the
check is pushed to the caller as opposed
Florin
Could you please point out what happened in the past 5 months in PHP
that changed the landscape so drastically as you say? And don't
mention folks reinventing the wheel in OOP because that's not news :)
The point was that best practice is volatile and temporal, and changes
depending on
Robert,
On Wed, Jun 26, 2013 at 10:52 AM, Robert Stoll rst...@tutteli.ch wrote:
I had a quick look at GO and as far as I understand they do not use duck
typing but a structural type system.
http://golang.org/doc/faq#implements_interface
Please change this in your RFC to avoid
All,
I've updated the RFC, renaming Protocol Type Hinting to Structural Type
Hinting (keeping the name of the file for historical reasons).
I've also expanded out the use-cases with a dedicated section and two
examples (middlewares and third-party specified standard interfaces)...
Thoughts?
Hi!
I think we should. And I think we should turn all non-engine related
fatals into exceptions. But both are beyond the scope of this proposal...
So, the question of what is the difference between the two errors
remains unanswered. If the whole diff is that one of the errors has word
On Tue, 25 Jun 2013 19:57:15 +0400, Anthony Ferrara ircmax...@gmail.com
wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more complete (and
Nikita,
Thanks for the response!
By looking at the diff I see it will only work for type-hints in
functions/methods. Could we also see something like $var instanceof
ProtoInterface? I fear it can't be done this way because of parser
limitations, but I believe this feature would be as useful
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more complete (and
On 25 June 2013 18:32, Laruence larue...@php.net wrote:
On Tue, Jun 25, 2013 at 11:57 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hey all,
https://wiki.php.net/rfc/protocol_type_hinting
What do you think?
Hey:
Just one question, usage? why we need this? (run-time check is
slow and
Anthony,
I like it. The one thing that is lacking in the PHP ecosystem is some
kind of support for a Gentleman's Agreement when it comes to APIs. I
am very much opposed to central bodies of code and/or shared interfaces
(like the PSR-3's et. al.) for seemingly simple and cross-cutting APIs.
On 6/25/13 10:57 AM, Anthony Ferrara wrote:
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/**protocol_type_hintinghttps://wiki.php.net/rfc/protocol_type_hinting
There are still open questions, and a more
Hi!
Hey all,
I want to throw out this draft RFC to get the concept floating around and
get feedback early.
https://wiki.php.net/rfc/protocol_type_hinting
I'm not sure I understand why it is good to have this. This way of
checking interfaces is very expensive (since you need to scan the
Laruence,
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
In practice, the run-time check shouldn't be that slow. In fact, I just did
a quick micro-benchark without actually implementing caching, and it's
Stas,
I'm not sure I understand why it is good to have this. This way of
checking interfaces is very expensive (since you need to scan the
function table) and relies on function names instead of explicit
programmer's intent to validate the API (i.e. it assumes if two classes
have method
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend component in
an Symfony app while still using caching today, you'd need to shim
On Wed, Jun 26, 2013 at 1:16 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a Zend
Hi!
See my reply to Laruence, it's not more expensive...
I don't see how you can see it's not - it does method matching on every
call. It just doesn't make sense that doing something N times is faster
than doing something 1 time. That may be true only if you load classes
you don't ever need (no
Stas,
On Tue, Jun 25, 2013 at 6:16 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
This may sound trivial, but imagine this. Right now Zend and Symfony have
very similar providers for certain tasks. One of the ones that comes to
mind (besides logging) is caching. If you want to use a
Hi,
On Tue, Jun 25, 2013 at 11:54 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Laruence,
Hey:
Just one question, usage? why we need this? (run-time check is
slow and I can not think out of a case then we must need it)
1. Library implementers don't need to declare a dependency for a
Hi!
Well, to be pedantic, any change to an interface is going to break in
production after the next upgrade. No matter what you're doing. Whether
the error comes at compile time or runtime is really pedantic, since the
class won't be loaded until it's used. So you may not hit it at compile
Stas,
I don't see how you can see it's not - it does method matching on every
call. It just doesn't make sense that doing something N times is faster
than doing something 1 time. That may be true only if you load classes
you don't ever need (no autoloader? why?) - but even in this case your
46 matches
Mail list logo
