EHS Blog
Home  
 
 
  Previous 10 Posts
  - Chunk_split() Overflow not fixed at all...
  - What site do you want to break today?
  - BlogSecurity Interview
  - About the CSRF Redirector
  - More CSRF Redirectors
  - MOPB Exploits taken down
  - HTML Purifier
  - Planet Web Security
  - iPhone Security Concern
  - CSRF Redirector
   

 
Categories


Web Hosting
Website Design
PHP
Perl
JSP
   

 
Archives

No Records !!!
   
 

2 3 4 5 6 7 8 

 
Shuffling methods
at 2007-08-12 19:10:22

I’m writing some quite complicated class structure in PHP, and I have realised there’s one feature I am missing in PHP - I need to be able to define an interface with default method implementation. Why not class? But of course because I can not inherit two classes. And I don’t really want multiple inheritance with all its problems - I want something much more restricted. Let’s see an example.

Let’s say I am definining interface “Kickable” having method kickMe, which describes an object that can be kicked. Most of the kickable classes would have this wonderful code:

function kickMe() {
    echo “Oy-vey!”;
}
?>

So if I have 20 classes which are kickable, I’d pr



dirname(__FILE__)
at 2007-08-12 19:10:22

This expression - dirname(__FILE__) - is used in a real lot of places. The reason is simple - libraries want to include files relative to library top directory, and do not want to count on include path. And relative include resolution rules in PHP not clear to all, so people prefer to be sure. The downside here is that this expression is dynamic - executed at run-time. Meaning it’s slower and less toolable and also makes a bad habit of putting dynamic things into include (which is not a problem here, since it’s “static dynamic” thing, but still a bad habit).

So why won’t we have constant that would mean dirname(__FILE__)? Something like __FILEDIR__. Would make a lot of code cleaner.

The problem with it of course to make real use in code we should travel back in time to 1996 and add it there :)



static __call
at 2007-08-12 19:10:22

As everybody knows, one of very nice OO features PHP 5 has is - if method that is not defined is called on an object of a class, the class could define catch-all method named __call and thus route this method call in any way the developer wants, transparent to the user. This allows very flexible way of defining interfaces between classes - even between entities that their interface might be not known to the developer of the class, such as SOAP services. Very useful indeed.

However, we can not do this on a class itself - we couldn’t define static __call and have it route class (static) method calls the same way regular __call routes the object method calls. I wonder maybe we should have it. Along with all other __methods for overloading stuff, of course. We couldn’t probably name it __call since we already have one call but something like



Making $$$ with PHP
at 2007-08-12 19: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 19: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



 

2 3 4 5 6 7 8 


Check Out Amazon