> -Ursprüngliche Nachricht-
> Von: Sam Barrow [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 10. Dezember 2007 22:48
> An: internals@lists.php.net
> Betreff: [PHP-DEV] Namespace resolution
>
> Ok, it's supposed to be this way right? If i define a custom class in
> the global namespace cal
Hi Marcus,
Will there be another way to do this or will they only be accessible from
the object?
- Frank
> Hello Rob,
>
> this is intended. The 5.2 solution is just a hack and returns a wrong
> result in the first place. The hack was however introduced to make
> development easier. Now with 5
Ok, it's supposed to be this way right? If i define a custom class in
the global namespace called "myClass" and I'm in another namespace, I
can only access it using ::myClass, not just myClass (without the
colons)? Seems to me that it should check the local namespace and then
the global, but it onl
Both are now on http://bugs.php.net/bug.php?id=43541. Ignore the first of
the three, it breaks when the length param isn't passed.
I'm going offline before I say anything else stupid :)
- Steph
- Original Message -
From: "Steph Fox" <[EMAIL PROTECTED]>
To: "Stanislav Malyshev" <[EMAIL
Agreed. I don't see any point in this limitation. As for confusion,
debugging would not be too hard (just echo __NAMESPACE__), or brackets
would solve that problem.
On Mon, 2007-12-10 at 16:59 -0300, Martin Alterisio wrote:
> 2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
> >
> >
> > > c) If br
Hello Rob,
this is intended. The 5.2 solution is just a hack and returns a wrong
result in the first place. The hack was however introduced to make
development easier. Now with 5.3 we were able to change the API and coudl
apply the solution that was first developed in HEAD.
marcus
Sunday, Dece
So it's better to check for == 0? What's the difference? Is an IS_NULL
check slower?
No, it's not slower, but it makes no sense to compare variable value to a
type constant. Even if coincidentally constant value is the same one you
need to compare to.
OK, so if I clean up those patches and r
It builds without complaint and works as expected - what am I missing?
IS_NULL is variable type. length is variable value.
So it's better to check for == 0? What's the difference? Is an IS_NULL check
slower?
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http:/
2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
>
>
> > c) If bracketed namespaces are a no-go, consider the possibility of
> > > declaring the full name of the namespaced element in its definition:
> >
> > Which would lead to people routinely mixing different namespaces inside
> > one file. Bad
So it's better to check for == 0? What's the difference? Is an IS_NULL
check slower?
No, it's not slower, but it makes no sense to compare variable value to
a type constant. Even if coincidentally constant value is the same one
you need to compare to.
--
Stanislav Malyshev, Zend Software Arch
It builds without complaint and works as expected - what am I missing?
IS_NULL is variable type. length is variable value.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development M
if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
+convert_to_long(length_param);
Isn't convert_to_long non-separating one? I think the variable supposed to
be separated before conversion, so convert_to_long_ex (and zval **) would
be in place.
Hm you're probably ri
2007/12/10, Martin Alterisio <[EMAIL PROTECTED]>:
>
>
> > 2) Using :: as namespace separator generates ambiguity
> >
> > Would that be 20th reincarnation of "let's find weirdest namespace
> > separator" thread? :)
>
>
> Please no. Just find the right one.
>
PS: Wasn't : (one colon) used as namespa
if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
+convert_to_long(length_param);
Isn't convert_to_long non-separating one? I think the variable supposed
to be separated before conversion, so convert_to_long_ex (and zval **)
would be in place.
+if (length == I
2007/12/10, Stanislav Malyshev <[EMAIL PROTECTED]>:
>
> > All namespace access should be explicit:
>
> Consequence: nobody uses namespaces, as it's too annoying.
Putting $this-> and self:: is annoying , that didn't stop anybody from using
objects in PHP.
> b) Name aliasing with use should only g
The manual kind of skirts around it: "If length is given and is
positive, then the sequence will have that many elements in it. If length
is given and is negative then the sequence will stop that many elements
from the end of the array. If it is omitted, then the sequence will have
everything
There's an IS_NULL check...
if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
If Z_TYPE_P(length_param) is 0, it's not NULL because it has something
in it. If length_param were of type long and had a value of 0, it would
be NULL.
Ouch... Now I see. Is there anybody using
If Z_TYPE_P(length_param) is 0, it's not NULL because it has something in
it.
Bleh... but you know what I mean :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a) Introduce a special name to refer to the current namespace (as self::
works for the current class).
namespace::
> All namespace access should be explicit:
Consequence: nobody uses namespaces, as it's too annoying.
b) Name aliasing with use should only generate namespaces aliases:
See n
Right, that's what "l" parameter spec is doing, doesn't it? Why convert
it manually?
Because it doesn't know the difference between NULL and 0 if it's a long.
And why this difference is important in array_slice()? I don't see
anything in manual that says anything about NULLs. Could you explai
1) Lack of cohesiveness of name resolution rules
Why is this an argument against: name resolution rules with namespaces
change completely the way names are resolved in PHP.
How does it affects: this breaks the explicitness of names in PHP. It will
affect code debugging and review.
Example:
Su
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (63 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
43408 Open get_called_class n
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (625 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
===[Apa
23 matches
Mail list logo
