Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40529
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.166.179 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:references;
        b=iOgnZVkJcjE0IAjRPnQToYMiDP96rvaZNuUNTPy4Q5uIynH86aEyJz6Wd2FCwItS7E
         G7ww2YU4v0K+4GaRWJcTjMtVN/tH+5BI6yT4ZsmCDKuq5XsL8bvxfzvU0IxI9mNK43U0
         ePUVKR2B/f/IIm35YnJf+HfOvOSnYT52/mPe0=
Message-ID: <261daaa10809160431s6012892bud33c790998788884@mail.gmail.com>
Date: Tue, 16 Sep 2008 14:31:23 +0300
To: "Jochem Maas" <jochem@iamjochem.com>
Cc: "Karsten Dambekalns" <karsten@typo3.org>, internals@lists.php.net
In-Reply-To: <48CF8675.9040206@iamjochem.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_169275_4116645.1221564683505"
References: <66DC865A-1910-46E4-AEB5-37BE62D2417A@typo3.org>
	 <261daaa10809151520s6c3f5adfld10004d8c408f301@mail.gmail.com>
	 <48CEEB4D.2050505@iamjochem.com>
	 <261daaa10809160144y3e2d6641y9b23632ac03f2495@mail.gmail.com>
	 <48CF8675.9040206@iamjochem.com>
Subject: Re: [PHP-DEV] Reply on "Who is using namespaces in PHP already?"
From: kenashkov@gmail.com ("Vesselin Kenashkov")

------=_Part_169275_4116645.1221564683505
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Tue, Sep 16, 2008 at 1:12 PM, Jochem Maas <jochem@iamjochem.com> wrote:

> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>
>

------=_Part_169275_4116645.1221564683505--