> Dear all,
>>
> I'm asking your help because I'm not able to solve an
> issue
>>> probably
related to some foolish mistake I have not yet discovered.
> I'm trying to develop an experimental extension to
> interface LIXA
library (http:/lixa.sourceforge.net/).
hi Bill,
On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
wrote:
> On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
>> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>>> disabled during 'configure'
>>
>> Why punish everyo
On Wed, 29 Feb 2012 08:48:07 +0100, 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 think having cast method may have merits, though use cases where
objects need to be co
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
> test(1, 2); // 2;
> test("1", 2); // 2
> test("1aaa", 2); // E_NOTICE or E_TYPE and result 2
> test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type
hint now.
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick
> Hi, John
>
> I personally do not care about weak or s
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_
Hi!
I can think of a few: bridges to foreign types (e.g. Java objects),
SimpleXML like libraries and bigint objects, for instance. The RFC has
more examples.
This all can be (and is) done with engine-level hooks. As I noted in my
previous mail, most RFC examples are either exotic (like limite
On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joye wrote:
> hi Bill,
>
> On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
> wrote:
> > On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
> >> On 02/28/2012 02:44 PM, Christopher Jones wrote:
> >>> Build PHP with ZTS enabled by default. Allow it to be
> > Dear all,
>
>>>
> > I'm asking your help because I'm not able to
> solve an
>> issue
probably
> related to some foolish mistake I have not yet discovered.
> > I'm trying to develop an experimental extension to
>> interface LIXA
> library (http:/
On Wed, Feb 29, 2012 at 10:47 AM, Christian Ferrari wrote:
> >> Dear all,
>
> >
> >>>
> >> I'm asking your help because I'm not able to
> > solve an
> >> issue
> probably
> >related to some foolish mistake I have not yet discovered.
> >> I'm trying to develo
Hi, Arvids
I did not meant to putt all in one big RFC but more to think about the
connection between these two while developing.
Bye
Simon
2012/2/29 Arvids Godjuks
> Combining different things into one big RFC is not a good idea. It's
> hard to develop and test the work it it's in one big chun
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
Hello Antony,
You did a nice work for the RFC.
However, I have to disagree with the name __assign, because it limits the
type casting operation only to assignments. An implicit type casting could
very well happen upon calling a function with type hints.
Therefore, I would suggest the use of som
> int $a = "1"; // no error. 1 == "1" so who cares?
> int $a = 'House'; // error 0 != 'House', so this is a problem.
For the sake of consistency, please take into account this example, which
works in the current implementation of PHP:
$b = 1 + "1"; // no error, $b == 2
$b = 1 + "House"; // n
I agree with Simon on this:
On Wed, Feb 29, 2012 at 08:58, Simon Schick wrote:
> I'd like to split this discussion in parts:
>
> - just type-hint in functions (as we have it with classes and arrays) or
> bind a variable to a strict type?
> - should it then also be possible bind variables
On Tue, February 28, 2012 8:40 pm, Anthony Ferrara wrote:
> https://wiki.php.net/rfc/object_cast_magic
Suggestion:
Rename __castTo as __castObject, to be parallel to engine
Question:
Is there no need to implement the get() function in userland?
It "feels" wrong for 1/3 to be missing, but I probab
Hi!
However, assignment overloading does not seem viable to me.
Also, I'm not sure how this is possible technically: $obj = {expression} is
supposed to replace $obj with the result of the expression, not call methods
on $obj.
The engine already calls methods on $obj when that happens. That's
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote:
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i
Hi, all
I just read this post about a vulnerability by loading doctype-declaration
of an xml-string given in a request:
http://www.idontplaydarts.com/2011/02/scanning-the-internal-network-using-simplexml/
Would it be a good point to restrict which urls can be loaded in the
doctype, or is the foll
I agree with the notion of typing in function arguments, though I'm not a
fan of this particular approach. Specifically, I don't like the idea of
"1aaa" throwing one kind of error (E_NOTICE) and array($whatever) throwing
another kind of error. They should both throw the same error because
they're
@Richard I think you made a very good point. Should we treat a float =>
int mismatch the same as we would a string => int mismatch, or should the
former fail more gracefully? I can see good arguments for both.
--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch wrote:
> On Tue, February 2
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way into
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think w
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes ye
On Wed, 29 Feb 2012 19:30:15 +0100, Simon Schick
wrote:
I just read this post about a vulnerability by loading
doctype-declaration
of an xml-string given in a request:
http://www.idontplaydarts.com/2011/02/scanning-the-internal-network-using-simplexml/
Would it be a good point to restrict
Hi, Kris
As we have some RFCs around that we should update them I think.
In my opinion we should split them up into 3 RFCs (and one grouping RFC):
Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close to
>> > > Dear all,
>>
>> >
>> >>>
>> > > I'm asking your help because I'm not
> able to
>> > solve an
>> >> issue
>> probably
>> > related to some foolish mistake I have not yet
> discovered.
>> > > I'm trying to develop an experimental
> extension to
Guys,
I've followed this thread silently so far, and I'm wondering what changed over
the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict
typing has no place in PHP. Rasmus said about the proposal bac
Aand here we go again. Every few days it seems, somebody jumps
into this thread and reminds us that strict typing is a bad idea, despite
the fact that we've already all agreed on that point about a gazillion
times.
As for past RFC's, I would recommend you review the voting procedure. If
Personally, while I see the value in recycling what's already there, I
think that would just make things WAY more confusing than they need to be.
Some of these RFC's are years old and appear to have since been abandoned.
I think it would be better to have a procedure for removing "dead" RFC's
after
Kris,
If we've agreed that strict typing is bad, why is it even showing on the
discussion here? Calling it 'firm' or 'strong' doesn't make a difference. If
it errors out or throws an exception (which BTW is out of the question for a
language feature), it's strict typing, regardless of naming.
Kris Craig wrote:
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I have to complain about that. There is nothing wrong in my book
Guys, you probably are too deep into the discussion that you haven't
noticed an elephant Zeev has put into the room. When the RFC procces was
put in place there was a rule outlined - if core devs decide to reject,
it's rejected. And as Zeev said last time core dev team decided that there
will be no
Responses inline.
--Kris
On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski wrote:
> Kris,
>
> ** **
>
> If we’ve agreed that strict typing is bad, why is it even showing on the
> discussion here? Calling it ‘firm’ or ‘strong’ doesn’t make a difference.
> If it errors out or throws an excepti
Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
a
Kris,
Responses aren't inline. I'll go back to the mode that most other core devs
are employing right now and ignore it for the waste of time that it is. I
won't ignore it if it ever comes to a vote, nor will the others.
Troll away.
Zeev
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent:
I would challenge the preconceived notion that it's likely to be rejected.
It winds up being a form of circular logic. For example, you argued that
previous tries failed to be approved because nobody wanted to do the work.
But then you said that nobody wants to do the work because it has failed to
In other words: "I'm not gonna respond to your arguments because you're a
troll. None of us smart people agree with you. Nyah nyah nyah I can't
hear you nyah nyah nyah!"
My response: *sticks tongue out* So there. ;P
Now that that's settled, where were we?
Ok, looks like we left of
Please.read my emails carefuly. What i said is last time the work has been
done, and two different patches have been developed and iterated. But
dificulties in implementation and strong resistance from the devs and
comunity got it killed. I actually had a post on our biggest russian
speaking IT res
I agree. I'm against strict type hinting as well. Of course, nobody here
is suggesting that we should go with strict typing, so it's a moot question
anyway.
--Kris
On Wed, Feb 29, 2012 at 2:35 PM, Arvids Godjuks wrote:
> Please.read my emails carefuly. What i said is last time the work has be
On Wed, Feb 29, 2012 at 4:49 PM, Zeev Suraski wrote:
> Kris,
>
> If we've agreed that strict typing is bad, why is it even showing on the
> discussion here? Calling it 'firm' or 'strong' doesn't make a difference.
> If it errors out or throws an exception (which BTW is out of the question
> for
Zeev Suraski wrote:
> I'll go back to the mode that most other
> core devs are employing right now and ignore it for the waste of time
> that it is. I won't ignore it if it ever comes to a vote, nor will
> the others.
Quite right. Even though I'd like some form of typehints it makes no sense to
I once pushed this hard for namespaces. Then, after years of it being shot
down, they did it.
And now I'm sad. It didn't occur to me until after it had been implemented how
bad an idea it was for php. I think this is one of those times.
Type hinting is wonderful, but i'm not sure you could rea
If you think it's a good idea, then why vote against it? Seems kinda
strange to me.
This issue isn't going to go away. If you really want it to stop coming up
every 6 months because people are *constantly* requesting it, maybe we
should find a way to implement something that would appease this c
With all due respect, it's a logical fallacy to draw a direct comparison
between these two simply because they both happen to be uphill battles.
We've demonstrated in this discussion that it can, in fact, be done without
breaking the PHP concept at all. The only consistent argument I'm hearing
ag
I'm a bit like Matt in that I might see something useful in this, but
worry that it just might not really work as initially intended.
Zeev actually gave a pretty explanatory reply (albeit a bit hostile
and condescending, come on dude!) as to why it doesn't fit into the
language paradigm.
Made me
I respectfully disagree. We've already covered this actually. The same
argument could have been (and probably was) made that stricter adherence to
OO standards in PHP 5 would break the PHP paradigm. Instead, it made PHP
considerably better and opened it up to a much wider audience. People are
s
Hi, All
Sorry for pulling the old RFCs out. But why is their status is still *in
draft* or something like that? I did not know something about the
6-month-rule.
That's also what I mentioned before with the missing solution ... If you
close an RFC or set it to *accepted*, please also write what has
@Simon Well said! For some reason, the issue of typing in the PHP and
other programming communities brings out a lot of emotion in people. Given
some of the heated rhetoric we've seen, you'd think we were debating
whether Roe v. Wade should be overturned lol.
I think it is important that we try
Hi, all
What's next?
I think the next step would be to write down a good Introduction,
Requirement, Solution and Examples.
As we had some discussions and ideas around here I think we came to a
proper place where we could write the first draft and discuss it after
writing it down in one place.
I
As much as I would love to have __castTo() and __assign() I have to agree with
Stas here that it fundamentally changes the mechanics of if($object) and
unfortunately turns that simple if statement into a possible hour long hunt to
find the code that is doing the damage, if it is even considered
@Simon If it's ok with you, I would like to set this aside briefly and
divert our attention toward the RFC voting thing, primarily because I think
that will make the drafting process much easier and less confusing when
we're ready to start working on the typing RFC initial draft. Any
objections?
> If it errors out or throws an exception, it's strict typing, regardless of
> naming.
Actually, for purposes of this discussion, "strict" is defined. It means "PHP
complains about (function(int $n){})('1'), even though it could have easily
converted it." The majority of arguments in the past,
> Hi, all
>
> What's next?
>
> I think the next step would be to write down a good Introduction,
> Requirement, Solution and Examples.
>
> As we had some discussions and ideas around here I think we came to a
> proper place where we could write the first draft and discuss it after
> writing it d
> -Original Message-
> From: Kris Craig [mailto:kris.cr...@gmail.com]
>
> @Richard I think you made a very good point. Should we treat a float => int
> mismatch the same as we would a string => int mismatch, or should the former
> fail more gracefully? I can see good arguments for both
I was thinking something more along the lines of simply throwing an error
if, say, (int) $a != $a *if *$a is defined as an integer.
--Kris
On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw wrote:
> > -Original Message-
> > From: Kris Craig [mailto:kris.cr...@gmail.com]
> >
> > @Richard
On Wed, Feb 29, 2012 at 8:46 PM, Kris Craig wrote:
> I was thinking something more along the lines of simply throwing an error
> if, say, (int) $a != $a *if *$a is defined as an integer.
>
> --Kris
>
>
> On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw >wrote:
>
> > > -Original Message
PHP currently allows users to provide type hints for functions and methods,
although the type hints are currently limited to objects and arrays:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
Restricting the type hinting to arrays and objects makes sense, as PHP's
type j
On Wed, February 29, 2012 6:55 pm, Kris Craig wrote:
> If not, I'll go ahead and draft an RFC for these proposed amendments
> sometime today or tomorrow when I get a spare moment. If anyone has
> any
> thoughts on this, please share them! Thanks!
This is not an official answer. I don't have time
On 02/29/2012 09:01 PM, Adam Jon Richardson wrote:
However, the aliases would allow developers to better communicate
intentions AND provide more information for IDE's and static analyses
tools.
1) You are trying to solve a social problem through technology. That
usually does not work.
2)
@Richard Yeah that sounds about right actually. That's probably exactly
the reasoning behind the current model being what it is.
However, it seems to me that, especially in complex proposals, the "should
we?" and the "how?" distinction becomes more and more difficult to avoid.
If everyone support
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
> I'm beginning to think that the type hinting question is too closely
> related to the dirty secrets of type juggling to resolve them
> separately. You may have to either discard consistency, or else fix
> the problem of silent bizarre conver
Bah and after all that, I went and misspelled *Symantec. *grumbles*
--Kris
On Wed, Feb 29, 2012 at 7:01 PM, Kris Craig wrote:
> @Richard Yeah that sounds about right actually. That's probably exactly
> the reasoning behind the current model being what it is.
>
> However, it seems to me that,
I agree with your well-thought-out remarks overall. However (and you knew
a "however" was coming lol), by making these types optional, we would be
allowing full backwards-compatibility without alienating non-CS developers,
since they would be able to continue writing the same code they do now.
Li
First, phpunit is a fantastic tool! I'm thankful for your contributions to
all of the PHP community (especially with the code coverage capabilities.)
I speak to your 2 points inline below:
On Wed, Feb 29, 2012 at 9:36 PM, Sebastian Bergmann wrote:
> On 02/29/2012 09:01 PM, Adam Jon Richardson wr
66 matches
Mail list logo
