# AW:  Basic Namespace Requirements

- Thread: https://externals.io/message/20812
- Original archive: https://news-web.php.net/php.internals/20812
- Started by Matthias Pigulla on 2005-11-29T11:06:19+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #20812 — Matthias Pigulla — 2005-11-29T11:06:19+00:00

URL: https://externals.io/message/20812#20812

> Von: Jessie Hernandez 
> 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)? 
...
> 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.

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.

---

## #20834 — Jessie Hernandez — 2005-11-29T15:35:06+00:00

URL: https://externals.io/message/20812#20834 · In reply to: #20812

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

""Matthias Pigulla"" <mp@webfactory.de> wrote in message
news:00A2E2156BEE8446A81C8881AE117F192C1D5D@companyweb...

> Von: Jessie Hernandez
> 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)?
...
> 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.

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.

---

## #20840 — Bart de Boer — 2005-11-29T16:29:36+00:00

URL: https://externals.io/message/20812#20840 · In reply to: #20834

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.



Jessie Hernandez wrote:
> 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
> 
> ""Matthias Pigulla"" <mp@webfactory.de> wrote in message
> news:00A2E2156BEE8446A81C8881AE117F192C1D5D@companyweb...
> 
> 
> > […]
> 
> ...
> 
> > […]
> 
> 
> 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.