Note that I say "try internal" because the only purpose behind allowing
this is to make it easier to use PHP's built-in functionality. Any
userspace stuff should be specifically \prefixed or imported via use.
And (yes) we need import for functions.
Greg
P.S. my mail server has been down for
Hi!
or in other words give the user the ability to specify when he wants the
fallback to global and not doing a fallback to global per default. That way
This would be quite complex thing since this way you can't be sure which
class gets loaded when you say, e.g., Exception - and thus, if you
Hello Gregory,
Tuesday, November 4, 2008, 5:15:35 PM, you wrote:
> Christian Schneider wrote:
>> Lukas Kahwe Smith wrote:
>>> one could also do
>>> 1) ns
>>> 2) global
>>> 3) autoload
>>
>> I'm in favour of this (if it avoids performance problems) as I don't see
>> a problem with giving global p
Hello Lukas,
Wednesday, November 5, 2008, 12:32:19 AM, you wrote:
> On 05.11.2008, at 00:12, Marcus Boerger wrote:
>>> classes:
>>> 1) try ns::class
>>> 2) autoload ns::class
>>> 3) fail
>>
>> Since we can stack autoload we could provide a c-level autoload
>> function
>> that does the default
2008/11/5 Cristian Rodríguez <[EMAIL PROTECTED]>:
> Lukas Kahwe Smith escribió:
>
>> Also should there be some other way to get STDOUT and STDERR defined
>
> I assume we are talking about userland constants right ?
Yes, userland constants defined with define().
>
>
> --
> "Good, Fast, Cheap: Pick
2008/11/5 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
>
> On 04.11.2008, at 23:02, Lukas Kahwe Smith wrote:
>
>>
>> On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote:
>>
>>> 2008/10/27 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
> 2008
On 05.11.2008, at 00:12, Marcus Boerger wrote:
classes:
1) try ns::class
2) autoload ns::class
3) fail
Since we can stack autoload we could provide a c-level autoload
function
that does the default lookup.
function global_autoload($name) {
if (($p = strrpos($name, '\\')) !== false) {
$
Lukas Kahwe Smith escribió:
> Also should there be some other way to get STDOUT and STDERR defined
I assume we are talking about userland constants right ?
--
"Good, Fast, Cheap: Pick any two (you can't have all three)."
Cristian Rodríguez R.
Platform/OpenSUSE - Core Services
SUSE LINUX Produ
On 04.11.2008, at 23:02, Lukas Kahwe Smith wrote:
On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote:
2008/10/27 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
2008/10/26 Johannes Schlüter <[EMAIL PROTECTED]>:
On Sun, 2008-10-26 at 14:32 +0
I'd prefer to have it fixed, but then it probably requires changing
the parameters API for 'a', which might lead to some unexpected
results with regard to functions that modify their arguments. I
think we may leave it alone for this alpha but try to resolve it for
5.3 release.
If my opini
Hi!
so where do we stand here?
I'd prefer to have it fixed, but then it probably requires changing the
parameters API for 'a', which might lead to some unexpected results with
regard to functions that modify their arguments. I think we may leave it
alone for this alpha but try to resolve it
On 24.10.2008, at 14:15, Felipe Pena wrote:
Hi youngs,
What about moving mSQL to pecl? :)
Derick copied it to pecl .. and i will delete it from php-src asap.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote:
2008/10/27 Lukas Kahwe Smith <[EMAIL PROTECTED]>:
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
2008/10/26 Johannes Schlüter <[EMAIL PROTECTED]>:
On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote:
So, I propose its
I'm too busy to review anything anytime soon; got lots on for the next
couple of months here at work.
--Wez.
On Nov 4, 2008, at 4:51 PM, Lukas Kahwe Smith wrote:
Hi,
Sorry about the top post, since I am CC'ing Wez and Sara again with
the tiny hope of a reaction.
It seems the streams layer
On 28.10.2008, at 15:33, Stan Vassilev | FM wrote:
I would say "no" for 5.3. But for 6 it would be fantastic to have
all array-related
operations supporting ArrayAccess interface, where possible.
+1 for this.
Hi,
cu, Lars
Just making sure but: I think the BC break should be fixed. It's
Hello again,
once again top posting this this is fairly old ..
however for something that is sounding so promising I am wondering why
this hasnt been picked up ..
regards,
Lukas
On 20.10.2008, at 22:09, shire wrote:
On Oct 19, 2008, at 12:11 PM, Karoly Negyesi wrote:
Hi,
I think zend_h
Hi,
Sorry about the top post, since I am CC'ing Wez and Sara again with
the tiny hope of a reaction.
It seems the streams layer is effectively unmaintained. Greg's seems
to have gotten his fingers a bit in there, but for such a critical
piece I guess it would be good to have at least 1-2 mo
2008/11/4 Andrey Hristov <[EMAIL PROTECTED]>
> Ryan Panning wrote:
>
> use 'NsA\NsB\NsC\func_c()';
>>
>
> OMG That looks UGLY1
>
This is exactly the kind of comment that is both useless and pointless.
Could you please make sure that you have a valid point with a subject,
arguments, e
As you pointed out, there is no autoload for functions, so people are
accustomed to ensuring that all functions are loaded before usage. Am I
missing something?
Yes - you're missing the possibility of overriding, AKA naming collisions
between internal and userspace funcs/consts.
- Steph
-
On 04.11.2008, at 18:59, Gregory Beaver wrote:
#2 means we want to be able to access stuff like strlen() and
array_map() without any monkey business.
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
Right, for the most part people will want access to intern
Ryan Panning wrote:
use 'NsA\NsB\NsC\func_c()';
OMG That looks UGLY1
$obj = new NsA\NsB\ClassB;
$obj->methodB();
func_c();
?>
Best,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Steph Fox wrote:
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which "randomly" occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and
should *
Hi Greg,
By doing the resolution I've suggested (and Stas, incidentally, was the
first to suggest this):
classes:
1) ns\class
2) autoload ns\class
3) FAILBOAT
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
We get the best of #1 and the best of #2, and it makes
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
> Distributed to user, that has ns.lookup=On as you propose, user borks
> his
> install, lacks the file containing the class, gets the global class ->
> obscure error messages because of nonexisting methods in places
> unr
Lukas Kahwe Smith wrote:
>
> On 04.11.2008, at 17:15, Gregory Beaver wrote:
>
>> In other words, it is perfectly all right to have a different name
>> resolution for classes than we have for functions and constants because
>> of this different expectation. It is dangerous to fallback for classes
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
On Tue, 2008-11-04 at 16:48 +, Steph Fox wrote:
> >> What am I missing?
> >
> > That INI is the worst we could do. Because it prevents from writing
> > portable code.
>
> This particular INI doesn't prevent anyone writing portable code. It simply
> gives the option of a 'tighter' development
First, I want to say thanks for determining the best separator. Even
though it's not what everyone would like, it's what would work best.
Second, sorry for starting a new thread. To me, continuing the
resolution discussion in the "namespace separator and whining" isn't the
correct place.
Thi
On Tuesday 04 November 2008 18:27:43 Steph Fox wrote:
> Hi Stefan,
>
> > Dev writes a script, uses autoload, overrides global class.
> > Distributed to user, that has ns.lookup=On as you propose, user borks his
> > install, lacks the file containing the class, gets the global class ->
> > obscure e
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks his
install, lacks the file containing the class, gets the global class ->
obscure error messages because of nonexisting methods in places unrelated
to
t
On Tuesday 04 November 2008 17:44:50 Steph Fox wrote:
> We could have an INI_SYSTEM switch.
>
> ns.lookup=Off
>
> means you _have_ to prefix because otherwise resolution will fail with a
> fatal error, but
>
> ns.lookup=On
>
> means that anything not prefixed and not local goes through the full
> l
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which "randomly" occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and should
*always* be used in
What am I missing?
That INI is the worst we could do. Because it prevents from writing
portable code.
This particular INI doesn't prevent anyone writing portable code. It simply
gives the option of a 'tighter' development mode.
- Steph
--
PHP Internals - PHP Runtime Development Mailing Li
Hello Steph,
Tuesday, November 4, 2008, 5:44:50 PM, you wrote:
> Hi Greg, all,
>> For this reason, the only resolution that we should be considering is:
>>
>> classes:
>> 1) try ns::class
>> 2) autoload ns::class
>> 3) fail
>>
>> functions/constants:
>> 1) try ns::function/ns::const
>> 2) try in
Hi Greg, all,
For this reason, the only resolution that we should be considering is:
classes:
1) try ns::class
2) autoload ns::class
3) fail
functions/constants:
1) try ns::function/ns::const
2) try internal function/const
3) fail.
I see this as giving priority to library authors rather than
On 04.11.2008, at 17:15, Gregory Beaver wrote:
In other words, it is perfectly all right to have a different name
resolution for classes than we have for functions and constants
because
of this different expectation. It is dangerous to fallback for
classes
prior to autoload, but it is not
Christian Schneider wrote:
> Lukas Kahwe Smith wrote:
>> one could also do
>> 1) ns
>> 2) global
>> 3) autoload
>
> I'm in favour of this (if it avoids performance problems) as I don't see
> a problem with giving global priority over autoload.
Hi,
This is the current name resolution. The proble
Hello Internals,
with many thanks to Greg we now have settled on \ as the namespace
separator. The next topic on the agenda is name resolution:
http://wiki.php.net/rfc/namespaceresolution
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
Lukas Kahwe Smith wrote:
> one could also do
> 1) ns
> 2) global
> 3) autoload
I'm in favour of this (if it avoids performance problems) as I don't see
a problem with giving global priority over autoload.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: htt
On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote:
Hi
I have tried to collect the various opinions on resolution order
into a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of
function/constants w
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Ionut,
>
> some remarks about your proposal:
>
> 1) You can turn any array into a Traversable using
> (Recursive)ArrayIterator. Though this solution is still slow. The issue is
> that the c-level code needs to v
How you got both files is beyond me - winres.h is not present in either
the 2003 sdk or the 6.1 sdk (used with VC6 and VC9 respectively) - our
current instructions for building involve renaming header files in the
sdk which is a very silly thing.
Nah, it'll be a legacy thing. I've only ever inst
Steph Fox wrote:
> Hi Elizabeth,
>
> I think you'll find that's version-specific. I have both those files,
> and they do rather different things. Can you test against both VC 6 and 9?
>
> - Steph
>
> - Original Message - From: "Elizabeth Marie Smith"
> <[EMAIL PROTECTED]>
> To: <[EMAIL P
2008/11/4 David Zülke <[EMAIL PROTECTED]>:
> Am 03.11.2008 um 16:41 schrieb Marcus Boerger:
>
>> 2) Ther are iterator_apply()
>
> owww that sounds like it really needs docs :>
http://bugs.php.net/bug.php?id=30185
Long time standing bug :)
--
Kalle Sommer Nielsen
--
PHP Internals - PHP Runtim
Am 03.11.2008 um 16:41 schrieb Marcus Boerger:
2) Ther are iterator_apply()
owww that sounds like it really needs docs :>
smime.p7s
Description: S/MIME cryptographic signature
On Tue, Nov 4, 2008 at 10:11 AM, Ionut Gabriel Stan
<[EMAIL PROTECTED]> wrote:
> Anyway, I see there's nobody else that would like this but it's ok, at least
> now we have namespaces so that
> I don't have to come up with ugly names like my_map() for these kind of
> helper functions.
I like the pr
On 11/3/2008 17:41, Marcus Boerger wrote:
Hello Ionut,
some remarks about your proposal:
1) You can turn any array into a Traversable using
(Recursive)ArrayIterator. Though this solution is still slow. The issue is
that the c-level code needs to verify the current pointer every single time
i
47 matches
Mail list logo
