4 ms·
Not quite ;) I just mean that really if you look at PHP's function list, it really is just a wrapper around C libraries. Many functions map 1-1 from the C lib
by lux 19y ago
Not quite ;)
I just mean that really if you look at PHP's function list, it really is just a wrapper around C libraries. Many functions map 1-1 from the C lib to the PHP function. That's where it gets its string function names, many of the original database libraries were exactly that (which is why there was no built-in abstraction layer for so long), and you can look at GD or any other extension for more examples.
When you take that into consideration, you can see what the language designers were thinking in the decisions they made for PHP. They aren't necessarily the ideal choices, but the rationale does make sense.
- wheels 19y agoI see what you're getting at, but I think it's better said like you did in the comment above. The standard library wraps a lot of C libraries. I however suspect that more came by way of Perl, which PHP was somewhat based on. As a language, aside from the fact that they're from the same syntactic family, one is a compiled, low-level iterative language, the other is an (semi-) object oriented, dynamic, garbage collected, interpreted language. In terms of language features, it's a lot closer to the Python, Ruby, Perl clan than C.
- lux 19y agoFeature-wise, yes it's obviously closer to those, but what PHP did originally was wrap a Perl-esque syntax and dynamic environment (dynamic typing, interpreted code, GC, etc.) around C libraries as its "standard library". It's grown a lot since then, but the C connection still accounts for PHP's standard libraries, despite the big improvements in OOP and newer libraries in the last few years (SPL for example). That is where many design limitations come from, and it's why PHP's standard library is still mostly just a collection of a million functions instead of something more OOP like the Python or Ruby :)