Richard Quadling wrote:
Hi.
I'm looking to test 5.3, but I stumble at the first hurdle as the ini
file is not being read.
Windows XP Pro SP3 and Windows Server 2005/2008.
2008-12-12 15:45:36 D:\Personal
Files\Downloads\Software\Programming\PHP\Latest
Snapshots\php-5.3-win32-VC6-x86-latest >php
Jessie Hernandez wrote:
Hi Greg,
I've read through the posts and the RFC and am not sure if this was
discussed before, but there is one other proposal I'd like to throw out
there: why not require all classes that are inside namespaces to be
explicitly imported? This would foll
then use that class.
2) If not, look for the class in the global namespace (this would
include internal classes).
If one wanted to have a custom Exception class inside a namespace, one
would first alias the core Exception class and then extend from that:
Thoughts, comments?
--
Jessie Herna
also agreed that only classes should
be allowed inside namespaces
(http://marc.info/?l=php-internals&m=113320797607651&w=2), I am +1 for
this proposal.
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
--
PHP Internals - PHP Runti
Hi Greg,
How is this different from my original proposal
(http://news.php.net/php.internals/34097,
http://news.php.net/php.internals/36822)?
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Gregory Beaver wrote:
Hi,
You probably have
Hi Greg,
How is this different from my original proposal
(http://news.php.net/php.internals/34097,
http://news.php.net/php.internals/34097)?
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Gregory Beaver wrote:
Hi,
You probably have
ven't received many comments on the patch nor any
reasons on why it shouldn't be merged. Let me know what you think of the
resolution rules I proposed.
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Stan Vassilev | FM wrote:
Hi,
ction x() { // Probably the easiest
public array x() { // I like this best, if it's possible
public function x() return array { // Probably not, just throwing it out
there
Agree?
How about using the ActionScript syntax?
public function x():array { ... }
--
Jessie Hernandez
Zend Certifie
t the current PHP_5_3)
Regards,
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Julian Reich wrote:
Hi,
I recently started porting an application to PHP 5.3.
1. While testing the new namespace implementation I noticed the following:
Executing
ly from cookies (what user fills in a login form by
setting cookies?), so I don't see a point of including them.
I also like solution #2, I always read cookies using $_COOKIE.
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
--
PHP Internals -
Hi Markus,
Thanks for testing out the patch!
Has anyone else had a chance to test it out? I think this is a good
solution to the naming conflict issue that is currently present with
namespaces, but I'd love to hear other's opinions/experiences on this.
--
Jessie Hernandez
Zend
t the patch, try it out, and let me know what you think
about it or if there's anything that can be improved. Thanks.
Regards,
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Index: Zend/zend_compile.c
rst place, there will be few "use ::internalName"
statements per file, so this won't burden the user.
I'll try to come up with the patch soon, incorporating Greg's "use
::name" change.
Regards,
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php
. If possible, I'd like someone to try it out and see if they have
the same result.
As always, comments/suggestions on the patch are welcome.
Regards,
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Jessie Hernandez wrote:
I just thought o
Greg,
I've been thinking about this as well and I also concluded that #3 is
the way to go. If I "use" a class with the same name as an internal one,
then I want to reference that class, I don't care about the internal
class, and I don't want an error either. If a new PHP internal class is
add
I just thought of something that might be a solution to the lookup rules
that we currently have in the namespaces implementation. Whether it's
good or not, I just wanted to throw it out there. Here goes:
Support a user-defined function named __get_namespace_classes, which
will be similar to __
his lookup logic wasn't used in your patch?
Regards,
Jessie
Gregory Beaver wrote:
Jessie Hernandez wrote:
Hi Greg,
How about this: any non-namespaced file that uses "use" statements is
implicitly put into the __php__ namespace (or whatever other name is
chosen, or having the name
Hi Greg,
How about this: any non-namespaced file that uses "use" statements is
implicitly put into the __php__ namespace (or whatever other name is
chosen, or having the namespace name be the path of the file)? With
this, "use" will never import any symbols into the global namespace.
Regard
Lukas,
I'm not having much spare time lately, but I'd like to continue working
on the patch as soon as I can. Will the patch be needed only on PHP 6 or
is there a possibility of including it in a minor version (5.3 or 5.4,
perhaps)? If it's only for 6, I'll try to adapt my patch for it over th
Lukas,
I'm not having much spare time lately, but I'd like to continue working
on the patch as soon as I can. Will the patch be needed only on PHP 6 or
is there a possibility of including it in a minor version (5.3 or 5.4,
perhaps)? If it's only for 6, I'll try to adapt my patch for it over th
an easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.
Is this feasible in flex/bison? Let me know if anything needs clarification.
Regards,
Jessie Hernandez
Stefan Wal
Hi Marcus,
Can you please clarify where the conflicts will occur if only classes
are allowed in namespaces?
Best regards,
Jessie Hernandez
Marcus Boerger wrote:
Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain
in class_table
(e.g. "namespace_name:class_name"). This is how it is currently in my patch.
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Marcus,
As I said, I wanted to only enable classes inside namespaces, and NOT
allow functions or constants. class::const would stay the same, so there
are no conflicts.
Marcus Boerger wrote:
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace
o consider imported classes.
4) When an import is done (with alias or not), and a global class with
that same name exists, what is the desired behavior? Error? Global takes
precedence?
Regards,
Jessie Hernandez
Sean Coates wrote:
Hello all,
A number of factors have come together to p
"index << 1").
Regards,
Jessie Hernandez
Andrei Zmievski wrote:
You probably saw that I have committed initial implementation of
TextIterator. The impetus for this is that direct indexing of Unicode
strings via [] operator is slow, very slow, at least currently. The
reason i
""M. Sokolewicz"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> hi,
>
> personally, I find :::A, ::A and such constructs *extremely* ugly. Might
> I suggest using a special keyword to denote global scoped classes?
> eg:
> global:::A and such. global already is a keyword, but I'm pre
Hello Ron,
""Ron Korving"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I assume ::: is being used because it simply works and the discussion on
> which seperator to use might still go on for some time ;). You have a
point
> about import statements being allowed only in the beginn
Oliver,
Like I mentioned in another thread, ":" cannot be used, even if only
classes are allowed in namespaces. Look at this example:
$x = $y?a:b::c();
The above can be parsed either as the first argument being "the result
of method c of class b in namespace a" or the first argument being "t
quot;l0t3k"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> ""Jessie Hernandez"" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > 2) How will symbols be resolved inside namespaces? If a class "
causes ambiguity. The separator is now in a #define, so if worst
comes to worst and ":::" cannot be used/is not desired, then the change to
"\" will be easy.
I'll post any additional issues as I encounter them.
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Oliver Grätz wrote:
Jessie Hernandez schrieb:
Please explain what you mean.
Didn't you get my mail? OK, I'll put it in here:
-
I already brought this up once: How difficult is it to introduce an
option to php.ini whi
Hi Oliver,
"Oliver Grätz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jessie Hernandez schrieb:
> > In this case the FOO define will be used. When you do a namespace
import,
> > you can really only use classes without the namespace prefix (s
Hello Bob,
""Bob Silva"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Looking for some feedback on what the expected behavior should be for
class
> and/or constant ambiguity within namespaces. For instance:
>
>
>
> Classes.php:
>
>
>
> namespace A {
>
> const FOO = 123;
>
>
is is outside the scope of what I want to accomplish.
Regards,
Jessie
""Matthias Pigulla"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Von: Jessie Hernandez
> So, the question is, can we scrap both namespace constants
> and namespace functions and
ms with
> > implementation... thanks for an explanation.
>
> > Bob
>
> > -Original Message-
> > From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> > Sent: Monday, November 28, 2005 12:26 PM
> > To: Jessie Hernandez
> > Cc: internals@lists.p
t want private and/or protected classes
> within a namespace? I imagine it would be due to problems with
> implementation... thanks for an explanation.
>
> Bob
>
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 28, 200
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
--
PH
Marcus,
In my patch, you can define the class as "private" inside the namespace, so
it could only be derived by classes inside the same namespace
(using/instantiating outside will trigger an error). This might solve your
problem.
Regards,
Jessie
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in m
Hi Dmitry,
Can you send/post your patch? I'm especially interested in seeing what you
did in zend_language_parser.y. Thanks.
Regards,
Jessie
""Dmitry Stogov"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Marcus,
>
> It worked. :)
> Even with nested classes.
>
> However it
Hello Marcus,
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Stanislav,
>
> easy changing of behavior in classes of a namespace by only changing one
> value for instance.
>
> namespace Foo
> {
>const XYZ = 42;
>
>class Bar
>{
> const =
Stas,
I agree that namespace constants are not needed, and are even problematic.
If I import a namespace that is divided among several files and I use a
constant from that namespace, __autoload won't let me find, and I won't know
where it is either. It's better to have a "Config" class under the n
; the complete vision of where PHP is heading either. I also do not think
that
> "internal prefixing" is the most elegant or right solution.
>
> I don't see that a patch will ever be accepted if we don't have agreement
of
> what namespaces should do and not do.
>
Dmitry,
Can you send me the patch (or alternatively, where can I get it)? I'd like
to see how you did this.
My problem with "::" is that you can't distinguish between calling a
function in a namespace and calling a static method, e.g.:
a::b()
This can mean either "call static method b of class
Hi Sara,
Sara Golemon wrote:
For the record, I vote for :::
T_מְשֻׁלָּשׁ_NEKUDOTAYIM
(Sorry, couldn't find a transliteration of "triple")
-Sara
I'll call it T_JESSIEYIM_NEKUDONAMESPACE ;-) !
Regards,
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
I have to
work on some minor details of the patch, which are more important than
this (I put the namespace separator in a #define, so it can easily be
changed in the future).
Regards,
Jessie
Jessie Hernandez wrote:
Great work, Oliver! I personally also add a +1 for ":", with the
|-| | +0 | +0 | +0 | +0 | | +0 | +0 | +1 |
+1 | +0 | +0 | | | | |
Jessie Hernandez |-| +1 | | +2 | | | | | | |
| | | | | | |
Matt Friedman|-| | | -1 | |
net/manual/en/language.operators.php:
"The third group is the ternary operator: ?:. It should be used to
select between two expressions depending on a third one, rather than to
select two sentences or paths of execution. Surrounding ternary
expressions with parentheses is a very good idea."
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marcus Boerger wrote:
Hello Matt,
bla!
LOL!
--
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Mat,
Matt Friedman wrote:
Hi, I've been following your conversations all day and think I might
have a nice idea for the namespace separator idea. Sorry to barge in
on your conversation but I think the following has value.
What about something like <- or <:: or even just <:
It makes sense to
I personally don't like any of these, but I just thought of this one:
"%%". Don't think it'll cause any problems at all, and look at the code:
What do you think? ":::" is more intuitive for me, but "%%" is an
acceptable alternative...
Regards,
Jessie
Greg Beaver wrote:
Hi all,
I have
Oops, hit "send" too soon! As you saw, ":-" cannot be used, but ":>"
looks like a possibility. Does anyone see anything wrong with this
sequence? Personally, I'd prefer ":::", as ":>" looks weird, but then
again, it's less typing.
I'll put in whatever sequence is most accepted, except of cours
Hi Oliver,
Oliver Grätz wrote:
Ilia Alshanetsky schrieb:
I'd prefer ::: over \ for a namespace operator, even though it is
bordering on the "too-long" limit.
What about these:
PEAR:>Date
PEAR:-Date
OLLi
I thought of these, but it'll break the following examples:
echo ( ( time() % 2
t;call static method c of class b under namespace a".
Since this cannot be determined, "::" cannot be used.
Regards,
Jessie
Jessie Hernandez wrote:
All,
What would you say if I managed to solve this problem, but that the
solution entailed changing the namespace separator to &
All,
What would you say if I managed to solve this problem, but that the
solution entailed changing the namespace separator to ":::"? The code
below works fine locally.
Is ":::" unacceptable? Personally, I think anything is better than using
"\", and ":::" is not bad for me. If not, which ch
Hi Chris,
Christian Schneider wrote:
From Jessie's statements I was assuming that ONLY in the ternary case
you would need whitespaces/parens to disambiguate the expression. That
would break way less PHP scripts than, say, a core Date class ;-)
Yes, this is true, but still, I wouldn't be
Hello Oliver,
Oliver Grätz wrote:
If I read Jessie correctly, the parser will throw an error now if the
usage is unclear with the ternary (a:b:c:d). So the real problem is when
namespace constants are not used but the parser thinks that he's reading
some:
$a = ($b)? c:d;
Are c and d constants
Sorry for the double posts, Thunderbird's been acting weird lately...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Greg Beaver wrote:
Jessie Hernandez wrote:
1) Do not allow constants in namespaces, just stick to functions and
classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also
Greg Beaver wrote:
Jessie Hernandez wrote:
1) Do not allow constants in namespaces, just stick to functions and
classes.
I am confused as to why we need namespaced constants. Now that we have
class constants, this is a far better way to "namespace" constants. I
was also
Bob Silva wrote:
$x = $y ? foo:bar:baz:stupid;
I think "stupid" is the key word here, by forcing the whitespace or (), you
are making the language itself stupid by not knowing how to parse itself.
I'm not a core developer, but I am pretty sure that this implementation will
never be accepted, s
Hi Oliver,
Oliver Grätz wrote:
So if one only allows simple namespaces (no nesting), then one can see
that this need to be two namespace constants BUT one has to read the
whole line:
- one colon means simple constants
- three colons: two namespaces constants
- two colons: ERROR, undefined
If
Hello Oliver,
Oliver Grätz wrote:
Marcus Boerger schrieb:
Hello Jessie,
that's only one case,go with consts. now try
$x = $y ? foo:bar:baz:stupid;
That's nonsense. If I as a programmer cannot comprehend what it should
mean by looking at it then I shouldn't expect that from the language.
T
I already use this approach at work, anyways).
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Gareth,
Gareth Ardron wrote:
Majority asking for namespaces != majority of php users.
How do you know? Have you conducted a poll?
Regards,
Jessie
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Chris,
Christian Schneider wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
- Chris
I completely agree, and as I said before, I suspect the majority who are
asking for n
Hi Sara,
Sara Golemon wrote:
Forcing whitespace here isn't an option. It is completely
inconsistent with the rest of PHP.
It's also a conversation that was had before PHP5.0 was ever released
(when namespaces were first being attempted).
Anyone remember the term "syntactic sugar"?
You ma
Rasmus Lerdorf wrote:
$x = $y ? foo:bar : baz:stupid;
Forcing whitespace here isn't an option. It is completely inconsistent
with the rest of PHP.
-Rasmus
This is only one isolated case, though, and even then, it only happens
with constants (classes don't work anyways here and don't
Hi Marcus,
Marcus Boerger wrote:
Hello Jessie,
that's only one case,go with consts. now try
$x = $y ? foo:bar:baz:stupid;
now what?
best regards
marcus
Here it'll fail. My patch is basically allowing colons inside the
class/function/constant name, so whitespace here is _crucial_, i.e.,
Rasmus Lerdorf wrote:
Are you saying this works?
namespace ns {
function foo() { }
}
function foo() {}
echo true ? ns:foo():foo();
Looks very confusing to me.
-Rasmus
Just tested that, and yes, it does work. If you think about it though,
this is excellent. A function foo() in my names
Hello Rasmus,
Rasmus Lerdorf wrote:
Jessie Hernandez wrote:
Why is "\" the only available character? Right now my patch is using
":" and it's working great (though against 5.1). Is ":" used in some
other way in PHP 6?
It clashes with the : in the ter
Hello Marcus,
Marcus Boerger wrote:
Guys it is sensless to discuss the namespace separator. The only possibility
is \ and that's not because anybody at some meeting liked it. It is the only
character that is freely available as in not conflicting with anything we
have right now and still availab
Bob Silva wrote:
That follows my sentiment, I think namespace implementation should be
fast-tracked before a PHP 6 release to give developers time to modify/adjust
their code to work with core object classes.
This is what I hope for. My current patch is based on the current
release of PHP 5.1
Marcus,
I have good news on this (I added both constants and function support!).
I will post the patch soon. There are still a few things that need to
be discussed, but right now the functionality is a huge step forward.
Best regards,
Jessie
Marcus Boerger wrote:
Hello Helgi,
obvious
Marcus,
I agree that we should work together on this, so that we can achieve the
best result possible and to avoid duplicate work. To a certain degree,
we have already worked together on this, when you suggested using the
__autoload mechanism to resolve namespace imports and this is what I
en
it in a
5.2 release, for example. Or will there be no more minor releases until 6?
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
lems.
Obviously, I don't agree on having to wait that long, but if that is the
case, I'll check what changes I need to do in order to apply it to PHP
6. Thanks for the clarification.
Regards,
Jessie Hernandez
Rasmus Lerdorf wrote:
Jessie Hernandez wrote:
I saw the notes regar
patch", then please email me or post your
questions to the list, and I'll be more than happy to explain.
Regards,
Jessie Hernandez
Derick Rethans wrote:
Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP
.
__construct
__toString
append
clear
contains
empty
indexOf
length
makeCopy
reserve
startsWith
toLowerCase
toUpperCase
trim
Regards,
Jessie Hernandez
""Bob Silva"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Jessie,
>
> I'd be more than
Hi Bob,
BTW, several months back I started working on a similar String class (you
can see my post at http://news.php.net/php.pecl.dev/2512). It was meant as
an OOP interface to all of the string-handling functions, and also had
smart buffer management for speed. I started working on this hoping to
Hi Kevin,
Kevin Newman wrote:
> Thank you for the info.
>
> I have some questions/suggestions (they may be silly - please feel
> welcome to tell me so, if they are):
>
> You have solved the problem (grievance number 5) of file based scoping,
> by introducing a function that can only be used wit
against a 5.1 CVS version some months ago,
maybe it doesn't apply cleanly anymore, haven't tried).
Regards,
Jessie Hernandez
Kevin Newman wrote:
> Hello,
>
> I have been trying to compile PHP with the namespaces patch, but have
> been completely unable to find the
I agree with Edin. To be consistent, either all interfaces and classes
should be prefixed or none should be prefixed. On the other hand, prefixing
all the old classes/interfaces will cause BC breaks.
This is one case where namespaces are useful. With my namespace patch, all
that would have to be
Hi Kevin,
I posted a patch very recently (1-2 months ago) that implements namespace
support. You can search this list and download the patch if you want to
check it out (I can also repost if necessary). Just to make sure you find
the latest one, it's in a "Beta 2" thread. It was also posted in a r
t; > only use it as above? Imports would only work for classes, and the only
>> > change would be that you can reference functions with a colon (of
>> > course, just like classes, you cannot declare a function name with a
>> > colon, only r
Hi Ilia,
While it really doesn't matter to me if functions are namespaced or not, or
even if functions are allowed inside namespaces, I just want to clarify
that only one hash table lookup would be done (as I said in my previous
post, this change was very simple, but all it did was allow the use o
David,
Don't know if you read my post from last night, but I played around with
functions in namespaces and they worked (the change was pretty easy). Though
all this allowed was the following:
So, for your string example, all this would buy is that you'd call
str:replace instead of str_replace
working great as it is,
and I suspect the majority of the users who want namespaces is to simply
group/organize their classes anyways.
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
now has. The files used by the tests have not changed, so
tests.tar.gz from the first post in this thread can still be used.
Regards,
Jessie
Jessie Hernandez wrote:
> Classes that had uppercase letters were not being handled properly in
> namespace imports. The attached patch has th
I am not familiar with PIMP, but I would not get it in 6.0 until we have
HOES (HTML Output Extension Server) complete. Then we can start on the
client(s) for 6.1 :-).
--
Jessie
"David Zülke" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > 6.0 - to define, for now we have two c
Classes that had uppercase letters were not being handled properly in
namespace imports. The attached patch has this fix (thanks Maxx!). Also,
the attached patch includes the default behavior of resolving
simple-imported class names to their file paths (ns:class1 being looked up
as ns/class1(.inc o
I was made aware of the fact that the patch wasn't compiling in ZTS mode, so
I fixed this in the attached patch (I still have not gotten a chance to
test under Windows, but it does work on Linux, both in ZTS and non-ZTS
mode). Other than that, there are no other changes.
Regards,
Jessie
Index: Z
Same as before, with the following changes:
- Fixed memory leaks.
- Added __NAMESPACE__ constant.
Regards,
Jessie HernandezIndex: Zend/zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.306
diff -u -r1.306
Yep, it's that simple! You can even import it and it'll work! In
zend_lookup_class, the standard class_table search is done first, but on
failure, before it calls __autoload, the class name will try to be
"resolved" using the import table for the executing file. If a matching
entry in the import ta
rectories), then maybe a default
> > implementation can be provided in SPL's autoload. That way, namespace
> > imports can be used "out of the box".
>
> > Marcus, what do you think?
>
>
> > Regards,
>
> > Jessie Hernandez
>
>
>
>
> Best regards,
> Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Michael,
Yes, I am aware of this. Underscores were used due to the lack of
namespaces. For user classes which use namespaces (and in the case where
some PEAR classes get modified to be under namespaces), the colon would be
used as the separator, and this would get replaced by the slash to form
imports can be used "out of the box".
Marcus, what do you think?
Regards,
Jessie Hernandez
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"John LeSueur" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >
> so, if I understand correctly, if your __autoload is defined in a
> different file(file1) from where the import was
> called(file2), then get_imported_namespaces() returns the namespace
> imports for file1.
> get_impo
me know if you have any questions on the attached patch.
Best regards,
Jessie Hernandez
? tests.tar.gz
Index: Zend/zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.306
diff -u -r1.306 zend.c
--- Zen
Hello Alex,
"Alex Kiesel" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> import $this is just something I'd expect PHP to be able to deal with -
> but I could live without it.
>
I never meant to implement this, and I also agree with Marcus that there's
no reason to allow it.
> B
1 - 100 of 120 matches
Mail list logo
