pestilence669

Fair enough, but I still disagree. You might want to submit your patch before the thread on the internals mailing list dies off.

Nothing should be stopping you from entering TSQL directly into your ODBC call. IIRC, you define your variables, call your stored procedure, then SELECT a row back out. It looks something like: DECLARE @foo1 INT DECLARE @foo2 INT CALL fooProc(@foo1, @foo2) SELECT @foo1 AS foo1, @foo2 AS foo2 Sorry if there's a syntax error. It's been awhile, but the idea is the same.

Where does it say your php.ini is located? Try: <?php phpinfo(); ?> I'm not sure if you're having the issue I'm thinking of, but depending on the PHP build, it could be looking for your INI in the wrong place. On a side note, you REALLY don't want to use the MSSQL extension. Microsoft's driver hasn't been maintained in close to a decade and leaks memory badly. I suggest searching for code using the ADO interface or the ADOdb extension. Both are more modern and will give you less headache.

lol. you are insane! is this in PECL yet?

There's been talk about scalar type hinting on the PHP internals list. Not that the patch you wrote isn't cool (I did look at it), but my question is why? Warning: I'm not flaming, but I am I'm biased toward dynamic languages & duck typing. Your blog seems to suggest that we're at complete opposites. I honestly would like to see one or two solid use cases for such a thing. I've written a lot of strongly typed code in C++ and Java, so I naturally would hate to see rigid types in PHP. I simply don't think it belongs and I fear that code might collectively devolve into things like: <?php abstract class FooBase { private $value = null; abstract public function setIntValue(int $value); abstract public function setBoolValue(bool $value); abstract public function setFloatValue(float $value); abstract public function setStringValue(string $value); abstract public function setValueToNull(); } ?> I was going to say that the code above is an exaggeration, but it's not. I work on a project that has nearly the same thing sprinkled over 400+ classes. The major difference is that scalar typing is enforced by a bunch of is_int(), is_bool(), is_float() and is_string() calls. The result is that everyone simply casted everything, but of course, inconsistently. You can't have scalar typing without adding more typecasting. They go hand in hand. Some people, obviously not myself, prefer explicit type declaration (and typecasting) to inference. Considering that scalars can (and are) casted automatically... I'm still wondering why take type safety to this level? Explicit casting might make code look like the early days of C with many (void *) pointers: $foo->setIntValue((int) $GLOBALS['id'], (int) $_POST['foo'], $_POST['bar'] == 'yes' ? true : false); Do I have to narrow of a view?