Hello All,

I am new to the php internals mailing list. I am a fairly experienced
programmer with a few ideas floating around. I have come from a C++ games
development background and have now moved to primarily writing in php.

One thing that I used extensively in C++ was the singleton design pattern.
I assume that most of you know what that is, if not a quick google search
will let you know. I have written an implementation of singleton in php,
but it's slow, and you have to use strings to reference the classes, or
duplicate a lot of code. (See methods 1 and 2 below)

I recently submitted an RFC to bugs.php.net about this, but there was never
feedback from the internals group, so I am going to try here.

http://bugs.php.net/bug.php?id=39946

In a few months time, I would like to start helping the development of php,
but I am too busy at the moment.

I was wondering if anyone has the time to implement this winner feature. I
think it would encourage good programming practise and speed up a lot of php
apps. Also I would like people's thoughts and feedback on the idea.

If no-one can implement this before me, I will have a go at it in a few
months time.

Thankyou,

Scott McNaught

Description:

Introduction

This document is an RFC for adding a small patch to the zend engine to
allow for native singleton classes. The problem
is that currently theres no clean way to implement singleton classes in
user-land over the entirety of a project.

Singleton classes are beneficial because:

• Removes the overhead of having multiple instances of the one object
  when there is no need
• Allows you to keep the objects state rather than always starting from
  an initial state.
• They provide namespaces with the benefits of polymorphism (eg -
  singleton classes can override / inherit from each other)

Throughout this document, I will use an example of a singleton class
"members" which acts as an interface to a database table.
This class can save and load members from this database table simply by
calling the following methods in this class.

members::get($member_id) Loads a member from a member id and returns an
associative array with info about that member
members::save($member) Saves a member to the database from an array of
properties about that member

With the recent phase of tiered and service oriented architecture, the
need for Singleton has become more and more apparent.

Singleton in php5

In the past, I have implemented Singleton two different ways. Both of
these have problems.

Method 1:

The first method involves having a public static getInstance method in
every singleton class. This sucks because you
need to manually copy and paste it into every singleton class you make.
Using a singleton class in this way is also confusing
for novice programmers. Eg:

<?php

class members
{
static public function getInstance()
{
static $object = null;

	if($object)
	{
		return $object;
	}
	
	$object = new members();
	return $object;
}

/**
 * Returns a member from the database based on their id
 */
function get($id)
{
	// ...
}

// save method etc...

}

// Usage
$arrMember = members::getInstance()->get(49);
$arrMember['member_f_name'] = 'Scott';
members::getInstance()->save($arrMember);

?>

Method 2:

This method involves an associative array of class names to their
instances, probably via a helper function similar to this.

<?php

class members
{
/**
* Returns a member from the database based on their id
*/
function get($id)
{
// ...
}

// save method etc...

}

/**

• Returns an instance of a singleton class from its class name
  */
  function getInstance($strClass)
  {
  static $objects = array();

  if(!isset($objects[$strClass]))
  {
  return $objects[$strClass];
  }

  $objects[$strClass] = new members();
  return $objects[$strClass];
  }

// Usage
$arrMember = getInstance('members')->get(49);
$arrMember['member_f_name'] = 'Scott';
getInstance('members')->save($arrMember);

?>

This sucks because its slow, confusing for novices, and IDEs never pick
up the class for code hinting.

Proposed new functionality

I propose that singleton classes become a native part of the php
language by adding the "singleton" class modifier T_SINGLETON.

I don't know if native singleton classes have been implemented in a
language before. Most other languages eg - C++
you can use template classes or generics to implement a clean
singleton.

The zend engine could feature a hash table and store the instances of
objects.

An example of the new way of using singleton classes would be:

<?php

/**

• A class for saving / retreiving members from a database
  /
  singleton class members extends dataadapter
  {
  /*
  * Returns a member from the database based on their id
  */
  function get($id)
  {
  // ...
  }

  // save method etc...
  }

// Usage
$arrMember = members->get(49);
members->save($arrMember);

?>

Edge cases / got-cha's

Some investigation will have to be performed as to how inheritence will
work with singletons.

Eg

• Never have singleton abstract classes?

• What happens when $members = new members() is called
  -- I say an exception being thrown and a suggestion to remove "new"

• Is it ok to go $members = members; ?
  -- I'd say yes

• Singleton constructors should not have parameters

• Perhaps a new function singleton_getobjects needs to be added to
  enable access to the internal hash table

• Dereferencing a non-singleton class should produce the same error

Hello Pierre,

Sunday, March 4, 2007, 6:22:03 PM, you wrote:

To make this long story short, I do not understand the reason behind a
glob:// stream wrapper. It makes no sense. But yes, we need a better
glob support in PHP. Many extensions needs it. For example, I have my
own version for zip, it is bad as the only difference is how I get the
path string, the pattern implementation being 100% the same (using
pcre or bsd's glob)

So instead of discussing here you should take the glob code of win32
directory, check the license and either make otwork as you want or reqrite
it.

I don't get what you are trying to say here.

Having that stuff in zip makes absolutely no sense at all. Especially
when it is already there. It is always better to reuse then to provide new
errors...

Is it not what I just said?

You miss/drop my point, I don't like the glob:// wrapper addition. It
makes no sense as it has no meaning from a URI point of view.

Then don't use it.

That's a comment I will keep in mind.

To have the pattern matching functions (something like fnmatch for
example) always available and exported is indeed a good thing. Many
extensions can use it. That does not mean we cannot rely on the system
versions when available (for the local file operations at least).

Another thing is that doing so would only make
the glob implementation itself profit from this. Providing the other way
makes anything profit from glob support.

Correct me if I'm wrong but a Iterator+filter can do the same thing
without having this ugly glob://

$iter = new DirectoryIteratorPattern("/dir1/.jpeg");
$iter = new DirectoryIteratorPattern("zip://my.zip/dir1/.jpeg");
$iter = new DirectoryIteratorPattern("ftp://my.zip/dir1/*.jpeg";);

It would be much slower. And still glob offers more. It works like your
system does.

It is certainly not slower and you still did not tell me why a glob://
is required.

Given that the stream wrapper provides the minimum set of ops to do it.

What stream wrapper are we talking of now? The pcre filter stream you are
going to implement?

Ok, a pcre URI wrapper is as insane as this glob://.

The wrapper that is there right now is glob and yes,
that one provides the minimum that is needed.

I'm talking about the other wrapper like phar or zip, if they don't
provide all required functions, how will you access the directory
contents? Or know whether a path is a directory or not?

We might even think of adding
support for opening files through glob:// by having it open the first
returned file when used for file opening.

I suppose we'll need other functions to move the cursor? Or make it
move forward magically on each fopen call? That's ugly. ;-)

Exactly, Hence glob only does what it can do.

Why a new URI then? Please tell why you need a URI.

No other language implements blog or fnmatch support in such way but
using iterators and filters (in one form or another). Such magic
behaviors are always confusing.

No other lanaguage has an Iterator implementation of the power PHP offers.
So shall we drop that? And guess what languages are different. For example
no other language has ternary implemented in the way PHP has.

.... take #4

I'm talking about the new GLOB:// URI not about glob support in
Iterator. One has nothing to do with the other. URI are not PHP
specific, there is some conventions for them. But we tend to ignore
them.

Damn, it apprears we have different taste :-)

It is not about taste. A glob is not a URI-like data. It is a filter.
I hope you understand my point now (for better glob support but no
glob://), let see what the other developers think about that.

Just in case you didn't notice. Glob is for directory listing. And the glob
stream does exactly that in a portable way that can easily be used form
anything that works on directories. Plain file directories that is because
glob does not understand anything.

That's why I said it makes sense to have a glob op, a glob URI makes no sense.

And should you work on it as described
above then anything using glob stream will automagically profit from that.
And this cooperation is the reason we have streams in the first place. If
you feel i left out zip - which is what your complain sounds like.

It is not about zip, it is not a complain, it is a discussion about
your (wild) addition to the core stream.

To make it clear: I don't like the new glob:// URI. I'm not talking
about iterators goodies or anything else, period.

Then I
suppose you go the route I laid down to solve that. It is not of my concern.
I for one did something that a user brought up, which made perfectly sense
to me and which already helped me. That is all I need to know.

Before bloating the general wrapper names space with something like
that, you may consider to discuss it on this list before.

Anyway, we are running (again) in circle, you see my comments as
personal attacks and stick to your point, that's bad and that's your
choice.

--Pierre