@Lester Well there's another logical fallacy. How, exactly, am I trying to "force" this on anyone? Last time I checked, the PHP community has a voting process that requires a 2/3 majority for anything touching the code. Also, last time I checked, there are numerous people who do want this, so I would definitely dispute some of the claims that this is "dead in the water" so-to-speak.
This has nothing whatsoever to do with implementing namespaces. That's a non-sequitur. Drawing a comparison because they both happen to be controversial ideas would be like me comparing you to Joseph Stalin because you both happen to breathe oxygen. The fact alone that something is controversial does not automatically mean it's a bad idea. Likewise, the fact that namespaces turned out to have unanticipated results does not mean that the same will happen with this. --Kris On Thu, Mar 1, 2012 at 10:06 AM, Anthony Ferrara <ircmax...@gmail.com>wrote: > 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 is attempted to be converted to > a numeric type if it is not already one (based on the string > conversion to numbers rules: > > http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion > )... I will refer to this as "Numeric Type Juggling" as we go on. > Note that objects cannot be used in this manner today, as they do not > implement the get() object handler, so they are converted to int(1) in > this context (which is defined as undefined by documentation). Also > note, that the string is cast to a number destructively. So if you do > 1 + "foo", you'll get 1 back without error or warning. > > If I use a variable in a string context, the type juggling rules still > apply, but this time converting to a string if it is not already one. > This I think is the most straight forward (and sanest) of all the type > rules. I will refer to this as "String Type Juggling" as we go > forward. Note that object can be used in this context now, based on > the __toString method. > > If I use a variable in a boolean context, the type juggling rules > still apply. So I can do if (array()), and the array will be > internally cast to a boolean to be evaluated. Let's call this > "Boolean Type Juggling"... > > If I cast a variable to an array, it follows a standard conversion > policy which is documented here: > > http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting > I'll call this "Array Type Juggling"... > > If I pass a variable to an internal function that expects a string > type, the "String Type Juggling" rules apply. > > If I pass a variable to an internal function that expects a class, it > will convert the variable to a string, and then lookup the class to > see if it's valid. This is the same as String Type Juggling... > > If I cast a variable to an object, it follows the documented casting > rules. Let's call this "Object Type Juggling". > > If I pass a variable to an external function that expects a class, > let's call this "Object Hinted Type Juggling"... > > If I pass a variable to an internal function that expects a callback, > it will try to see if it's a valid callback by running logic if it's a > String, Array or Object. Other types are ignored and error out. > Let's call this "Callback > That's where the sanity ends... > > If I pass a variable to an internal function that expects an integer > or float, some weird things happen. If the argument is a float, it's > cast to an integer. If it's an integer, null, or boolean, it's > converted directly to an integer. But if it's an array, object or > resource, it causes an error. Up to now, it seems sane and right > inline with "Numeric Type Juggling". Except that strings behave > differently. If the string is numeric (passes the is_numeric() test), > then the string will be cast to an integer and proceed as expected. > But if it is not, a warning is thrown and the internal function errors > out. This is quite different than "Numeric Type Juggling", so I'll > call it "Numeric Internal Parameter Type Juggling". > > If I pass a variable to an internal function that expects a boolean, > it sort-of works. I can pass integers, strings, floats, and booleans, > and have normal type conversion rules apply. But if I pass in an > array, object or resource, then it will error out. So the type > juggling rules work for primitives, but not for complex types, which > is different from "Boolean Type Juggling", so we'll call it "Boolean > Internal Parameter Type Juggling". > > If I pass a variable to an internal function that expects an array, it > will error out if not. It will not even attempt a cast, which is > quite different from "Array Type Juggling". So let's call this "Array > Internal Parameter Type Juggling" (even though it doesn't juggle > anything)... > > If I pass a variable to an internal function that expects a hash table > it can conditionally accept an object (as long as the hash table param > is defined as a capital H). This is even more different than arrays, > so "Hash Table Internal Parameter Type Jugging"... > > If I pass a variable to an internal function that expects an object, > it will error if it's not an object with no casting attempt. Let's > call this "Object Internal Parameter Type Juggling". > > > So in reality, there are tons of different rules and cases on how this > happens. > > But the odd thing is that while we can wrap internal functions, we > cannot use the same casting rules as they can. So writing a wrapper > for substr is non-trivial. You **HAVE** to: > > function mysubstr($string, $from, $to = 0) { > if (!is_numeric($from)) { > throw new Exception('From Must Be Numeric'); > } > if (!is_numeric($to)) { > throw new Exception('To Must Be Numeric'); > } > return substr($string, $from, $to); > } > > Otherwise your code will possibly throw errors. > > So to bring consistency in, what I would like to do is have the > ability to add the same type hints (with the same casting rules) that > zend_parse_parameters has into userland code. So, have the ability to > do: > > function (string $string, int $from, int $to = 0) { > } > > And have the exact same functionality occur as happens with internal > functions. That will do two things: make internal code and user-land > code behave consistently when it comes to type juggling, and make it > easier to extend internal functionality transparently without tons of > boilerplate code... > > Thoughts? > > Anthony > > > On Thu, Mar 1, 2012 at 6:10 AM, Kiall Mac Innes <ki...@managedit.ie> > wrote: > > On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine <les...@lsces.co.uk> wrote: > > > >> Both provide something that a large number of people did not or do not > >> want anything to do with. > >> > > > > I disagree - The majority of PHP developers I've discussed this with are > > in favor of adding *something *like this. Do a majority want this? I have > > no idea and, I honestly don't believe you do either. > > > > > >> Namespace was forced on us in much the same way you are currently trying > >> to force this on us. > >> > > > > Forced? Nobody is forcing anything. Discussions are happening, and > possibly > > a vote in the future. This is the farthest thing from being forced IMO. > > > > > >> Many people who were pursuaded that namespace was a good idea are now > >> realising that it wasn't and was the thin end of wedge which this > >> discussion is once again trying to force open. > >> > > > > Many of the popular frameworks have made the changes, or are planning to > > make the changes, needed to take advantage of namespaces. This, to me, > > suggests a general acceptable of namespaces. > > > > Also - I'm yet to hear a single complaint about namespaces > > - although again, I've not talked to every PHP developer! > > > > (Well.. No complaints other than the namespace separator being a '\' that > > is) > > > > > >> I have no objections to 'object orientated' as that is how I have always > >> used PHP, but the BULK of the data I am handling is simply strings which > >> 'magically' get converted to the format I need. I don't see any use for > >> 'type hinting' in any form since I NEED to check if a string I get in > has > >> the right data in before I store it in a database field. I don't need to > >> throw some random error which needs handling ... I just handle the > errors > >> in line as I process the data. My framework helps to ensure what I get > in > >> is right in the first place anyway, so even the in-line checks are > probably > >> redundant nowadays! > >> > > > > I can certainly agree with you here - have I ever absolutely NEEDED this? > > Nope. Would it get it the way of writing code in certain situations? Yup. > > > > But - Does that mean it's not generally useful? Nope! > > > > Kiall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
