Reply on "Who is using namespaces in PHP already?"

Vesselin Kenashkov schreef:

We had no issues related to the namespaces (well we found & reported some
minor bugs, but not related to the namespaces).

to be clear, your not using namespaced functions or constants?
and your not using any classes that are not namespaced?
how are you handling usage of internal classes?

No, in fact everything (classes, functions, constants) is namespaced (in
order to avoid collisions if external code is used), except just a few
initialization lines of code (which is outside any function/method). Then a
few manually included namespaced classes, and then the autoload
functionality gets on...

Of course we have one namespace per file, having the file structure

following the namespace structure. As well, as Karsten mentions,
converting
some_class_name_new to some::class::name::new is not an option.
We had no issues with the name resolution and no confusion so far on how
to
use the namespaces. In fact, we have a complex autoload procedure that
follows the directory/namespace hierarchy to load/create (yes we generate
some) classes. No issues with the autoload so far. Just one note: you
should not throw Exceptions during the all autoload process, not just the
__autoload function.

true, although you can actually successfully throw an exception from
within autoload to the scope that triggered the autoload ... it's a bit of
a
WTF, there is also a workaround that uses eval to generate a class (when
the
class isn't found) that does nothing except throw exceptions upon init,
static calls
etc ... so that the code trying to use the non-existent class does actually
get
a class of the given name but using it always results in an exception
(e.g.
AutoLoadException or UnknownClassException)

I haven't checked the releases in the last month so

this might have changed. Besides the namespaces, our internal framework
uses
in it fundamentals the Late Static Binding (for creating singletons and
providing the static method get_instance ).

are you in a position to offer a few bits of example code to demostrate
how/what
your doing with respect to namespaces. I'm in the process of gathering
material
in order to compile a 'best practices' guide for namespaces ... I believe
that
there is a strong need to educate users in general on how/what/why to do
things
a certain way with namespaces (I include myself in that group of users!)
... maybe
some of your implementation details could help educate others?

see below for some examples...

In overall I can say that php 5.3 is highly anticipated (both because of

the
namespaces and LSB). I'm reading the ongoing discussions and proposals for
support for multiple namespaces per file but this I think will delay 5.3.
My
opinion is that php 5.3. has to be finally released even with limited
support for namespaces. It can be followed immediately with another
release
with the extended namespace support (this way many users will switch to
namespace support although some CMS/frameworks will not because for
optimization reasons they combine files). 5.3 was delayed enough
already...

your using alpha software in production, understandbly your hoping nothing
changes and that it's released asap. but really your on the bleeding edge,
some
blood is to be expected.

Well, the expected price to pay for it :)
The namespaces allow true modularity without endless class names like
some_class_name_new or otherwise simulated namespaces.

In fact our previous version of the framework was in desperate need for
something like the LSB and that was the other major reason to switching to
php 5.3.

Consider this example:

<?
class singleton
{
private static $instances;

public function __construct()
{
$c = get_class($this);
if(isset(self::$instances[$c]))
{
throw new Exception('You can not create more than one copy of a
singleton.');
}
else
{
self::$instances[$c] = $this;
}
}

public function get_instance()
{
$c = static::$class;
if(!isset(self::$instances[$c]))
{
$args = func_get_args();
$reflection_object = new ReflectionClass($c);
self::$instances[$c] = $reflection_object->newInstanceArgs($args);
}
return self::$instances[$c];
}

public function __clone()
{
throw new Exception('You can not clone a singleton.');
}

public function whoami()
{
return static::$class;
}
}

class singleton_test extends singleton
{
protected static $class = CLASS;
}
?>

We have to use LSB ($c = static::$class;) in the get_instant method,
otherwise it will simply not work.

Regargind the namespaces, the first thing that comes to my mind is that we
have MVC framework and obviously I would like the name of the View to be the
same as the name of the Controller. In our case the Actions are public
methods and the request parameters are the arguments (we are using the
Reflection to achieve this). Then for the Controller for example we have:
<?
class cart extends controller
{
public function add()
{
}

public function remove()
{
}
}

?>
And for the view:
<?
class cart extends view
{
//...the same methods...//
}
?>
Obviously without namespaces we will have name collision. With namespaces we
can have:
<?
namespace ourframeworkprefix::controllers;
class cart //...
?>
And:
<?
namespace ourframeworkprefix::views;
class cart //...
?>
We can extend this even more - with Packages:
<?
namespace anticollisionprefix::shopping::controllers;
class cart ...
?>
Then we can fit here the Model (if it has to have the same name...)

Of course this example can be expanded furter with:

namespace prefix::package::views::viewprocessor::media
like:
namespace prefix::package::views::xsl::screen
namespace prefix::package::views::smarty::print

For me this is extremely useful, because I can have classes with the same
name for the views for all the different processors, media and avoiding the
name collision with the controller.

And organizing the file structure reflecting the namespaces like:

/package/controllers
/package/models
/package/views/xsl/screen
/package/views/smarty/print

makes it easier to create an autoload function. Then in the controller you
can simply type:
$o = new prefix::package::models::model(); or $o = new
prefix::package::models::model::get_instance(); (using a singleton)

In the same time the models are in the same namespace/dir which gives you
the possibility to reference the other model classes wihtout the namespace
(and under definition of the MVC it self you will not need to reference the
controller or the view classes so no need to use the "use" statement in the
models).

This is my story with the namespaces and the LSB.

I don't actually think either LSB or namespaces is that highly anticipated
in the larger arena, I think users like yourself and I are in a minority
in that respect. I also think that uptake of these features will be modest
at best, many developers/projects require that their code runs on older
versions
(even to the point of still supporting php4) which makes applying these new
features impossible for them.

As I said at least for me there is a huge advantage of using 5.3. As well I
haven't checked the status of the rest of the changes like the overloading
of static properties/calls but this could be another useful addition...

Vesselin Kenashkov

Vesselin Kenashkov

On Tue, Sep 16, 2008 at 2:10 AM, Jochem Maas jochem@iamjochem.com
wrote:

Vesselin Kenashkov schreef:

Hi,

At our company the majority of the projects in the last 4 months are
using
namespaces (we can afford using dev version of php, because we host the
projects).
Just to add my +1 into the count.

care to elaborate? what are your experiences? have you run into any
trouble?
have you developed a list of do's and dont's? (as Karsten has)

Vesselin Kenashkov

On Mon, Sep 15, 2008 at 5:26 PM, Karsten Dambekalns <karsten@typo3.org

wrote:

Hi.

Lukas asked on his Blog, so here goes my answer.

We switched to namespaces last week for FLOW3 and all related packages.
See
http://forge.typo3.org/repositories/revision/21/1210 for the needed
changes and

http://forge.typo3.org/wiki/flow3-overview/Notes_on_using_PHP_namespacesfor
some notes on the implications.

Currently we don't have any problems with use statements, as we still
have
fully qualified names almost everywhere, thus autoloading works as
expected.

Still, looking into the future I'd love to see an enhancement as
proposed
by Greg in http://marc.info/?l=php-internals&m=121527668606247 plus
some
way to get rid of having to use single classes if I could use some
wildcard
instead.

Regards,
Karsten

Karsten Dambekalns
Gimme Five!
http://typo3.org/gimmefive

You'd probably have more replies about this on php-general. Good idea
to put all the ideas together though :)

--
Slan,
David