I have downloaded last Mono source code (http://www.mono-project.com/,
version 2.0.1), the open source version of one of the most complex and
mature framework in the world, the .NET framework.
Framework is written using namespaces (as opposite to current version of
Zend). And I have analysed s
> Zend_Acl ==> Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface,
> Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry...
>
> Regard, Stan Vassilev
Stan, ZF doesn't use namespaces yet. This is not namespaced code.
Namespaced code requires different convention
(http://framework.zend.com/wiki/d
> > Why? I have developed framework using PHP namespaces and studied Zend
> > Framework source codes and result is: if we use the new resolution
rules
> > (1), than in nearly all cases developers must prefix class names
with \,
> > only in few cases prefix is not required. Why? Because usually
David Grudl wrote:
> Try to answer the question: what is the $obj instance of?
>
> namespace foo;
> $obj = $factory->loadClass('bar\class');
bar\class
dynamic class names are always FQN.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
Try to answer the question: what is the $obj instance of?
namespace foo;
$obj = $factory->loadClass('bar\class');
---
$factory is implemented cca this way:
namespace ?;
class Factory
{
function loadClass($class) {
return new $class;
}
}
With absolute FQN is the answer evident
true, however i have a counter example: classes from more general namespace
that use further nested classes (think some kind of behaviour and different
drivers/plugins for example).
so while it's true that more nested classes usually extend the less nested
ones it also common for more generic
Why? I have developed framework using PHP namespaces and studied Zend
Framework source codes and result is: if we use the new resolution rules
(1), than in nearly all cases developers must prefix class names with \,
only in few cases prefix is not required. Why? Because usually classes in
more
Are you aware of __NAMESPACE__? Also, if you are using a lot of
external namespace names, you might consider simply defining constants:
namespace foo\bar\baz;
const ns = __NAMESPACE__;
then you can simply do
use foo\bar\baz; $name = baz\ns;
I don't see a huge pressing need for nameof since t
David Grudl wrote:
> Why? I have developed framework using PHP namespaces and studied Zend
> Framework source codes and result is: if we use the new resolution rules
> (1), than in nearly all cases developers must prefix class names with \,
> only in few cases prefix is not required. Why? Because
"Stan Vassilev | FM" wrote:
> For me the only way to make it clear to both humans and parsers alike is
> the filepath semantics, in all places, including use. It's not perfect,
> there's no completely problem-free solution, but "prepend \ for absolute
> path" is able to become muscle memory, while
Stan Vassilev | FM wrote:
>> Hi Marcin,
>>
>> Stan also requested this, so it should be considered as a possibility.
>>
>> Personally, I would rather not introduce this land mine. It requires
>> the user to do an implicit prepending of namespace name ("foo") to "bar"
>> in the use statement as wel
Hi Marcin,
Stan also requested this, so it should be considered as a possibility.
Personally, I would rather not introduce this land mine. It requires
the user to do an implicit prepending of namespace name ("foo") to "bar"
in the use statement as well as a translation of "A", which could fast
let's look at this code:
There are a few things to keep in mind. PHP has __autoload(), which C#
does not have. Thus, a solution such as:
1) try foo\classes\foo\stuff
2) try foo\stuff
Greg, this is clear. I am trying to point something different - to try
ONLY 2) and never try 1).
Why
Marcin Kurzyna wrote:
>
> namespace foo;
>
> use bar as A; /// ->resolves as A == \foo\bar
> use \bar as B; /// ->resolves as B == \bar
>
> ?>
Hi Marcin,
Stan also requested this, so it should be considered as a possibility.
Personally, I would rather not introduce this land mine. It req
Greg Beaver wrote:
>
> namespace foo\classes;
> use sneaky\devil as foo;
>
> class buh extends foo\stuff {}
> \\ this extends sneaky\devil\stuff. oops... should have used \foo\stuff
> ?>
accualy I have a question about this if i may: why doesn't the use statement
fall under the same resolutio
David Grudl wrote:
> Původní zpráva
> Předmět: Re:Namespace resolution rules has been changed?
> Od: David Grudl <[EMAIL PROTECTED]>
> Datum: 10.11.2008 23:53
>> > Can you please point us to an example describing this best practice?
>>
>> For example Namespace Naming Guidelines in
Původní zpráva
Předmět: Re:Namespace resolution rules has been changed?
Od: David Grudl <[EMAIL PROTECTED]>
Datum: 10.11.2008 23:53
> Can you please point us to an example describing this best practice?
For example Namespace Naming Guidelines in .NET
(http://msdn.microsoft.com
Or Zend Framework source code. There is no class extending class from
subpackage (class Zend_View extends Zend_View_Abstract is not
subpackage, viz
http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff).
*
> *In PHP nothing bubbles, hence this doesn't work.
> Can you please point us to an example describing this best practice?
For example Namespace Naming Guidelines in .NET
(http://msdn.microsoft.com/en-us/library/893ke618(VS.71).aspx)
"A nested namespace should have a dependency on types in the containing
namespace. For example, the classes in
I understand this new behaviour is same as using "relative paths", but
there is a common best practise to not make dependencies form topper
namespaces to deeper ones.
So it is rare to have class Company\Software\Base extending
Company\Software\Web\Forms\Control (i.e. Base extends Web\Forms\Contr
The problem was that it isn't immediately clear why we would consider
"Sub\Object" to be the same as "\Sub\Object", but "Object" to be
different from "\Object" inside a namespace context, but the same
outside a namespace context.
The "Sub\Object" should be understand as fully qualified identi
Jaroslav Hanslík wrote:
> David Grudl napsal(a):
>> Hello!
>>
>> This code leads to fatal error: Class 'Nette\Loaders\Nette\Object'. Is
>> it a bug in current implementation or namespace resolution rules has
>> been changed?
>>
>> namespace Nette;
>>
>> class Object
>>
>> {}
>>
>> namespace Nette\L
David Grudl napsal(a):
Hello!
This code leads to fatal error: Class 'Nette\Loaders\Nette\Object'. Is
it a bug in current implementation or namespace resolution rules has
been changed?
namespace Nette;
class Object
{}
namespace Nette\Loaders;
class AutoLoader extends Nette\Object
{}
$ob
Lukas Kahwe Smith wrote:
>
> On 04.11.2008, at 18:43, Ryan Panning wrote:
>
>> Just to make my post clear, I'm in favor of this approach for
>> non-qualified calls in a namespace.
>>
>> 1. global
>> 2. autoload
>> 3. fail
>
>
> A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
- people expect direct access to the vast number of php functions/
constants
Do you know rule 1 in #phpc? This is one of those cases.
People want :: and not backslash.
People want global stuff to resolve in their namespace (how does this make
any sense? the very idea of a namespace is to avoid
Here are some reasons why we felt that functions/constants should
fallback:
- most namespace users will be using classes and not functions
This is a self-fulfilling prophecy, the more you open a gap between classes
and functions, the more people will stick with the richer functionality
since
Here is a reason why we would limit this to international functions only:
- <@Stas> but note that global user-space fallback for function means
run-time resolution (which may be ok, but slower - no caching resolution
in bytecode cache)
Hi,
Not true: you can't resolve it at compile time wit
On 04.11.2008, at 18:43, Ryan Panning wrote:
Just to make my post clear, I'm in favor of this approach for non-
qualified calls in a namespace.
1. global
2. autoload
3. fail
A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just
chatting on IRC and we all favor the following:
Just to make my post clear, I'm in favor of this approach for
non-qualified calls in a namespace.
1. global
2. autoload
3. fail
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
29 matches
Mail list logo
