Monthly Archives: July 2011

Overview of classes and objects

Objects are the building blocks of the application (ie: the workers in a factory)
Classes can be thought of as blueprints for the objects. Classes describe the objects, which are created in memory.
So, the programmer writes the classes and the PHP interpreter creates the objects from the classes.

A class may contain both variables and functions.
A variable inside a class is called a property.
A function inside a class is called a method.

Instantiation

To create an object, you instantiate a class (you create an instance of the class as an object).
For example, if we have a class named ‘person’ and want to instantiate it as the variable $oliver:

$oliver = new person();

The variable $oliver is referred to as the ‘handle’.

Accessing properties and methods

To access the properties and methods of a class, we use the object’s handle, followed by the arrow operator “->”.
For example, if our class has a method ‘get_name’, we can echo that to the page with:

echo $oliver->get_name();

Note that there are no single or double quotes used in instantiating a class or accessing properties and methods of a class.

Constructors

A class may have a special method called a constructor. The constructor method is called automatically when the object is instantiated.
The constructor method begins with two underscores and the word ‘construct’:

function __construct($variable) { }

One can pass values to the constructor method by providing arguments after the class name.
For example, to pass the name “John Doe” to the constructor method in the ‘person’ class:

$john = new person("John Doe");

! If a constructor exists and expects arguments, you must instantiate the class with the arguments expected by the constructor.

Access modifiers and visibility declarations

Properties must, and methods may, have one of three access modifiers (visibility declarations): public, protected, and private.
Public: can be accessed from outside the class, eg: $myclass->secret_variable;
Protected: can be accessed within the class and by classes derived from the class
Private: can be accessed only within the class

Declaring a property with var makes the property public.

Methods declared without an explicit access modifier are considered public.

! If you call a protected method from outside the class, any PHP output before the call is still processed, but you get an error message when the interpreter gets to that call:

Fatal error: Call to protected method...

Inheritance

Inheritance allows a child class to be created from a parent class, whereby the child has all of the public and protected properties and methods of the parent.

A child class extends a parent class:

class employee extends person {
}

A child class can redefine/override/replace a method in the parent class by reusing the method name.

! A child class’s method’s access modifier can not be more restrictive than that of the parent class. For example, if the parent class has a public set_name() method and the child class’s set_name() method is protected, the class itself will generate a fatal error, and no prior PHP output will be rendered. (In the error below, employee is the child class to person):

Fatal error: Access level to employee::set_name() must be public (as in class person) in E:xampphtdocstesteroopclass_lib.php on line 38

To differentiate between a method in a parent class vs the method as redefined in a child class, one must specifically name the class that contains the method you want to call using the scope resolution operator (::):

person::set_name($new_name);

The scope resolution operator allows access to static, constant, and overridden properties or methods of a class, generally, a parent class. This would be done inside the child class, after redefining a parent’s method of the same name.

It’s also possible to use ‘parent’ to refer to the child’s parent class:

parent::set_name($new_name);

(I’m still a bit vague on this and am looking for examples of situations in which this would be used.)

Classes inside classes

Just as it’s possible to instantiate a class and use the object in a view file, it’s possible to instantiate an object and call its methods from inside another class.

Static properties and methods

Declaring class properties or methods as static makes them accessible without needing an instantiation of the class. A property declared as static can not be accessed with an instantiated class object (though a static method can).

Resources
http://us2.php.net/manual/en/language.oop5.php
http://net.tutsplus.com/tutorials/php/oop-in-php/
http://www.phpfreaks.com/tutorial/oo-php-part-1-oop-in-full-effect
http://www.killerphp.com/tutorials/object-oriented-php/

The other day, I needed to extract a 7 GB zip file containing a VMware virtual machine onto the hard drive of a nearly stock 64-bit Windows 7 Professional machine. Because this machine did not have a third-party compression utility installed, I tried to extract it using Windows’ native zip utility, called Compressed Folders.

This failed with a pretty neat error.

You need an additional 5.99 PB to copy these files.

As you can see in the screenshot above, Windows reported that…

Copy Folder

There is not enough space on Local Disk. You need an additional 5.99 PB to copy these files.

Local Disk
Space free: 125 GB
Total size: 232 GB

[Try Again] [Cancel]

I found the 5.99 petabyte requirement pretty amusing, but I was in a hurry, so I downloaded the excellent 7-Zip, unpacked the file, and set about building the vm.

I had meant to write a post about the error message, but some time passed and I forgot all about it. Then, about three weeks later, someone else in the department tried to extract a copy of the file on a 32-bit Windows XP Professional machine and got the same error. At that point, I had to investigate.

The Compressed Folders native Windows utility seemed to be unable to accurately calculate the free space needed to extract the file. The file was admittedly pretty large, but was size the only reason?

According to the Wikipedia page on ZIP files, there are a number of known limitations of Compressed Folders.

ZIP64, AES Encryption, split or spanned archives, and Unicode entry encoding are not known to be readable or writable by the Compressed Folders feature in Windows XP or Windows Vista.

http://en.wikipedia.org/wiki/ZIP_(file_format)#Windows_compressed_folders

None of these things applied to my file, but I found a rather telling and simultaneously ambiguous (go figure) KB article at Microsoft Support: Compressed folder becomes corrupted when larger than 2 gigabytes.

According to various threads, the popular theory is that the problem stems from size limitations on compressed files. Windows Vista and later have a 4 GB limit (compressed and uncompressed size), while XP has a 2 GB limit.

Strangely, the same error appears before a copy process when the OS encounters a file that exceeds its maximum individual file size, which I can understand, but find a bit confusing in the context of a zip file. Certainly, both Windows 7 and XP (NTFS) were able to handle the file to begin with, and only had a problem when decompressing it.

My best guess is that the file was created using the Compressed Folders feature on XP. The file exceeded the maximum size limit for that version of Windows, but due to the bug described in MS KB article 301325, the file was created anyway using 32-bit headers. When the file was later opened by Compressed Folders, the 64-bit headers were read (as a file of that size would naturally use 64-bit headers), but that information was garbage, preventing Windows from accurately calculating the space required to extract.

If anyone has a more complete understanding of the cause of this error, please leave me a comment.

I’m running XAMPP 1.7.4 [PHP: 5.3.5] (not as a service) on 64-bit Windows 7 Professional.

I installed XAMPP to E:\xampp, and I have pinned the XAMPP Control Panel (xampp-control.exe) to the taskbar for easier access, but starting up xampp-control.exe from that shortcut throws an error:

XAMPP Control

XAMPP Component Status Check failure [3].

Current directory: E:\xampp

Run this program only from your XAMPP root directory.

[OK] [Cancel]

Strangely enough, I even get this error even when running xampp-control.exe from my XAMPP root directory, which really is E:\xampp.

The last post in the thread at http://www.apachefriends.org/f/viewtopic.php?f=16&t=44320&sid=a41029c6a36bbf5b3bb5817f37842340&start=60 offers a simple solution: change the Install_Dir value under HKEY_LOCAL_MACHINE to point to C:\xampp. According to the thread, the error message is due to a bug where the Install_Dir is checked against a hard-coded path on C:\. That may or may not be the case, but the suggested work-around seems to be effective.

Here’s a registry merge for Windows 7 64-bit that will make the change for you.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\xampp]
"Install_Dir"="C:\\xampp"

Now xampp-control.exe launches without the error, and I haven’t noticed anything (PHP, MySQL, etc.) not working because of the bogus path.

Back in May of 2011, the Xbox.com forums were redesigned. The old forum’s content was transferred to a new subdomain at http://forumsarchive.xbox.com/ and left to rot.

What happened to all the stuff in the “old” forums?

For a limited time, all your posts from the previous version of the forums live on forumsarchive.xbox.com (will be available shortly after the new forums have gone live). They are available for you to go grab any FAQs, walkthroughs, and other valuable posts that you created, so you can repost them in the new forums.

http://forums.xbox.com/xbox_forums/forum_faq/f/6/p/3058/19910.aspx

That isn’t quite true, as I’ve found links in posts on ardamis.com to at least one thread that I’d started on the old forum that is missing from the archive, so there has obviously been some culling happening.

I suspect that not only were countless useful threads simply abandoned or even deleted, but probably millions of inbound links to xbox.com were left to 404.

Instead of redirecting all of the links to the old forum threads, visitors following those links now see an ugly IIS server error message.

Server Error in ‘/’ Application.

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.

Requested URL: /31685953/ShowPost.aspx

It’s stunning, actually, how poorly this transition was handled, and I’m not alone in thinking that. There are even threads on the new forum about how much better the old one was. I cannot picture any metric by which improvement is measured that would indicate this change was successful. And I would love to know how the decision was made to let tons of inbound links 404. Who on earth would allow this to happen to their site?

One of my most popular articles at ardamis.com was a description of the slow death of my Xbox 360 at the hands of FFXIII, which thankfully didn’t link to the forum threads that it referenced for support. All those threads on how either a) Final Fantasy XIII broke dozens of Xbox 360s, or b) dozens of Xbox 360s just happened to break as people were playing Final Fantasy XIII, disappeared. But I’ve begun a new one, for posterity (and not because I still play the game, which I found to be a huge disappointment). So, to keep the flame of discontent burning, here’s the link to the new thread on Final Fantasy XIII freezing on Xbox 360.

On the upside, a quick look at the HTML of the new pages suggests that the links are not nofollowed, which is something else I found interesting about the old forums.