Instead of removing a warning, why not add an additional parameter to the
function that would instruct it to silence warning messages on parse
failure?
On Fri, May 21, 2010 at 11:55 AM, Brian Moon br...@moonspot.net wrote:
+1
Brian.
http://brian.moonspot.net/
On 5/21/10 10:38
The documentation team is about to document a few trunk features, but we're
unsure about scalar type hinting. I see no final proposal (only three old
RFC's) nor recent discussion here. Is the recent scalar type hinting commit
meant to bring discussion to the topic? Or, has this form of scalar
Not sure what happened here, but scalar type hinting was still up for
discussion as there are two conflicting RFCs.
Not sure how come a version of it was committed to trunk, so it
should definitely not be documented at this time.
Zeev
At 17:51 22/05/2010, Philip Olson wrote:
The
All,
As I mentioned numerous times scalar type hinting is a very
controversial feature in my mind and requires some substantial
discussion before we move ahead to implement it.
As such, I think we should revert the patch that was committed to
trunk and move to discuss it first instead.
My (
hi Zeev,
It seems that there was a bit of discussions on IRC about committing
Ilia's implementation. However it is trunk, and trunk is a development
tree. That means its purpose is to develop new PHP features. But it
does not meant that these features will make it in the next releases
or if they
Maybe I view trunk in a different way than others, but I think
committing it turns it into some sort of 'status quo', and now we'd
need a good reason to change it.
I think major developments should be discussed on internals (IRC's
fine, but not enough), and should be discussed before
could you discuss that on internals please?
On Sat, May 22, 2010 at 5:15 PM, Ilia Alshanetsky i...@prohost.org wrote:
Felipe,
The idea behind the more complex logic was to allow people to have
Int/String/etc... class names, which if we make the types reserved keywords
will no longer be
hi,
On Sat, May 22, 2010 at 4:42 PM, Ilia Alshanetsky i...@prohost.org wrote:
Instead of removing a warning, why not add an additional parameter to the
function that would instruct it to silence warning messages on parse
failure?
What are the actual usefulness of these warnings? I see
Zeev,
There was a comprehensive discussion on this functionality a few months back
on the mailing list and the overall consensus was that the functionality
made sense (as was committed) but was to late in the game to be part of the
5.3 branch. So, now that the trunk has been established it went
At 18:49 22/05/2010, Ilia Alshanetsky wrote:
Zeev,
There was a comprehensive discussion on this functionality a few
months back on the mailing list and the overall consensus was that
the functionality made sense (as was committed) but was to late in
the game to be part of the 5.3 branch. So,
FYI - I did some fairly major editing on the issues with strict type
hinting and advantages of auto-converting type hinting in the RFC
(beforehand I focused primarily on the conversion table).
I encourage everyone to take another look at this RFC even if you've
read it before.
Thanks,
Zeev
Zeev,
First of all as far as I can tell majority of the changes relate to 2 new
type hints you are suggesting to introduce which are numeric and scalar. I
don't see any issue with adding those two hints, predominantly for people
who don't want to be specific with their type requirements. So, +1
At 19:30 22/05/2010, Josh Davis wrote:
On 22 May 2010 17:04, Zeev Suraski z...@zend.com wrote:
As one of the key people who designed PHP's type system I consider strict
type checks completely alien to and counterintuitive in PHP and
am therefore
pushing to implement 'weak' typing instead,
At 19:25 22/05/2010, Ilia Alshanetsky wrote:
Zeev,
First of all as far as I can tell majority of the changes relate to
2 new type hints you are suggesting to introduce which are numeric
and scalar. I don't see any issue with adding those two hints,
predominantly for people who don't want to
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the _type hinting system_. As far as I know, there's no
weak type hinting; if a method signature hints
So which RFC should I be reviewing? Does this RFC reflect what Ilia's
patch does? I just want to be sure we are talking about the same thing
and can review and comment on it in detail. We've had many discussions
on this topic over the years and different people had different things
in mind so we
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However, the
topic here is the _type hinting system_.
On 23.05.2010, at 00:01, Hannes Magnusson wrote:
can we please just stop calling a something a type hinting system, which
leads to a catchable fatal error when the type does not strictly match?
thats a very misleading euphemism. its simply strict typing, it has nothing
to do with hinting.
Andi,
The existing functionality is very simple (no RFC) needed. It allows for
scalar type hints and ensures that the Z_TYPE of the parameter matches the
indicated type in the declaration, any mistmatch results in an error.
On Sat, May 22, 2010 at 5:46 PM, Andi Gutmans a...@zend.com wrote:
So
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
really cool, juggles strings with ints and what not. However,
On Saturday 22 May 2010 11:43:50 pm Zeev Suraski wrote:
At 01:01 23/05/2010, Hannes Magnusson wrote:
On Sat, May 22, 2010 at 22:39, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
On 22.05.2010, at 18:30, Josh Davis wrote:
As you wrote, you worked on PHP's _type system_ which is dynamic,
21 matches
Mail list logo
