Actually, it turns out the segfault and auto-reference bugs were
easier than I thought to fix. I've updated both gists with the new
code, and it looks to be running quite well...
On Thu, Mar 8, 2012 at 9:32 PM, Anthony Ferrara wrote:
> Hey all,
>
> As promised, I've cre
Hey all,
As promised, I've created a POC patch to implement scalar type hints,
the way that zend_parse_parameters handles hinting. First off, here's
the patch:
Directly apply-able without re2c:
https://gist.github.com/2004623
Removing generated files (requires re2c to compile):
https://gist.git
Michael,
Quick question: how would this work with require_once?
Let's say that I have a class Foo defined in a file without a
namespace declaration.
What happens if I require_once with a namespace first (so Foo gets
imported into the namespace), and then require_once later without a
namespace?
Gustavo,
> Not really, that's just a convention that if zpp fails functions return null
> or false immediately (which one is used depends on the extension, current
> weather, etc.). That's because there's a convention that builtin functions
> don't raise exceptions. But nothings stops them from fa
> AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
> solution for scalar type hints would be the unification of the scalar type
> hints with the current implementation of zend_parse_parameters.
Yeah, that's basically what we were discussing. However, there's one
significant
John,
> Thanks...and aw crap. I hate feeling like I shut the door on something.
Not at all. I don't feel bad about this in the least. Yes, I would
have liked to have gotten it in, but I want a good solution before I
want mine. So I'm absolutely willing to withdraw this RFC, as it does
have iss
John,
Thanks a lot for the reply. Comments inline:
> You've been spending a lot of time defending these proposals and trying to
> prove wrong feedback that raises concerns. This is preventing you from
> actually using the feedback to improve the proposals. You are losing out on
> perhaps the
Christian,
On Wed, Mar 7, 2012 at 3:22 AM, Christian Kaps
wrote:
> Hi,
>
> I'm with Stas here.
>
> First let me say that I would like to see type hinting for scalars in PHP.
> As a userland developer it would help me to write clean and more robust
> code. But I think this proposal is only a worka
Stas,
Thanks for the comments!
inline.
On Wed, Mar 7, 2012 at 2:31 AM, Stas Malyshev wrote:
> Hi!
>
https://wiki.php.net/rfc/parameter_type_casting_hints
>
>
> Just took a look on it - the syntax proposed there is quite ugly and rather
> confusing, I really wouldn't like to have such synta
John,
On Tue, Mar 6, 2012 at 9:04 PM, John Crenshaw wrote:
> Disclaimer: The following is direct (maybe brutally so). I'm not trying to
> hurt any feeling or attack, but I'm not pulling punches either. I don't have
> the energy right now to polish this and make it all nice and gentle, so I'm
>
John,
> Sorry, I disagree. This is nowhere close IMO, and silence doesn't denote
> consent in this case. I actually basically stopped participating when it
> became apparent that people were determined to rush head first into creating
> a doomed RFC without any process to ensure that historical
My concern is the total lack of talk on-list about it. It's obviously
not perfect, but there has been little to no talk on-list about it.
That is an indication to me that it's not ready or that it won't get
in if put to a vote...
Thoughts?
Anthony
On Tue, Mar 6, 2012 at 6:10 PM, Simon Schick
w
>> But please don't add another ini setting. Especially one where
>> *logic* can change depending on the setting. I don't want a case
>> where pow(2, 65)-1 will return different answers depending on the ini.
>> That's just asking for problems.
>
> I edited the RFC while you were sending this for
I initially like the concept (arbitrary precision operations).
But please don't add another ini setting. Especially one where
*logic* can change depending on the setting. I don't want a case
where pow(2, 65)-1 will return different answers depending on the ini.
That's just asking for problems.
10:27 AM, Matthew Weier O'Phinney
wrote:
> On 2012-03-02, Anthony Ferrara wrote:
>> Well, there are a few questions about the implementation:
>>
>> 1. *Which* type casting rules should it follow?
>>
>> a. Regular cast rules (like $foo = (int) $foo), where it
azare INEPOLOGLOU
> Ingénieur Logiciel
>
>
> 2012/3/4 Anthony Ferrara
>>
>> Hey all,
>>
>> I've drafted an RFC for the Parameter type casting hint proposal that
>> I posted to before. Attached to the RFC is a patch that's proposed
>> for
> Can you make sure that only scalar or array casts can be done?
>
> I wouldn't want people to put class typehints in there such as
> function foo( (SomeClass) $foo)
That's how it is implemented now. That'll generate a parse error...
--
PHP Internals - PHP Runtime Development Mailing List
To un
>> In sum, I think the rule that if a mathematical operation involves a float,
>> the result should be a float ought to be kept.
>
> Yes, it is a must.
Well, I'm not so sure about that.
If you look at the docs of pow(), it describes the return type as
"base raised to the power of exp. If the resu
Hey all,
I had messaged about these patches before, but with the 5.4 release
process happening I think it slipped through the cracks. I have 3
patches that are ready for inclusion...
https://bugs.php.net/bug.php?id=60813
Adding a new hash_pbkdf2() function to allow for a C level
implementation o
Stas,
On Sat, Mar 3, 2012 at 9:27 PM, Stas Malyshev wrote:
>> https://wiki.php.net/rfc/object_cast_to_types
>
> Some notes:
>
> 1. Use cases for this are unclear. Wrapping scalar types does not seem very
> efficient as conversion is always one-directional - once you do any
> operation your type
Hello all,
I've drafted an RFC and functional-complete patch for disucssion
another alternative to add scalar object casting magic methods.
https://wiki.php.net/rfc/object_cast_to_types
Please review the RFC and attached patch, and start some discussion on
this proposal.
Thanks,
Anthony
--
P
Hey all,
I've drafted an RFC for the Parameter type casting hint proposal that
I posted to before. Attached to the RFC is a patch that's proposed
for inclusion in core for functionality (it doesn't include news
entries, or documentation, or any of the other steps that would be
needed prior to com
unclean cast (casting (int) "foo" in this
context). However, that's not how the current cast handler works, so
that's not what this does.
Any feedback?
Thanks,
Anthony
On Fri, Mar 2, 2012 at 3:15 PM, Adam Jon Richardson wrote:
> On Fri, Mar 2, 2012 at 7:51 AM
I like that. That way there will always be 2 stable maintained
versions, and possibly a third (depending on timing) that's security
only...
Solves the problem quite nicely IMHO...
Anthony
On Fri, Mar 2, 2012 at 10:41 AM, Sebastian Bergmann wrote:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
>>
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
5.3 is 2.5 years old now. Which means depending on the option that's
chosen here, it'll be completely out of support a mere 3.5 to 4.5
years after ini
ould be a parsing error:
>
> function foo((int) & $bar) { } // parsing error
>
> On the contrary, were there no brackets, the resemblance to the syntax of C
> would be confusing.
>
>
>
>
> Lazare INEPOLOGLOU
> Ingénieur Logiciel
>
>
> 2012/3/2 Ant
the intent clear, and
> there's not BC issues with class names.
>
> David
>
> On 02/03/12 14:48, Anthony Ferrara wrote:
>> Hey all,
>>
>> I know given all the discussion about this topic lately, this is a hot
>> topic. But I whipped together a quick POC patch
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_du
Here's one thing to consider. Right now casting/type-autoconversion
is inconsistent at best. Let me show you what I mean:
If I add 1 to a variable, the variable is converted based on the
standard http://us2.php.net/manual/en/language.types.type-juggling.php
type juggling rules, but the variable
Whereas if you implemented just the scalar hint without the aliases,
it wouldn't be a problem at all to add them, since there would be no
BC break at all...
Anthony
On Thu, Mar 1, 2012 at 9:33 AM, Adam Jon Richardson wrote:
> On Thu, Mar 1, 2012 at 8:55 AM, Anthony Ferrara wrote:
>>
Please do not implement int, float, etc as an alias to scalar. That's
going to cause nothing but trouble later on. It will instantly close
the door to any type of casting magic (due to BC concerns), be
completely non-obvious ("I hinted for int, why is it a boolean?"), and
cause nothing but confus
Stas,
Thanks for the comments!
Replies inline:
Thanks,
Anthony
On Wed, Feb 29, 2012 at 2:48 AM, Stas Malyshev wrote:
> Hi!
>
>
>> Hey all,
>>
>> I've created a draft version of the RFC for implementing __castTo()
>> and __assign():
>>
>> https://wiki.php.net/rfc/object_cast_magic
>
>
> I thin
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
It's still a draft, and has a lot more work to do, but I figured this
would be enough to start triggering some discussion (or at least a
little bit more focused
ything but to add noise to the
conversation.
Anthony
On Tue, Feb 28, 2012 at 4:37 PM, Richard Lynch wrote:
> On Mon, February 27, 2012 11:05 pm, Anthony Ferrara wrote:
>> > class Foo {
>> public $value = 1;
>> }
>> class Bar {
>> public $value = 1;
>&
Can I make a suggestion? Instead of an rfc, can we collate the existing
discussion into an easier to digest format (historical as well). Summarize
the conversations and existing rfcs with the discussion around them
(including the pros/cons and problems). That way we have a point of
reference and
ore writing an official
patch and RFC. That's why I made a POC patch, to investigate the
ramifications and prove it could be done before finalizing and
proposing exactly how it should work...
Thanks,
Anthony
On Tue, Feb 28, 2012 at 5:54 AM, jpauli wrote:
> On Tue, Feb 28, 2012 at 6:05 A
= new Foo;
$b = new Bar;
$a->value = 2;
$b->value = 2;
var_dump(substr("test", $a)); // string(1) "t"
var_dump(substr("test", $b)); // string(1) "te"
Anthony
On Mon, Feb 27, 2012 at 3:24 PM, Anthony Ferrara wrote:
> Rich,
>
> I appreciate t
Ferenc,
Thanks for the comments!
On Mon, Feb 27, 2012 at 4:09 PM, Ferenc Kovacs wrote:
>
>
> On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara
> wrote:
>>
>> > no, it is: "come back after you did your homework, and you can provide
>> > new
>>
Rich,
I appreciate the candid and honest nature of your reply, while
maintaining civility. This list needs more of that. Further replies
inline:
On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch wrote:
> On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
>>> I have to say th
> no, it is: "come back after you did your homework, and you can provide new
> arguments to the discussion"
To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=
, and zval_ptr_dtor it as well
(instead of efree, as that way if a reference is stored somewhere it
won't result in a double free, or a segfault for accessing freed
memory)?
Thanks,
Anthony
On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui wrote:
> Sent from my iPad
>
> 在 2012-2-28，0:10，
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
(transparently when
possible).
So what it sounds like you're -1ing to, is not actually what was proposed...
I'm starting to work on a patch for this as a proof of concept...
Anthony
On Mon, Feb 27, 2012 at 10:08 AM, Richard Lynch wrote:
> On Sun, February 26, 2012 9:48 am, Anthon
I fail to see how you would do it via a register function... Unless
you mean a call-chain of callbacks to try to "cast" with a "from" and
a "to" parameter:
spl_autocast_register(function($from, $to) {
if ($to == 'Integer') {
return new Integer((int) $from);
}
});
That could have
ally think it's
solvable in a consistent enough manner that it would work here.
On Sun, Feb 26, 2012 at 11:12 AM, Stefan Neufeind wrote:
> On 02/26/2012 04:48 PM, Anthony Ferrara wrote:
>>> I have to say, it doesn't get work, thinking this:
>>>
>>> $mixed1 = n
let's see an
implementation before we decide, but the concept sounds
interesting/good"...
Anthony
On Sun, Feb 26, 2012 at 10:39 AM, Laruence wrote:
> On Sun, Feb 26, 2012 at 10:57 PM, Anthony Ferrara wrote:
>> I've gone back and re-read a bunch of the old posts on Type H
truct(Integer $i);
>
> Cast To:
> public Integer();
>
> This would require function overloading (__construct overloading by type) but
> with Type Hinting already available for function parameters, this could be
> done relatively easily I think.
>
> Doing this would k
I've gone back and re-read a bunch of the old posts on Type Hinting,
and have come to the conclusion that it won't be done any time soon.
Not because it doesn't have merit, but because there are at least a
few fundamental difficulties that are non-trivial to figure out while
still keeping the usefu
If you're going to go that far, why not make a flyweight enum type?
(Basically what's described here: http://c2.com/cgi/wiki?FlyweightEnum
)...
Right now, it's a hack to get typing in place to let you pass an
integer where a class is defined (the public function foo(MyEnum
$enum) bit). If you use
Hi all,
I've implemented a patch (attached to the bug, but in a gist as well
here https://gist.github.com/1641725 ) that implements a hash_pbkdf2()
function. The patch also slightly refactors hash_hmac() to split out
a little bit of common functionality (since pbkdf2 relies upon hmac).
https://b
Hey all,
I've found what I would call a bug (I submitted it as a feature
request, since that's probably more appropriate) with pow(). If any
one of the arguments is a float, it will cause the result to be a
float. On 32 bit systems this is fine, since all integers can be
exactly specified by the
y PHP. Some argues that it is safe. Btw, it is not faster to run on
> x64 either.
>
> php-next will have x64 support tho'.
>
> Cheers,
>
> On Wed, Jan 18, 2012 at 12:46 AM, Anthony Ferrara wrote:
>> Hello all,
>>
>> I've noticed that on windows.php.net
Hello all,
I've noticed that on windows.php.net that all the builds are x86. I
was wondering if there is any reason (technical or not) not to
distribute x64 builds as well there. It's quite annoying having to
constantly drop to a VM every time I need to test something that's 64
bit dependent...
should use PseudoRandom numbers.
I tried to avoid the Ad Hominem argument (if anything sounded like
that, please forgive me).
I hope that clarifies things from my point of view...
On Wed, Dec 28, 2011 at 4:11 PM, Tom Worster wrote:
> Hi Anthony,
>
> Thanks again for your time responding
Hey all,
I found a superfluous if statement while investigating another issue.
I submitted a bug to clean it up and attached a patch:
https://bugs.php.net/bug.php?id=60596
It's on line 56 of /ext/spl/spl_engine.c :
http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_engine.c#56
It's really simple, an
Stas,
> it's not a solution for the problem it is presented to be - it does> not make
> your code more robust or fail less or saves you effort on> development
I'm going to have to disagree with you there. Type hinting DOES save
me a LOT of effort in development. I can stop worrying about checki
and can under certain circumstances make other
secure applications less secure).
2011/12/21 Tom Worster :
> Hi Anthony,
>
> Thank your for your reply. I inserted some comments below.
>
> On 12/21/11 11:19 AM, "Anthony Ferrara" wrote:
>
>>2. I was unable to do it.
Tom,
First off, very detailed post! However, there are a few things I'd
disagree with.
1. Salts for crypt() purposes need to be cryptographically secure
random numbers.
This is not true. The only requirement is that a salt be reasonably
unique (meaning that the chance of using the same one is
eneral since it creates a
tight coupling to the validator class and is not polymorphic.
I guess my thought is that I would be fine with it as long as it can
accept reasonably arbitrary expressions...
On Fri, Dec 2, 2011 at 11:50 AM, Matthew Weier O'Phinney
wrote:
> On 2011-12-01, Anthony Ferra
To be honest, I'm not a fan of the proposal as written since it can't
accept arbitrary expressions inside the parenthesis. Now, if you
could do any expression inside, then I would +1 for completeness. But
since that's not really possible with the current parser (or language
specification), I'm no
Comments Inline
On Mon, Nov 28, 2011 at 12:57 PM, Matthew Weier O'Phinney
wrote:
> This seems reasonable, but there are some pretty big drawbacks as well:
>
> * Type-hinting -- typically, a decorator should be able to be used
> wherever the object it decorates is used. As such, if you simply
> Excellent thinking. One hitch... that goes fatal in 5.3 if $foo is a string.
> Here's how to write the test so it works the same way under 5.3 and 5.4:
Correct. However, it's worth noting that it only goes fatal if $foo is a string.
So as long as you know that the root variable is an array, it
, 2011 at 5:48 AM, Richard Quadling wrote:
> On 23 November 2011 18:37, Anthony Ferrara wrote:
>> Ralph:
>>
>> From where I'm sitting, I can see a few sane alternatives (there may
>> be more, but here are the options I can see):
>>
>> Option 1. Rem
One thing to note. The good test for what's being talked about would be simple:
isset($foo['bar'][1]['baz']) && is_array($foo['bar'][1])
You don't need to check each level. Only the one above the key you're
looking at.
I think it would be a good idea to raise a notice on string index
conversio
Ralph:
>From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or
Hello all,
I've had an idea that's been burning in my head for a while. Rather
than write an RFC or do any significant work on it, I thought I would
bounce this off of you all first.
Basically, I see a problem with implementing decorators in PHP. To
explain the problem, let's say that I have a
If I'm not mistaken, that is to be expected. That's because you're on
a 32 bit system, so the maximum possible int (PHP_INT_MAX) is
2147483647. Now, normally PHP could cast to a float to get the larger
number in, but you explicitly cast it to an integer, so it had to
truncate the value.
Try var_
Comments Inline
> 1) What we know and have been told is that PHP's signature
> checking is governed by Liskov Substitution Principle. There are
> many references to this in the list.
Except that signature checking is not needed for LSP to function. You
can write all of your code using duck typi
Some responses inline...
> So, since PHP lets you do bad things in the first place (like have
> constructors and static methods in interfaces, and abstract ctors in
> abstract classes), we follow that up with another "bad" of breaking general
> LSP expectations of how things work?
>
> Isn't this t
Honestly, I think __construct should behave like any other method when
specified abstract or via an interface.
I know you're thinking "But it's not an LSP violation in the
constructor". But my assertion to that is that it's a violation of
the contract that the abstract method / interface defined.
> Yes, but even in that case the autoloader would not be triggered to
> load \Foo_Bar because if you already have used \Foo\Bar previously,
> that would have loaded \Foo_Bar as well.
Well, my original point is that what if both are not defined in the
same file. It's not that far fetched of an ide
Guilherme,
Comments inline
> Thanks immensely for your input.
> Without such action, it's extremely hard to improve the RFC. =)
> Awesome action from your side.
> I'll place my comments inline.
Thanks. I didn't really intend for my other comments to get so...
aggressive. I saw the proposal bei
David
Sorry, I just RE read your reply. that's basically what you said, so in
essence I agree...
Anthony
On Nov 10, 2011 6:29 PM, "Anthony Ferrara" wrote:
> Well, the problem with adding methods later is that it will fatal any
> class that implements the old one. A big
Well, the problem with adding methods later is that it will fatal any class
that implements the old one. A big no no.
You could get around that by doing something like traversable. Provide an
empty and non usable core SplAutoloader interface which is typehintable.
Then add a child SplClassAutolo
Ronald,
Very well said. Thanks for the clarification.
Anthony
On Thu, Nov 10, 2011 at 2:49 PM, Ronald Chmara wrote:
> On Thu, Nov 10, 2011 at 8:09 AM, Anthony Ferrara wrote:
>>> However, and it is what we approved, OSS project leads have a voice,
>>> today and here. An
> 2) This isn't a "bunch" of developers, this is a bunch of the largest> used
> PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal),
Ok, I have to say it... You're a group of people who have done great
things. Good for you. Get over it. Stop trying to use that as a
justification or
> However, and it is what we approved, OSS project leads have a voice,
> today and here. And they are not random people, they know sometimes
> much better than us what should be added to the core (be language, or
> functions in an extension like spl).
Well, I would like to make a point here. Righ
Guilherme et al,
Since you asked me for feedback on how I would suggest improving the
RFC, so here it goes...
I think I need to make one thing clear first. I don't think that I
can vote yes for this RFC in principle (I just don't agree this
belongs in core). However, with that said if the RFC w
On Wed, Nov 9, 2011 at 5:16 PM, Rafael Dohms wrote:
> On Wed, Nov 9, 2011 at 2:03 PM, Anthony Ferrara wrote:
>
> You sort of prove my point here, as you actually have your own
> autoloader, which in case you are PSR compliant, you would not need,
> you can still use your bootstra
Rafael
> This makes life as a PHP developer much easier and having the standard>
> "valued" by PHP by having a SplClassLoader that allows any library to> not
> need to implement a autolaoder if no framework is present allows> for much
> nicer "plug and play" interaction of libraries, less work
> I updated the RFC a few hours ago based on a lengthy discussion in>
> php-standards.
Point of order. Discussions on RFCs are supposed to happen on the
internals list. That's the point of an open RFC process, so that the
discussion and justification can be made public for all to see. The
RFCs
t or in example. How can we
vote on a moving target...?
Anthony
On Mon, Nov 7, 2011 at 12:23 PM, Anthony Ferrara wrote:
> Well, with respect to that, are there any examples of where PHP
> currently "reserves the namespace"? I can declare functions/classes
> for every single disa
thony
On Mon, Nov 7, 2011 at 12:09 PM, Lester Caine wrote:
> Anthony Ferrara wrote:
>>
>> Lester,
>>
>> I think he was referring to something like the MySQL/bcmath/etc
>> extension where it ships in core, but is disabled by default (requires
>> a compile-tim
Lester,
I think he was referring to something like the MySQL/bcmath/etc
extension where it ships in core, but is disabled by default (requires
a compile-time option).
I think what you interpreted it as is basically just what PECL is for
and how it works? Considering that it would basically be ju
ere are at least some people who
want it, but agrees that it doesn't belong in its current form (at
least some I've talked to). It's barely even worth pointing out, but
since I'm writing the email anyway...
Just my opinion,
Anthony Ferrara
On Mon, Nov 7, 2011 at 10:35 AM,
lementation standard.
Does this RFC cover how the class loader can be extended in user-land
to alter the behavior (remember, the implementation isn't specified,
so we have have several implementations that differ yet follow the
PSR-0 Standard).
I don't really know what else I can say to
Jonathan,
> The problem with spl_autoload_register() is it isn't clear what the
> autoloading function is supposed to do if the class if not found.
Then that's a documentation problem. If you throw an exception in
yours, sure that's going to cause problems for anyone else. It's 100%
possible (a
for the list. So I put
it in a blog post as it's more of a personal opinion...
http://blog.ircmaxell.com/2011/11/on-psr-0-being-included-in-phps-core.html
Anthony
On Thu, Nov 3, 2011 at 12:07 PM, Paul Dragoonis wrote:
> On Thu, Nov 3, 2011 at 3:19 PM, Anthony Ferrara wrote:
>> Can I
Can I make a point here.
Why the heck are we caring about the performance of the autoloader at
all here? The filesystem operations necessary (at least the stat()
call) will greatly dominate any string function. And considering that
even the biggest framework only has perhaps a few hundred classe
Stefan,
Thanks for the reply. I disagree on a few points that you made
however. See below for my reply.
> Please refer to:
> https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate
>
> "Traits do not provide any provisioning for handling state."
The original RFC was correct in th
Well, I have a few opinions on this that I think are worth sharing:
1. If this change is made, we no longer would have mixins, but would
have regular multiple-inheritance (With all the "issues" associated
with it). Note that I said mixins and not traits. That's because
since these were implement
Hello all,
I purposely tried to stay out of this conversation, but seeing as
there's a lot of information flying around I think I'll give my
$0.02...
As far as the Square-Rectangle example, that is a classic violation of
the LSP. In fact, it's unsolvable using inheritance. For information
as to
So, based on the rfc, does "must return an instance" mean that it can't
throw an exception (ex: if a resource couldn't be opened)?
On Sep 11, 2011 3:26 PM, "Sebastian Bergmann" wrote:
> We (Arne Blankerts, Stefan Priebsch, Benjamin Eberlei, and I) have
> worked on/with code where a factory for str
> always test against the latest and greatest. Otherwise you'll be
> testing against libmysql versions that are not going to see any updates.
I would disagree with that statement. Tests should be run against all
expected versions of the library. So if 5.1.46 is supported, it
should pass the test
> Traits definitely need to be able to support properties, IMO
Well, if traits support properties, they stop being traits and become
mixins. A trait is nothing more than a mixin that does not have a
state (so no properties). I'm not saying that it wouldn't be useful
to contain properties (and he
I was under the impression that traits were not supposed to have
properties at all:
>From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a
e more concrete. Perhaps b<< or something else.
I'll update the RFC to leave the selection of an operator pair up for
discussion.
Thanks,
Anthony
On Sun, Jul 17, 2011 at 8:00 PM, Rasmus Lerdorf wrote:
> On 07/17/2011 04:47 PM, Anthony Ferrara wrote:
>> Hello all,
>>
&
Hello all,
I have added an RFC for the addition of logical bitwise shift
operators. (>>> and <<< proposed).
https://wiki.php.net/rfc/logicalshiftoperator
Feedback welcome,
Thanks
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
> are you kidding, right?
var_dump('Foo' instanceof 'Bar');
//Fatal Error: instanceof expects an object instance, constant given
On Wed, Jun 29, 2011 at 5:05 PM, Martin Scotta wrote:
> On Wed, Jun 29, 2011 at 5:25 PM, Paul Dragoonis wrote:
>
>> On Wed, Jun 29, 2011 at 9:22 PM, David Zülke
>>
Well, we could take python's approach and use a syntax similar to this:
array_filter($source, lambda $x: $x < 5);
array_map($source, lambda $x, $y: $x < $y);
However, I would question the need. Pythonic lambdas cannot contain
anything but expressions. Therefore they cannot have any meaningful
501 - 600 of 616 matches
Mail list logo
