A rather good curry

I've tried the Brick Lane curry experience a few times now, as I live in East London and work in Bethnal Green, but have always been disappointed. I think out of the worst half a dozen curries I've ever had in my life, Brick Lane has accounted for about five of them.

Curry Capital, then, was a real find. It's slightly further up the north end of Brick Lane than the large gaggle of Indian and Bangladeshi restaurants usually are and is almost on its own. There's no-one outside touting free beer, wine or starters (a very good sign) and the decor is quite sophisticated... relative to the rest of Brick Lane's offerings, of course.

The food is also pretty good - certainly well above anything else I've had down London's most famous curry street. The "Katmandu Delicacy" I chose had very tasty fresh chillies, and lamb that didn't require oversized muscles to chew on. The sauce was richly flavoured and the side dishes were equally good.

Although the menu did offer what they called 'Old favourites', the main focus was definitely on the Chef's Specialities listing. These dishes were the most interesting and the descriptions of each makes them very appetising.

Beer was the usual offering of Cobra or Kingfisher. Prices came to £25/head for main course, a couple of beers, rice, naan and a couple of side dishes, which seemed very reasonable given the quality

Class hinting is where the class of object to be passed into a method is specified in the function call.

e.g.

abstract class User
{
 protected $logState;
 
 public function User()
 {
  $this->logState = new LogState()
 }
 
 public function setLogstate(LogState $logState)
 {
  $this->logState = $logState;
 }
}

This code will throw a runtime error if the variable passed into the setLogstate method is anything but a LogState object.

The benefits of this are twofold:

• Errors in code are trapped at an earlier point in runtime. If the type was not checked then $this->logState may contain, for example, a string or other variable type and the mistake not caught until much further through processing making it more difficult to locate the source of the error.
• The code is self-documenting as it is obvious to anyone reading the setLogstate method what class of object $logState will contain

The hint may not just be a class, it can also contain the name of an interface. Hence a method such as:

function saveSomething(Saveable $objectToSave)
{
 //Do things with $objectToSave
} 

will allow through any object which implements the Saveable interface.

Interfaces are a way of adding the definition of extra methods onto a class to force it to conform to a particular pattern. An interface consists entirely of methods with empty bodies i.e. abstract methods:

interface Saveable()
{
 public function save();
}

Classes implement interfaces as a way of guaranteeing that they will allow a set of operations as specified by the interface. E.g.

abstract class User implements Saveable
{
 /*
  Previous code for User here
 */
 public function save()
 {
  //Code in here for saving to disk
 }
} 

Interfaces are useful primarily to help document and constrain code, especially when used with class hinting (see next section). A class may implement more than one interface, separated by a comma e.g.

class User implements Saveable, Cacheable 

Advanced uses of Interfaces allows the treatment of objects as arrays (by implementing Iterator, ArrayAggregator and a number of Standard PHP Library interfaces).

Next section: Class hinting

Static classes are used for utility scripts that (in the past) would have been in common functions or held global variables. The advantage of using a static class is more to increase code readability (and ease of debugging) than for any other reason. A static class may have properties and methods but there will always be only one ‘instance’ (hence static) and any changes will be made ‘globally’.

Static classes are often used for algorithms that may be used by multiple classes. They may also be used to construct objects of a specific type and to abstract logic from classes (to encourage loose coupling of objects – i.e. the ability of one class to operate without dependency on another). The example that follows allows the passing in of a username and password and will decide which class of user to instantiate and return. This is important in the case where we want to create a User object, but we have now defined the User class as abstract – how do we know what class of User to create?

class UserHandling
{
 public static $numUsers = 0;

 //a static class has no constructor

 /*
  This static method accepts a username and password
  and returns an object of type User
 */
 static public function makeUser($username,$password)
 {
  /*
   Logic in here to look in a database
   and get a userTypeID based on username and
   password
  */
  if($isValidUser)
  {
   if($isAdmin)
   {
    $user = new AdminUser();
   }
  else
  {
    $user = new RegisteredUser();
  }
  }
  else
  {
   $user = new UnregisteredUser();
  }
  UserHandling::$numUsers++;
  //Changing a static variable
  //inside the class still
  //needs the full reference.
  //There is no “$this” inside a
  //static class.
  return $user;
 }
}

//To make a user object, from anywhere in the code
$user = UserHandling::makeUser($username,$password); 

Properties accessed from outside a static class (if they’re public) are also handled in the same way:

echo UserHandling::$numUsers;

Next section: Interfaces

Abstract classes are used to define operations and parameters but where you do not want a class instantiated directly. An abstract class must, therefore, have subclasses. In our example, we may not allow a type of general “User” but insist that a specific type is created. We can do this by defining the class as abstract:

abstract class User
{
 protected $logState;
 
 function User()
 {
  $this->logState = new LogState()
 }
 
 public function setLogin($loginValue)
 {
  $this->logState->setLogin(true);
 }
 
}

A call to $user = new User(); will now be invalid. Instead, we must call a subclass e.g. AdminUser.

An abstract class may contain abstract methods. These define the template for the method that must be implemented by each subclass. Abstract methods have no body, as with showNavigation() below:

abstract class User
{
 protected $logState;
 
 public function User()
 {
  $this->logState = new LogState()
 }
 
 public function setLogin($loginValue)
 {
  $this->logState->setLogin(true);
 }
 
 abstract public function showNavigation();
}

It would then be compulsory for each and every subclass of User to define a method called showNavigation() and to provide body code to perform the operation.

Next section: Static classes

PHP 5 allows you to declare properties and methods as public, private or protected. These are defined as:

• Public: anyone either inside the class or outside can access them
• Private: only the specified class can access them. Even subclasses will be denied access.
• Protected: only the specified class and subclasses can access them

It is good practice to mark properties as protected (at least) and to use get/set methods to change their value. This future-proofs the code and can reduce the number of changes that need to be made. E.g. the existing user code makes use of an isLoggedIn variable. Making the variable protected and adding a method to set its value like this:

class User
{
 protected $isLoggedIn = false;
 
 function User()
 {
 }
 
 function setLogin($loginValue)
 {
  $this->isLoggedIn = $loginValue;
 }
 
}

will prevent code outside of the class (or subclasses) from changing the value of isLoggedIn without going through the setLogin() method. Although it may seem long-winded, the code of User may change in the future e.g. with the addition of a ‘LogState’ object to handle the logging in status:

class LogState
{
 protected $isLoggedIn = false;

 function __construct()
 {
 }

 function setLogin($isLoggedIn)
 {
  $this->isLoggedIn = $isLoggedIn;
 }
}

class User
{
 protected $logState;
 
 public function User()
 {
  $this->logState = new LogState()
 }
 
 public function setLogin($loginValue)
 {
  $this->logState->setLogin(true);
 }
 
}

If access to the logged in state of the user is protected then every change to it will be through the setLogin method. Now that a new object is controlling the state, only the method needs to change and no other code will notice the alteration. Protected and private methods prevent outside calls to methods which may upset the internal state of an object.

Next section: Abstract classes

The introduction of a method called __construct() means that function User() no longer need be the default method name for instantiating an instance of the User class. This is especially useful in the case where you are using subclasses, or if the name of the class changes during development. E.g. In the example above, the constructor for User is called User() and the constructor for AdminUser is called AdminUser().

class User
{
 function __construct()
 {
 }
}
class AdminUser extends User
{
 //No constructor in here, so we’ll
 //use the parent’s code
}

Alternatively, the AdminUser constructor may use the majority of code from its parent but may also add to it. The parent’s constructor may then be called from within the child class.

class User
{
 function __construct()
 {
 }
}

class AdminUser extends User
{
 function __construct()
 {
  $isAdmin=true;
  //Call the parent’s constructor now
  parent::__construct();
 }
}

Next section: Public, private, protected

Subclassing allows flexibility in code. E.g. there may be many types of User to a site. We can define subclasses of User such as AdminUser, RegisteredUser, UnregisteredUser which may share some common methods and properties but may have unique abilities. The syntax for this is simple:

class User
{
 //constructor function for User
 function User()
 {
 }
}
class AdminUser extends User
{
 //constructor function for AdminUser
 function AdminUser()
 {
 }
}

The method of logging in for all users may be the same, so we add a method to the User class:

class User
{
 //constructor function for User
 function User()
 {
 }
 
 function doLogin($username,$password)
 {
  //Code in here
  return $result;
 }
} 

As AdminUser extends User the method doLogin() will be defined (identically) for both classes.

Alternatively, a new method called doLogin() could be written specifically for AdminUser to handle a distinct situation. This can be tackled on a subclass-by-subclass basis e.g. AdminUser and RegisteredUser may use the common doLogin() method but UnregisteredUser has its own version.

N.B. The signatures of methods in subclasses must match that of the parent class (as PHP does not support overloading). Therefore a definition of

Public function doLogin($someArray)

In AdminUser would be invalid code (as it only accepts a single variable) and caught at compilation time (i.e. before runtime).

Next section: The constructor method

PHP 4 passed variables by value by default. This was not very pleasant to work with. The way around this was to pepper your code with ampersands (to tell PHP to use references instead) but forgetting to include one was difficult to debug. By default, PHP 5 passes all objects by reference. Therefore calling:

$user->getLogin($_SESSION);
print_r($_SESSION);
class User
{
 function getLogin($sessionArray)
 {
  //Code in here
  $sessionArray[] = “another value”;
 }
}

will result in exactly the same object (the session array) being passed into the method and used by it throughout. As we are adding an extra value to it the session array outside of the method will also change.

N.B. this isn’t particularly good practice in itself as it is not entirely clear from the line User.getLogin($_SESSION); that the $_SESSION array is being changed. A more self-documenting way or writing this would be $_SESSION = User.getLogin($_SESSION); and to return the $sessionArray variable from the getLogin() method.

Next section: Subclasses

Classes are used as an abstraction of a real world situation. E.g

class User
{
}

may be used to contain the code that will represent a user of an application.

Objects have properties and methods. Properties may be thought of as adjectives (e.g. coat->blue) and methods as verbs (e.g. coat->putOn()).

e.g. to create a user class, instantiate it and set a login property to true

class User
{
 var $isLoggedIn = false;
 //Variable to contain the logged-in
 //state, with a default value of ‘false’
 
 function User()
 {
 }
 
 function login($loginValue)
 {
  $this->isLoggedIn = true;
 }
 
}
$user = new User();
$user->login(true);

will create the user with a default property (isLoggedIn) and then log the user in with a method (login).

Next section: By reference or by value

Read more at:
PHP 5 Classes and objects on php.net

I found the pictures of Toyota's robot cars/personal vehicles very interesting. ('Those whacky Japanese do it again' was going to be my alternative headline, but that doesn't give a great deal away about the content.) Okay, they may only travel at less than 1mph and look like a 1960's sci-fi view of the future, but aren't they great anyway?

I was less pleased to see all the negativity which always seems to come from our British academics as soon as anything tries anything different:

Dr Erel Avineri, of the Centre for Transport and Society at the University of the West of England in Bristol said: "The design of the introduced mobility devices is not completely adjusted to the specific needs of the elderly and the disabled."

And at what point did Toyota say 'This is a finished product. isn't it great!' It's just a show, for christ's sake...

"In general, introducing a new technology requires the passenger to change behaviour patterns that have served the older passenger for decades. Elderly users might not necessarily accept such innovation.

"This may be another barrier to the commercial success of such a vehicle."

Call me cynical, but I have a feeling that Toyota may know slightly more about the commercial realities of selling vehicles than an academic from Bristol, so perhaps they've got that area covered?

"The concept of personal mobility behind these sorts of innovations is great but they beg a huge number of questions": Dr David Gillingwater, Loughborough University

Yes, and that's the point. IT'S AN EXPO!

BBC NEWS | Technology | Robotic pods take on car design

I recently downloaded and installed QuickTime. I couldn't do much about it, but it installed QuickTime at the same time. I have no desire for keeping iTunes on my system, and certainly no reason to have an iPodHelper.exe process running all the time (since I don't own an iPod). There were no options to uninstall iTunes - it was just not on the uninstall radar at all.

The solution was to download iTunes again, install it, and then uninstall it. This also installed QuickTime again, but uninstalling it only removed iTunes.

The last step was to go into the registry editor (run: regedit.exe), drill down to HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/
Windows/CurrentVersion/Run and remove Qttask from starting up each time windows loaded. So now my system is not owned by Apple and I can watch quicktime movies on the rare occassions taht something entertaining comes along.

Quicktime installs a very annoying process when you install it on Windows XP called qttask.exe that you may often see running in your taskbar and processlist. There is no way to stop it running from within quicktime's preferences. Instead, you must:

• Go to 'Start' -> 'Run'
• Type 'regedit' and click 'OK'
• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Apple Computer, Inc.\QuickTime\ActiveX
• Find the value QTTaskRunFlags, right click on it and change the value to 0
• Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\
  Windows\CurrentVersion\Run
• Delete the value pointing to qttask.exe

That should stop it running automatically when you start windows or when you open Quicktime.

If you are also stuck with iTunes then see this post about removing it after you've installed Quicktime

"Attention grabbing pseudo-science headline". It's not so dramatic as it sounds - apparently we're all carrying loads of data round on our PDA's. So nothing to do with obesity at all.

BBC NEWS | Technology | Britons growing 'digitally obese': "Britons growing 'digitally obese'"

An interesting browser (mostly, it has to be said, Internet Explorer) rendering issue has produced an slightly odd workaround. The problem arises from the rendering of form elements, specifically dropdowns, by the browser. These are registered as windows components and hence are rendered somewhat outside of the other HTML elements. (This is not true in Firefox and other Mozilla based browsers which have their own rendering. It is painfully true of the old Netscape 4 where all form elements show through, but there's no fix for that at all.) The same rendering issue is also true of frames, iframes and embedded objects (albeit Flash can now be specified with a transparent background).

This gives the situation where a layer (in a div tag) over the top of a dropdown box leaves half the select box visible through the layer. E.g.

The code for this follows:

<div style="position: relative;">
  <form name="testForm" id="testForm">
    <select name="test" id="test">
        <option>Peekaboo!</option>
    </select>
  </form>
  <div style="background: rgb(0, 102, 153); position: absolute;
    left: 50px; top: 10px; width: 300px; height: 20px;
    color: rgb(255, 255, 255); overflow: hidden;
    clip: rect(auto, auto, auto, auto);">
      I'd like to be on top
  </div>
</div>

The solution I've found is that IFrames can be rendered on top of select tags. Not much use in itself, but ever since Internet Explorer 5.5 it's been possible to give IFrames a Z-Index and render layers on top of them. So in the rendering scheme of things:

• select beats div
• iframe beats select
• div beats select

Hence the 'Scissors, paper, stone' reference of the title. The order does seem somewhat circular

To solve the IE rendering problem we can insert an iframe between the div and the select with the same dimensions as the div tag over the top, as follows:

With the following HTML code

<div style="position: relative;">

  <form name="testForm" id="testForm">
    <select name="test" id="test">
      <option>Peekaboo!</option>
    </select>
  </form>
  <iframe style="position: absolute; left: 50px;
    top: 10px; width: 300px; height: 20px; background: #069;
    color: #fff; overflow: hidden; clip: auto;"></iframe>
  <div style="position: absolute; left: 50px;
    top: 10px; width: 300px; height: 20px; background: #069;
    color: #fff; overflow: hidden; clip: auto;">
      I'd like to be on top
  </div>
</div>

With the prospect of legalised casino's in the UK, the parallels between the 'real' world and Sim City seem ever closer. Personally, I don't know what the moral arguments before and against are, but if the government had ever played Sim City but the legalisation of gambling in that game always resulted in higher crime and, longer term, ran an area downhill so that no other businesses wanted to move in.

The BBC's take on the merits of legalising gambling can be read here

I've just come across these pages about JavaScript that I found very interesting. The examples of private variables and inheritance are quite an eye-opener for someone like me who's been writing away in JavaScript and DHTML for a few years now.