jrhernandez05@gmail.com (jessie

All,

After seeing Dmitry's patch, all he is allowing inside a module are import
statements and classes.

So, the question is, can we scrap both namespace constants and namespace
functions and just stay with classes (as was agreed on several months ago,
Andi himself agreeing to it)? This would make the patch smaller, simpler,
AND would allow me to reuse the "::" operator (and there would be no
conflicts with ternary operations).

I think this is the best solution thus far. If any one of you still feels a
need for constants/functions, PLEASE show me a _valid_ example that cannot
be accomplished by just simply putting the constant/function inside a class
in the namespace.

If I don't hear of any valid arguments, then I'm going to go ahead and scrap
constants and functions and then concentrate on the final details of the
patch.


Regards,

Jessie Hernandez

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

pollita@php.net (sara

Absolutely. Static methods and Class constants are more than sufficient.
All the added functionality of namespaces without all the baggage.

+1

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

helly@php.net (marcus

Hello Jessie,

i already showed that dropping constants in namespaces leeds to static
classes or private classes. So we are just shifting here. Instead of doing
work that is worth nothing you should simply try to come up with a working
patch using a working separator which can clearly only be "\".

best regards
marcus


Best regards,
Marcus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

jason@ionzoft.com (jason

Hello Sara,

Please explain what the difference is between nested classes, and
this type of namespacing?

If you scrapped namespace constants and functions, then all we have
left is classes. If it was looked at as nested classes, then we get
all the functionality with all the simplicity and the benefit of
being able to use "::".

Please take a moment to explain, because I am an avid user, not a
tokenizer

--
Best regards,
Jason mailto:jason@ionzoft.com

SG> Absolutely. Static methods and Class constants are more than sufficient.
SG> All the added functionality of namespaces without all the baggage.
SG> +1
SG> -Sara


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

oliver.graetz@arcor.de

Jessie Hernandez schrieb:


No complaints from me. I try to avoid both since a long time. Functions
would be nice, simply for convenience (sometimes one wants to use
something so often that a static method just isn't as nice), but I
really don't see any need for global constants EXCEPT that supporting
everything that's currently OUTSIDE of namespaces would allow to
completetly clean it without further work.

Did you give the "no namespaces in the ternary" idea a try?
Even if this doesn't make it I'd be happy to know if it works.

Anyways, +2 for both : and ::

OLLi

PS: I'm now preparing the final table. We should not stretch this any
more ;-) The First subscribers are getting heart attcks from too much
mail...

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

bart@mediawave.nl (bart de

I personally never use constants anyway. But at least functions and
variables should work with namespaces:

namespace name1 {
$var = 3;
function func();
}

From a language perspective those should exist only in that namespace.

I also think '\' as a seporator is nice. It has this nice filesystem
feeling to it.

(Although now I'm wondering if we use '\' as a seporator, shouldn't it
be possible to use '\' in stead of the Paamayim Nekudotayim '::'
seporator as well? Just to keep things consistent? hmmm... )

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

sb@sebastian-bergmann.de (sebastian

Sara Golemon schrieb:


+1

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

stas@zend.com (stanislav

MB>>work that is worth nothing you should simply try to come up with a working
MB>>patch using a working separator which can clearly only be "\".

That's one creative way of using "working", "clearly" and "only" with
meanings that I was not familiar with before.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

jrhernandez05@gmail.com (jessie

Matthias,

Simply put, const != define. Like I think Sara mentioned before, defines are
runtime-defined, and making it both compile-time/runtime defined based on
context will be really confusing.

Also, I'm not accepting variables in namespaces and this is not needed
either. So, yes, this is outside the scope of what I want to accomplish.


Regards,

Jessie


Bart de Boer came up with a good reason for them so I'd like to re-post his statement.
<quote>
Namespace constants can be handy if you'd want to include some library
that uses predefined constants and classes that might conflict with
other classes and constants in the script.

namespace someLib {
include('huge_conflicting_library_that_I_dont_want _to_reverse_engineer') ; }
</quote>

Of course, that would not only require to put defines [=constants?] and
functions in namespaces, but variables as well.

namespace X {
var $foo = 1;
function bar($p) {}
}

X::bar(X::$foo);

which can, of course, not easily be distinguished from static class
members.

So is the whole "include-legacy-stuff-into-namespace"-approach beyond
the scope of what you're trying to do?

-mp.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

bart@mediawave.nl (bart de

I'm not sure I understand this problem. Isn't it doable to define
defines at runtime and then put them under a certain namespace? I'm
assuming namespaces are defined before defines?

Ideally, I'd say there should be no code limitations inside namespaces.
But if this poses technical problems. Then I think using only classes
under namespaces is better then no namespaces.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php