Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.
Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.
Bye
Simon
2012/3/2 Simon Schick <[email protected]>
> Hi, Kris
>
> I have to confirm that that's not really what I wanted.
> But many people were now talking about type-hint to scalar, but that was
> maybe in another thread in this list :)
>
> To get more to the point what were discussing about want:
> Why not always (at least try) to transform the data?
>
> In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
> * Changed silent conversion of array to string to produce a notice.
> * Changed silent casting of null/''/false into an Object when adding a
> property into a warning.
>
> I would suppose to add a type-hint for the following types:
> * Boolean
> * integer
> * float
> * string
>
> Here's the last state what I thought about these type-hints ...
> Both of the given examples here should give the same result:
>
> foo(boolean $b, integer $i, float $f, string $s) {
> // your code
> }
> foo2($b, $i, $f, $s) {
> $b = (boolean)$b;
> $i = (integer)$i;
> $f = (float)$f;
> $s = (string)$s;
>
> // your code
> }
>
> If you view it from that site - you can't get an array to do what you can
> do with an object. Therefore I think it's quite OK to break the script
> there, but here, as you can transform the values, I'd (at least try to)
> transform the given data into the expected format.
> The only thing I'm quite unsure about - should we trigger a E_WARNING or
> E_NOTICE if we have data-loose in this transformation? Just let it pass as
> it's transformable, but trigger some error ...
> If you want to get a warning or notice in the function *foo2* then open a
> new thread, as I think that should not be discussed here. It affects much
> more than just the function-call.
>
> p.s. What about adding another type-hint for resources?
> That's something we could check by *is_resource()* and it would make
> sense (at least to me).
>
> Bye
> Simon
>
>
> 2012/3/2 Kris Craig <[email protected]>
>
>> I agree with what John said. Limiting the scope to scalars, while having
>> some advantages, probably wouldn't pass the "usefulness" test for most
>> people.
>>
>> --Kris
>>
>>
>> On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw <[email protected]
>> >wrote:
>>
>> > From: Richard Lynch [mailto:[email protected]]
>> > > On Thu, March 1, 2012 2:38 am, John Crenshaw wrote:
>> > > >> You might consider those scripts poor programming practice. We all
>> > > >> do.
>> > > >> But PHP is the language of the unwashed masses, and that was, and
>> is,
>> > > >> part of why it is hugely popular. Somebody who barely understands
>> > > >> programming can pound away at the keyboard and write a bloody
>> useful
>> > > >> web application, breaking 10,000 Computer Science rules along the
>> > > >> way.
>> > > >
>> > > > And in 20 minutes I can hack into that application 20 different
>> ways.
>> > > > This isn't really PHP's fault...or is it? By deliberately catering
>> to
>> > > > the lowest possible denominator is it possible that PHP itself
>> > > > contributes to the proliferation of wildly insecure web sites? I do
>> > > > understand the "unwashed masses" argument, and yet, the security
>> geek
>> > > > in me sometimes questions how "good" this is.
>> > > >
>> > > > (Before someone flames me, I'm not really saying that we should
>> scrap
>> > > > any foundational principles or tell basic users to go hang
>> themselves.
>> > > > This is mostly philosophical musing.)
>> > >
>> > > We make concerted efforts to educate scripters, by posting the same
>> > thing in all our blogs.
>> > >
>> > > Even if all they understand is "Don't do this!" it's good
>> > > enough for
>> > most of them.
>> > >
>> > > Other times the decision was made to just deprecate a "feature" and
>> > provide a migration path,
>> > > if suitable, but spread out over major
>> > > releases:
>> > > PHP x.0: Feature is bad, but there
>> > > PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
>> > [This is the bit
>> > > where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
>> is
>> > just gone.
>> > >
>> > > People who completely ignore docs or don't upgrade remain vulnerable,
>> > but there's not much
>> > > you can do without making life miserable for a bazillion developers.
>> >
>> > No, you've misunderstood. The average new not-really-a-developer has no
>> > concept of security. Every SQL query they write is vulnerable to
>> injection.
>> > Every echo exposes their site to XSS vulnerabilities. Every form is
>> > vulnerable to CSRF. If they did anything with files in their script I
>> may
>> > be able to read arbitrary files to their server and/or upload and
>> execute
>> > arbitrary scripts. If they used eval() or system() I can probably
>> execute
>> > arbitrary shell code and take control of the entire site. If their
>> server
>> > is badly configured I could capture the entire machine.
>> >
>> > This isn't a question of keeping software updated and not using
>> deprecated
>> > functions, this is a question of discipline that is completely missing
>> > among the "unwashed masses" as you call them. The intuitive way to
>> handle
>> > many of the most common PHP tasks is also the completely insecure way.
>> > Philosophically, I wonder if we do a great disservice by encouraging
>> these
>> > people to tinker with code at all. We do so knowing (or at least we
>> should
>> > know) that anything they create will inevitably be hacked. We fuel the
>> > widespread security problems that currently plague the web.
>> >
>> > John Crenshaw
>> > Priacta, Inc.
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>>
>
>