Sean Coates wrote:
I don't believe there's anything stopping you (or other users) from creating either
userspace or extension wrappers to handle organization and consistency. You could even
use the "system" namespaces, since they don't exist.
True, the thought has crossed my mind. But I'm more concerned about
performance than organization. I don't know how to make a C extension,
but rather would have to make a PHP namespace.
Derick Rethans wrote:
> No, it would me having two implementations.
Although I don't know C, couldn't you do something like:
namespace Foo;
funciton bar($arg1, $arg2) {
return foo_bar($arg2, $arg1);
}
Stan Vassilev wrote:
> Ahem. We all secretly know how it should've been from the very start.
> Pseudo-methods for the basic types.
>
> $array->merge($array2);
> $string->len();
I like this. Although wouldn't this be more of a strict data type way of
doing things?
Lukas Kahwe Smith wrote:
> Right, if we ever namespace internal stuff (obviously there would be a
> need for some out of the box BC extension), than this would be the
> moment to fix stuff like this.
>
> Anyways, if anyone cares about any of the above proposals write up an
> RFC (or champion an existing one). Lets not end up in a situation
> where we have to refer people to the archives to understand a previous
> decision ever again.
I'm sure it would be a huge undertaking, I'm just saying that it would
be nice to see.
If I knew C I would try to help out, unfortunately I don't yet. That is
why these are all just my comments. I can't act on them but want to
voice my opinion. Again, it's up to all the great developers here.
There are a couple good proposals out there, either would fit. But, is
there something like type check foo(string $message) vs casting
foo((string) $message)?
Thanks,
Ryan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
