EHS Blog
  Previous 10 Posts
  - Komodo 101
  - Adding Fresh Blood to the Bleeding Edge of Web Development with Komodo 4.1.1
  - ActiveState Hackathon: Get Your Boss to Do This!
  - Google hack to instantly search for files
  - 10 JSP tag libraries no programmer should be without
  - Learning the JavaFX way of doing things
  - Using JavaFX Script for UI Declarations
  - Unicode support in JavaFX Script
  - Could you cut your development time in half?
  - Cookie Handling


Web Hosting
Website Design


No Records !!!

3 4 5 6 7 8 10 11 12 13 14 

Making $$$ with PHP
at 2007-08-12 15:10:22

Not exactly what you thought reading the title, sorry :) Just wanted to write about the topic discussed elsewhere - how one could do money calculations with PHP? PHP has no BCD type and no arbitrary precision float type either. And for money calculations is it important to have it very precise - accountants can not allow even single penny to slip by (remember the plot of the Office Space movie? ;)
So, using regular floats/doubles is not good in this case - for starters, there’s no precise representation for number as simple as 0.1! So if you make a lot of calculations with such numbers errors would creep in. Now the question is what could be done about it?

One solution is to ma

Improving executor
at 2007-08-12 15:10:22

Calling function in PHP is not cheap. One of the reasons for that executor has a lot of things to take care of when calling function - a bunch of globals, execution state, symbol tables, etc., etc. And we do a lot of allocations and reallocations for them. Also since a number of these things live on the stack - on deep recursion the stack is depleted. So I was thinking how could we improve it?

  1. First step could be to unite all execution-state related variables into single structure. In compile-time we know how many Ts, CVs, etc. we might need, so this is fixed. Size of other structures is known too, so we know overall memory size for every function, and we can automatically allocate execution data on the function start. Which means no reallocs, only one allocation per execution cycle and probably even better memory usage due to the reuse of the memory blocks for frequently called functions.
  2. Right now some of the execution data is kept

    Graceful recovery
    at 2007-08-12 15:10:22

    Right now some situations (parse errors, undefined function call, no more memory) in PHP result in fatal error - which means the engine can not continue with the request beyond this point. From the user point of view, this often results in a blank page. I wonder if it would be possible to have standard recovery mechanism that would allow the PHP engine on fatal error to enter some kind of “recovery mode” when it would output some very basic page saying “ok, I have some problems here, but don’t panic and just tell my programmer to fix the code”. It won’t give much info probably but it would allow production sites display nice message to the users instead of the boring snowfield panorama it displays now (that is if the administrator was smart enough to set display_errors to off).

    Maybe it should allow only fixed HTML, or maybe some kind of “request recovery” mode which would create some “recovery mo

    Kill resources
    at 2007-08-12 15:10:22

    I wonder why we still have resource type in PHP?

    Since 5.x, objects are perfectly capable on encapsulating any void * transparently (there’s at least 2 Java bridges doing that, for example) and of course using objects doesn’t force you to use OO syntax - i.e. you can do fread($foo) with $foo being either resource or object equally well. We can see ext/unicode/collator.c in PHP 6 as one example of dual interface also (I’m sure there are more, I just had to pick one). So objects as I see it can do anything resources can do. And much more - you could extend it (had we had file as object and not resource, streams probably would be much easier to implement), serialize it (provided correct methods of course), etc., etc.

    Also, with some effort I think it would be possible to modify all resource-using code to

    We are doomed!
    at 2007-08-12 15:10:22

    Generally I enjoy reading all kinds of “PHP sucks” and “PHP is doomed” articles, of which there’s no shortage. First, many times the authors have very interesting ideas on places where PHP does suck and can use improvement - and the more good ideas the merrier. Second, once you read a dozen of them you can’t help noticing how people say PHP sucks and is doomed for entirely contradictory reasons which makes it fun. And last but not least - if people write about flaws of PHP it means they care. Nobody writes about why PL/1 sucks and how Clipper is doomed ;)

    Recently on PHP blogs I saw a reference to one blog entry - named “PHP is Doomed!” of course - that proclaims PHP is doomed for one single reason - it doesn’


3 4 5 6 7 8 10 11 12 13 14 

Check Out Amazon