Re: [PHP-DEV] Strict typing
2010/8/12 Zeev Suraski z...@zend.com: At 04:02 12/08/2010, Josh Davis wrote: What would be interesting to see is what people think of Derick's latest proposal allowing both the strict typechecking and the more sensible weak typing Everyone who opposes strict typing on grounds that it's an alien feature to PHP(*) doesn't see any advantages in this suggestion, as everything that's bad in strict typing remains on the table. If there were only two options left on earth, strict typing and strict+auto-conversion, I'd vote for going with just strict. Who appointed you the official anti-strict ambassador? If there really are so many people who think it's the worst idea since the dawn of mankind, it will be revealed when it's inevitably time for a vote. Perhaps if you stopped pretending to know everybody's opinion, it would be easier finding a consensus. Unless someone expressed their opinion, it is *unknown*. Stick to expressing your *own* opinion. I don't see any reason why we can't provide smartcast for when the API provider cares about the value *and* strict typing for when the API provider cares about the data type. Providing both options instead of only strict is entirely different. If there is only strict, then that is the only option the PHP users have if they want type hinting (yes, incorrect term, yadda yadda). If both are available, people still have the option to use strict in the specific use cases where they need it, but use smartcast otherwise. If you don't like function foo(int $i) (strict) vs. function foo((int) $i) (smarcast), it could just as well be function foo(int $i) (smartcast) and function foo(+int $i) (strict, other char than plus could possibly be used). This has two benefits to the former syntax choices: 1) The smartcast syntax would be consistent with how the APIs are documented in PHP's documentation, so the syntax in PHP would not conflict. 2) +int isn't used anywhere, so it's obvious that it's something different and it's easy to see in API documentations, auto-completion, etc. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strict typing
On Wed, Aug 11, 2010 at 23:26, Zeev Suraski z...@zend.com wrote: Now that strict typing is pretty clearly off the table [...] Did I miss a vote or something? The only thing I've seen is the same small group of people that has been fighting for the last few months. Your reasoning seems to be there are people who complained, so it's out, but there are plenty of people who haven't complained, so it's in is an equally justifiable position to take. Obviously people aren't going to sends loads of I think everything is perfectly fine-emails. PS: Can I get a list of the PHP axioms? Seeing as that's apparently how things are decided, it would be nice if people won't have to waste your precious time making obnoxious feature requests that are *clearly* against the PHP axioms. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace separator constant
On Tue, Aug 10, 2010 at 21:56, Christian Kaps christian.k...@mohiva.com wrote: Hi, is there any reason why no namespace separator constant exists in PHP. I have many cases where I concatenate strings to a namespace. This ends up with many class constants like const NS_SEPARATOR = '\\'. A default PHP constant would be a better way to handle such cases. It is already constant (i.e. it's always a backslash). What do you need a constant for? It's not system nor configuration dependent. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Jul 29, 2010 at 09:43, Ferenc Kovacs i...@tyrael.hu wrote:
On Thu, Jul 29, 2010 at 3:49 AM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
I've updated the patch and the RFC that proposes the return type-hint
implementation (Engine + Reflection).
The proposed implementation is working just like the last changes in the
parameter type-hint (in trunk). i.e. working with the scalar and numeric
pseudo-types.
http://wiki.php.net/rfc/returntypehint
Thoughts?
--
Regards,
Felipe Pena
Hi, I would love this feature.
But I have some concerns.
AFAIK you can declare classes with the name int ,scalar, etc. so
hinting anything else than class names can be ambiguous.
Or we have to set these keywords as reserved, so nobody could declare
classes with such names.
Weren't they already made reserved with the parameter type hinting patch?
But in this case, this would be a big BC problem, especially, because
I think that there is many project out there which uses type
names(int, object, etc.) as classname.
Try to search class Object{ or class Object extends on google codesearch.
Maybe this was resolved with the last scalar type hinting patch, which
got merged to the trunk, I don't know.
ps: the spam filter rejected my previous email because of the
codesearch links...
Tyrael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove variable function and method calls
On Fri, Jul 23, 2010 at 21:34, Karoly Negyesi kar...@negyesi.net wrote: This is plain false. PHP does care for BC a lot. OK. I will try to test PHP to help you guys in this. I know there is documentation but it often misses crucial subtle points and there is not a lot of education of the public to set expectations. If the documentation is missing information about BC breaks, please file a doc bug at http://bugs.php.net. If nobody is aware that it is lacking, naturally it won't be improved. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 10:34, Arvids Godjuks arvids.godj...@gmail.com wrote:
Please read more carefully - what I mean that is we deal mostly with
numbers witch are represented as strings, because all data that comes
from external sources are STRING regardless of actual contents - be
that integer or float - no matter. I don't want to make my code look
like this:
function doSomeStuffWithDbData(int $id, string $name, int $someFlag) {
}
$sql = 'SELECT id, name, some_flag, FROM table WHERE .';
$res = mysqli_query($db, $sql);
$row = $res-fetch_assoc();
doSomeStuffWithDbData((int)$row['id'], $row['name'], (int)$row['some_flag']);
And so on. There is no meaning in doing explicit type casts and then
check the type again! Because if you have bogus data like 123abc
with type cast you cast it to 123 integer and you function check for
integer will pass without any notice!
Hm, it just strike me. If you want a strict type checks, you have to
convert your data before you pass it when it comes from outside (and
it always does by the way! - databases, request data, files). So
basically you will first convert it and then pass to functions to
avoid inconsistent type errors. And UPS! Magically you have no errors!
because $data = '123abc'; $data = (int)$data; results in pure 123 int.
No benefit in using type hints at all.
If you don't know whether the user/database provided information you
have is correct before you pass it along to something else, I would
say that the code indeed is bad. Unless you regard 123abc as a valid
value from your user, don't allow the user to give you that value. If
you regard it as a valid value, then it's not an int thus you wouldn't
want to type cast it in the first place.
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 10:53, Arvids Godjuks arvids.godj...@gmail.com wrote:
Heh... Please do a DB select and make a var_dump on the rows from
database. You will see things like:
array(3) {
[id]=
string(1) 1
[ref_id]=
string(2) 15
[name]=
string(7) Bla bla
}
string, string and string again.
And that breaks the concept of strict type hinting. Because we get
data from DB in STRING type, regardless of the type of the DB fields.
And that's my argument for auto-converting type hints when it is
possible without data loss. I expect PHP to pass indexes id and
ref_id to function, witch expects int without any notices or errors
- just do the bloody thing with converting to int and do your work. If
I pass name index to that function - it should fail with a Fatal
error.
So, stop twisting my words and taking sentences out of the context,
please! I don't want to argue on things that I described in detail and
people just skim them trough just to reply with critics just for the
sake of making a reply.
I don't see how I'm twisting your words.
As for the database: Hopefully you know what types you have in your
database. If you know that a particular column is an int, then casting
to int is entirely a non-issue.
As for user provided data: Say you ask the user how old he is (that
would be an int)? If he answers 123abc then your validation logic
should catch that he entered an invalid value. Once you've determined
that it is a valid value, then casting to int is a non-issue.
--
Daniel Egeberg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
On Thu, May 27, 2010 at 11:05, 魏世江 shiji...@staff.sina.com.cn wrote: Hi . I think there is no need to argue on it any more. Good programmers have the ability to manipulate the variables' types. But I think it's the icing on the cake if we give the PHP programmer the choice of whether use explicit types. For examlpe, we may add a switch in php.ini, let's say, explict_types=On/Off. A php.ini setting is a really bad idea. Say that Library A expects it to be On, but Library B expects it to be Off. Now what happens if I want to use *both* Library A and Library B? -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autoboxing in PHP
On Tue, May 4, 2010 at 05:48, Moriyoshi Koizumi m...@mozo.jp wrote: Hey, Just to let you know about a new RFC for adding autoboxing feature in PHP. Look at http://wiki.php.net/rfc/autoboxing . Regards, Moriyoshi Is there any reason why primitives couldn't be autoboxed to SplInt, SplBool, etc.? These classes could maybe even be extended with method aliases to the relevant functions in PHP's library. -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ArrayAccess::offsetGet not returning a ref
On Tue, Apr 27, 2010 at 10:51, Peter Cowburn petercowb...@gmail.com wrote: On 27 April 2010 09:17, Etienne Kneuss col...@php.net wrote: Hi, it looks like the fact that ArrayAccess::offsetGet is not returning a reference is a recurrent problem, I see basically 4 options: a) Ignore the issue, change nothing b) Rewrite offsetGet to return a ref, breaking BC -1,000,000 c) Create a new ArrayAccess interface where it does return a ref d) Relax prototype checks so that both are allowed. Of the options presented, I think d) would be the best of the bunch. Folks seem to expect the ability to get references so any solution that gives them that would be better IMO than keeping the interface as-is. Without having the technical insight in how it works internally, I would also say that from an end-user perspective, option (d) makes most sense. Personally, I believe that a fatal on such prototypes error is not warranted, so I'd prefer (d). What do you think would be the best option? Can you think of another? -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: gerardobenitez
On Tue, Apr 13, 2010 at 16:21, Gerardo Benitez gerardobeni...@gmail.com wrote: Translating the documentation What language do you intent to translate it to? -- Daniel Egeberg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
