> I think that would require an RFC.
Alright, thanks.
> To clarify, you're proposing to replace this:
>count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) == true
>with
>(new ReflectionClass(Beep::class))->hasAttribute(Ignore::class)
> Right?
Correct.
> That doesn't seem lik
>
> I think that would require an RFC.
>
> To clarify, you're proposing to replace this:
>
> count((new ReflectionClass(Beep::class))->getAttributes(Ignore::class)) ==
> true
>
> with
>
> (new ReflectionClass(Beep::class))->hasAttribute(Ignore::class)
>
> Right? That doesn't seem like a huge impro
On Wed, Jul 12, 2023, at 3:25 AM, Robin Chalas wrote:
> Hi internals,
>
> It is common attributes to be used as markers. Just like a marker
> interface with no methods, such attributes don’t have any parameter.
>
> Examples from Symfony:
> - #[Ignore] indicating that a property should be skipped i
I have just merged the PR with the amended Reflection changes:
https://github.com/php/php-src/commit/6039c07a3afd64a42c9b9f1ed994ca971db67a1e
Best regards,
George P. Banyard
Hi George,
> https://github.com/php/php-src/pull/7546#discussion_r837900447
Thanks for asking (even if voted).
On Tue, Apr 5, 2022 at 2:01 PM Marco Pivetta wrote:
> Probably best with consistency?
>
> > - Ignore the Reflection changes of the RFC and align the union type with
> the current beh
Probably best with consistency?
> - Ignore the Reflection changes of the RFC and align the union type with
the current behaviour
This one, specifically.
I'd love to see all nullable types become
`ReflectionUnionType(ReflectionNamedType($t), ReflectionNamedType(null))`,
but that would be a BC br
>> >
>> > Obviously, the `\0` is horrible and can probably be improved: depends on
>> > whether the API is intended for human or machine consumption. If it is
>> > machine consumption, strings are the wrong approach anyway.
>>
>> Machine or human?
>> One goal is that these names can be used as arra
See http://php.net/manual/en/language.namespaces.rules.php
What you mean is a "qualified name" so it would be a QN.
On 11 December 2017 at 10:28, Marco Pivetta wrote:
> Weird, that looks wrong to me, so I may be wrong here.
>
> When receiving a string containing a symbol, the only sensible appro
Weird, that looks wrong to me, so I may be wrong here.
When receiving a string containing a symbol, the only sensible approach is
to consider it a FQN, as no context is provided with the string.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
On Mon, Dec 11, 2017 at 10:23
On 11 December 2017 at 10:16, Marco Pivetta wrote:
> On Mon, Dec 11, 2017 at 10:03 AM, Andreas Hennings
> wrote:
>>
>> On 11 December 2017 at 09:16, Marco Pivetta wrote:
>> > If you really want to expose a symbol's FQN,
>>
>> Just to clarify: For me, "FQN" means "fully-qualified name", which
>>
On 11 December 2017 at 08:58, Marco Pivetta wrote:
> What's the use-case for creating a userland `ReflectionType` instance,
> besides mocking the reflection API itself?
> Consider that the subclassing in userland already provides an easy way to
> perform these operations (although ugly):
> https:/
On Mon, Dec 11, 2017 at 10:03 AM, Andreas Hennings
wrote:
> On 11 December 2017 at 09:16, Marco Pivetta wrote:
> > If you really want to expose a symbol's FQN,
>
> Just to clarify: For me, "FQN" means "fully-qualified name", which
> begins with "\\".
> This is specifically not what I propose her
On 11 December 2017 at 09:16, Marco Pivetta wrote:
> If you really want to expose a symbol's FQN,
Just to clarify: For me, "FQN" means "fully-qualified name", which
begins with "\\".
This is specifically not what I propose here. I want the name without
the leading namespace separator.
So maybe "g
If you really want to expose a symbol's FQN, I suggest exposing the
internal name as per `(array)` cast semantics.
namespace A {
class B {
public $c;
private $d;
private $e;
}
}
That would be:
"A\B#\$c"
"A\B#\0*\0\$d"
"A\B#\0A\\B\0\$e"
Obviously, the `\0` is horr
What's the use-case for creating a userland `ReflectionType` instance,
besides mocking the reflection API itself?
Consider that the subclassing in userland already provides an easy way to
perform these operations (although ugly):
https://github.com/Roave/BetterReflection/blob/2.0.1/src/Reflection/A
On 10/11/2016 07:27 AM, Stanislav Malyshev wrote:
I hope it's string(3) otherwise we have a bug on our
hands
That was a copy/pasta/no-adapt mistake, my bad.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> printed
>
> string(4) "?int"
> string(3) "int"
>
> and now it prints
>
> string(4) "int"
I hope it's string(3) otherwise we have a bug on our
hands
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php
Sebastian Bergmann schrieb am So., 9. Okt. 2016, 08:56:
> At some point in time during the development of PHP 7.1 this code
>
> function f(?int $x)
> {
> }
>
> $f = new ReflectionFunction('f');
>
> var_dump((string) $f->getParameters()[0]->getType());
> var_dump($f->getParameters()[0]
I have updated the section on Reflection to explain some of the design
decisions: https://wiki.php.net/rfc/returntypehinting#reflection;
hopefully that will help you and others to understand the rationale.
Please let me know if you have follow-up questions.
--
PHP Internals - PHP Runtime Developm
Hi Chris,
On 20.10.14 12:10, Chris Wright wrote:
[...] in depth summary of future idea ReflectionType
Thanks a lot for the clarification and regarding the future expansion of
the use of ReflectionType I now better understand most points and why
they're currently are that way.
I don't think I've
Markus
On 19 October 2014 20:31, Markus Fischer wrote:
> On 16.10.14 06:39, Levi Morrison wrote:
>> - The design and accompanying section of reflection[3] has been
>> rewritten entirely.
>>
>> [3]: https://wiki.php.net/rfc/returntypehinting#reflection
>
> I've some comments about the Reflecti
On Tue, Aug 12, 2014 at 8:52 PM, Stas Malyshev wrote:
> Hi!
>
>> I've just been looking back at the history of this previous conversation...
>>
>> http://marc.info/?l=php-internals&m=132673741606531&w=2
>>
>> as a mockist tester I'd really REALLY like to see this be possible but I
>> can see the p
Hi!
> I've just been looking back at the history of this previous conversation...
>
> http://marc.info/?l=php-internals&m=132673741606531&w=2
>
> as a mockist tester I'd really REALLY like to see this be possible but I
> can see the problem with the original patch modifying the actual existing
>
On 11 August 2014 18:44, Chris Wright wrote:
> I don't think that it even makes sense to have this as a possibility
> for internal classes.
>
Even leaving everything else outside, I think internal classes should
become less magic and more transparent over time.
The current "fixing" of internal c
On 11 August 2014 17:09, Julien Pauli wrote:
> On Mon, Aug 11, 2014 at 12:59 PM, Ferenc Kovacs wrote:
>> On Sat, Aug 9, 2014 at 12:35 PM, Tom Oram wrote:
>>
>>> I've just been looking back at the history of this previous conversation...
>>>
>>> http://marc.info/?l=php-internals&m=132673741606531
On Mon, Aug 11, 2014 at 12:59 PM, Ferenc Kovacs wrote:
> On Sat, Aug 9, 2014 at 12:35 PM, Tom Oram wrote:
>
>> I've just been looking back at the history of this previous conversation...
>>
>> http://marc.info/?l=php-internals&m=132673741606531&w=2
>>
>> as a mockist tester I'd really REALLY like
On Sat, Aug 9, 2014 at 12:35 PM, Tom Oram wrote:
> I've just been looking back at the history of this previous conversation...
>
> http://marc.info/?l=php-internals&m=132673741606531&w=2
>
> as a mockist tester I'd really REALLY like to see this be possible but I
> can see the problem with the or
On 11 August 2014 11:30, Chris Wright wrote:
> Hi Tom
>
> On 9 August 2014 11:35, Tom Oram wrote:
>> I've just been looking back at the history of this previous conversation...
>>
>> http://marc.info/?l=php-internals&m=132673741606531&w=2
>>
>> as a mockist tester I'd really REALLY like to see th
Hi Tom,
On 9 August 2014 12:35, Tom Oram wrote:
> Thoughts?
>
Possible? Probably, yes.
I'd actually argue that it may not be a good solution: it seems to me that
if you have to resort to this kind of mocking, then someone type-hinted
against a concrete implementation, which is a smell. Shouldn
Hi Tom
On 9 August 2014 11:35, Tom Oram wrote:
> I've just been looking back at the history of this previous conversation...
>
> http://marc.info/?l=php-internals&m=132673741606531&w=2
>
> as a mockist tester I'd really REALLY like to see this be possible but I
> can see the problem with the orig
I've just been looking back at the history of this previous conversation...
http://marc.info/?l=php-internals&m=132673741606531&w=2
as a mockist tester I'd really REALLY like to see this be possible but I
can see the problem with the original patch modifying the actual existing
class.
One soluti
to make sure I got my point across on
why it'd be useful)
Software Developer
Nathan Bruer
-Original Message-
From: Alexander Lissachenko [mailto:lisachenko...@gmail.com]
Sent: Monday, January 14, 2013 2:16 PM
To: Sebastian Krebs
Cc: PHP internals list
Subject: Re: [PHP-DEV] [Reflection
Probably, it will be better to give a link to the one of examples of
AOP integration for laravel framework (requires 5.4.10 to work):
https://github.com/lisachenko/laravel-aspect (just clone, install
dependencies and look at result)
I need to perform weaving of aspects into the original methods, s
I do not use static methods, frameworks and applications use them )).
I just want to extend logic of class methods in the application with
custom behavior (Logging, Caching) and preserve original scope. It's
already done for PHP 5.4 with closures and my library works well with
any PHP framework. F
2013/1/14 Alexander Lissachenko
> My use-case is weaving aspects into the methods. Yeah! )
>
> So, I take the original class, rename it and then create a decorator
> class instead of original class with overridden dynamic and static
> methods. Method in the decorator should make some specific log
Alexander,
So, I take the original class, rename it and then create a decorator
> class instead of original class with overridden dynamic and static
> methods. Method in the decorator should make some specific logic and
> then just invokes the original static method with Reflection, but the
> scop
My use-case is weaving aspects into the methods. Yeah! )
So, I take the original class, rename it and then create a decorator
class instead of original class with overridden dynamic and static
methods. Method in the decorator should make some specific logic and
then just invokes the original stati
2013/1/14 Alexander Lissachenko
> Hi! It's my first letter here )
>
> I want to suggest a small improvement for ReflectionMethod->invoke()
> and ReflectionMethod->invokeArgs() methods to support LSB for
> overridden static methods. Currently, for invoking static methods
> first argument should be
On Wed, 18 Jan 2012 00:00:09 +0100, Jan Dolecek wrote:
This issue seems much more complicated than I thought. We'll need to
consider all cases which could cause troubles and have a solution for
them.
Namely:
- rewriting permanent structures for internal classes, which are
being kept between r
This issue seems much more complicated than I thought. We'll need to
consider all cases which could cause troubles and have a solution for
them.
Namely:
- rewriting permanent structures for internal classes, which are
being kept between requests, must be avoided
- races in threading models
- re
Hi!
This doesn't seem right. Correct me if I'm wrong: for internal classes,
their data structures are allocated permanently, so I'd say the effects of
removing the flag would be permanent (i.e., would affect subsequent
requests). And for threaded builds this could cause races between the
thread
On Mon, 16 Jan 2012 19:06:31 +0100, Jan Dolecek wrote:
Hi,
reflection is a great tool for testing, but it still misses support
for mocking classes/methods marked as final. I created a small patch
https://gist.github.com/1621839#file_php_finals.patch, examples how to
use it https://gist.github.
As it is not that bad for trunk, I think we should wait a bit before
commiting this patch, there are still need for discussions and we
should give some time to other people to comment the feature (the
implementation is trivial as this stage). Sebastian, mind to revert it
until we are done with the
Sebastian, thanks for the commit. But actually as I see the tests, I
may have not specified it enough:
ReflectionClass::setFinal(false) removes the final from the class, not
it's methods.
This test case
http://svn.php.net/viewvc/php/php-src/trunk/ext/reflection/tests/ReflectionClass_setFinal.phpt
> Why did you choose to make the argument to setFinal() optional?
> setAccessible() doesn't do this.
To be honest I didn't check the setAccessible method first. It just
seemed natural to me, that $refl->setFinal() makes it final even
without true as an argument.
Jan Dolecek
juzna...@gmail.com
--
On Mon, Jan 16, 2012 at 7:06 PM, Jan Dolecek wrote:
> Hi,
>
> reflection is a great tool for testing, but it still misses support
> for mocking classes/methods marked as final. I created a small patch
> https://gist.github.com/1621839#file_php_finals.patch, examples how to
> use it https://gist.gi
Yes, there always is a reason. But when we test and create mocks, this
reasons can go aside. This is the same with
ReflectionProperty::setAccessible() etc.
They shouldn't be used normally, but in special cases like testing
it's necessary.
Jan Dolecek
juzna...@gmail.com
On Tue, Jan 17, 2012 at 2
>
> if a class is marked as final, there must be some reason for it to be a
> final.
>
> if you remove the final and extends it, may lead to bad error.
>
>
reflection should always be used with care.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Jan 17, 2012 at 6:22 PM, Sebastian Bergmann wrote:
> Am 16.01.2012 19:06, schrieb Jan Dolecek:
>> reflection is a great tool for testing, but it still misses support
>> for mocking classes/methods marked as final. I created a small patch
>> https://gist.github.com/1621839#file_php_finals.p
setFinal is available for both classes and methods, as shown in
example in my gist
(https://gist.github.com/1621839#file_final_test.php). This should be
enough for all possible mocks, as I discussed it with my friends.
It is also possible to remove final, create a mock class and then put
it back,
Am 17.01.2012 12:03, schrieb jpauli:
> The patch just adds setFinal() to ReflectionClass.
> What about ReflectionMethod?
From the patch
+/* {{{ proto public void ReflectionMethod::setFinal([bool isFinal = true])
+ Sets/unsets class as final */
+ZEND_METHOD(reflection_method, setFinal)
+/* {{{ p
Am 17.01.2012 12:00, schrieb jpauli:
> How didn't we think about that earlier... ?
I have had this on a TODO list at the back of my head for a long time;
at least since we added setAccessible().
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergm
Just one last word : The patch just adds setFinal() to ReflectionClass.
What about ReflectionMethod ? Not very usefull for the mocking purpose, but
that would be good for the Reflection API.
Julien
On Tue, Jan 17, 2012 at 12:00 PM, jpauli wrote:
> +1, I like the idea as well.
> How didn't we th
+1, I like the idea as well.
How didn't we think about that earlier... ?
Julien
On Tue, Jan 17, 2012 at 11:54 AM, Sebastian Bergmann wrote:
> Am 17.01.2012 11:34, schrieb Pierre Joye:
> > Patch looks good, but coding standard.
>
> If there are no objections, I can fix the CS issue and commit th
Am 17.01.2012 11:34, schrieb Pierre Joye:
> Patch looks good, but coding standard.
If there are no objections, I can fix the CS issue and commit the patch
to trunk.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
hi Jan!
Patch looks good, but coding standard.
Please always use brackets, even for one line condition (if () foo else bar).
Cheers,
On Mon, Jan 16, 2012 at 7:06 PM, Jan Dolecek wrote:
> Hi,
>
> reflection is a great tool for testing, but it still misses support
> for mocking classes/methods m
Am 16.01.2012 19:06, schrieb Jan Dolecek:
> reflection is a great tool for testing, but it still misses support
> for mocking classes/methods marked as final. I created a small patch
> https://gist.github.com/1621839#file_php_finals.patch, examples how to
> use it https://gist.github.com/1621839#fi
Hi:
On 09 Aug 2011, at 19:10, Joey Smith wrote:
> On Mon, Aug 08, 2011 at 03:52:37PM +0100, Keloran wrote:
>> There seems to be a bug in traits that if you use any of the GLOBAL vars it
>> segfaults
>
>
>
> I'm not sure it's clear from Keloran's code example here, so I thought I'd
> point
> ou
On Mon, Aug 08, 2011 at 03:52:37PM +0100, Keloran wrote:
> There seems to be a bug in traits that if you use any of the GLOBAL vars it
> segfaults
I'm not sure it's clear from Keloran's code example here, so I thought I'd point
out that the problem only seems to happen if you include the trait d
There seems to be a bug in traits that if you use any of the GLOBAL vars it
segfaults
e.g.
getStuff("tester");
}
}
that causes a segfault
change the trait to
wrote:
> On 07/25/2011 02:05 PM, Stefan Marr wrote:
> > Hi Johannes:
> >
> > 2011/7/25 Johannes Schlüter :
> >
> >> Now I use reflecti
On 07/25/2011 02:05 PM, Stefan Marr wrote:
> Hi Johannes:
>
> 2011/7/25 Johannes Schlüter :
>
>> Now I use reflection on this:
>>
>> $rc = new ReflectionClass('C');
>> print_r($rc->getTraitAliases());
>>
>> Array
>> (
>>[tc] => T1::t1
>> )
>
> Great, that is nice.
>
>
>> So far so nice but
Hi Johannes:
2011/7/25 Johannes Schlüter :
> Now I use reflection on this:
>
> $rc = new ReflectionClass('C');
> print_r($rc->getTraitAliases());
>
> Array
> (
> [tc] => T1::t1
> )
Great, that is nice.
> So far so nice but I'm missing the information where C::t1() is coming
> from. In the r
Hi Kalle,
> 3) Closures, theres alot of closure differences in HEAD and 5.3, for
> example HEAD has ReflectionMethod::getClosure() and
> ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it
> looks like a change in 5.3 that never occured to HEAD, unless that is
> the logic
Hi Jim,
you're searching for runkit ;-)
http://de.php.net/manual/en/ref.runkit.php
johannes
On Fri, 2007-02-09 at 10:18 -0600, Jim Wilson wrote:
> Dear PHP Internals subscribers,
>
> I have two quick questions regarding PHP 5's Reflection API (I apologize if
> this isn't the right list to ask):
Hi Sebastian
On 6/8/06, Sebastian Bergmann <[EMAIL PROTECTED]> wrote:
http://phpfi.com/122573
Looks like the arginfo patch broke it.., well, actually it uncovered a
bug in ext/reflection.
The messages are correct, ReflectionMethod::invokeArgs takes two
arguments but ReflectionFunction::invoke
Hi,
> hey cool stuff! Any chance you could publish this or make
> it a PEAR class or put it into the newly created Reflection
> extension as example?
http://sourceforge.net/projects/phpclassbrowser/
Its in CVS at sourceforge. (Still haven't gotten around to reading up on how to
create fil
Hello Jared,
hey cool stuff! Any chance you could publish this or make it a PEAR class
or put it into the newly created Reflection extension as example?
best regards
marcus
Wednesday, November 23, 2005, 12:50:25 PM, you wrote:
> Hi,
> This has been do-able in PHP5 for somewhile, (wrot
Hi,
This has been do-able in PHP5 for somewhile, (wrote a reflection
browser while ago to show such things)
http://www.ren.dotgeek.org/classbrowser/?class=DOMCdataSection
Jared
> Here's an idea for the maintainer of the Reflection API, to
> be able to view the class a method is define
Nope, sorry, I'll do my homework next time.
Bob
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 23, 2005 12:39 AM
> To: Bob Silva
> Cc: 'internals'
> Subject: Re: [PHP-DEV] Reflection API idea
>
&g
Hello Bob,
have you looked at head output of Reflection lately? I guess that contains
all you want, right?
marcus
Wednesday, November 23, 2005, 5:19:10 AM, you wrote:
> Here's an idea for the maintainer of the Reflection API, to be able to view
> the class a method is defined in (if not overr
Whoops, that memcmp should be a strcmp.
> -Original Message-
> From: Bob Silva [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 22, 2005 8:19 PM
> To: 'internals'
> Subject: [PHP-DEV] Reflection API idea
>
> Here's an idea for the maintainer of the Reflection API, to be able to
> view
Yes, but if you're not planning to have any module globals,
wouldn't it be better to just nuke the lines?
--Jani
On Fri, 18 Nov 2005, Marcus Boerger wrote:
Hello Rob,
we can define a dummy in it. I thought that some compilter don't like
empty structs.
marcus
Friday, November
Hello Rob,
we can define a dummy in it. I thought that some compilter don't like
empty structs.
marcus
Friday, November 18, 2005, 4:18:51 AM, you wrote:
> Marcus,
> are you going to be using any module globals in the extension?
> I had to remove the code for it to get it to build on windows
Hello Sebastian, hello Timm,
after all the differnece is whether we know of the typical PHP user can
find out.
marcus
p.s.: Timm you're going to FFM?
Tuesday, November 2, 2004, 11:45:18 PM, you wrote:
> Timm Friebe wrote:
>> Care to elaborate? Except for the call_user_func-syntax being longe
Timm Friebe wrote:
> Care to elaborate? Except for the call_user_func-syntax being longer I
> don't see any difference.
The difference is that with using a method of ReflectionFunction or
ReflectionMethod I do not have to switch paradigms (Reflection API and
OOP vs. call_user_func*() and non-OO
On Tue, 2004-11-02 at 13:52, Sebastian Bergmann wrote:
> Timm Friebe wrote:
> > Why was this added?
>
> I asked Marcus to add these.
He forgot to support invokeArgs(NULL, array(...)) for static invocation
("Warning: invokeArgs() expects parameter 1 to be object, null given").
[...call_user_func
Timm Friebe wrote:
> Why was this added?
I asked Marcus to add these.
> These:
>
> 1) call_user_func_array(
> array(new ReflectionMethod('class', 'method'), 'invoke',
> array(1, 2, 3)
>)
>
> 2) call_user_func(
> array(new ReflectionMethod('class', 'method'), 'invoke',
>
Timm Friebe wrote:
Can somebody commit this?
Done.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
At 09:33 AM 5/5/2004 +0200, Arjen Warendorff wrote:
The ReflectionParameter method "allowsNull()" doesn't seem to return
anything else then (bool)TRUE ??
Because today this still isn't supported (except for maybe in internal
functions).
Today all parameters allow NULL :)
Andi
--
PHP Internals - P
- Original Message -
From: "Arjen Warendorff" <[EMAIL PROTECTED]>
To: "'PHP Internals List'" <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 7:33 PM
Subject: [PHP-DEV] Reflection API : Feature request and question
> Hello,
>
> I have played around with the Reflection API, missed some f
I am in contact with Timm re: integrating his doc into the official manual.
S
Andi Gutmans wrote:
At 08:28 PM 4/3/2004 +0200, Timm Friebe wrote:
Have you contacted the doc guys to make the add this to the PHP manual?
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
At 08:28 PM 4/3/2004 +0200, Timm Friebe wrote:
On Sat, 2004-04-03 at 20:00, Jochem Maas wrote:
[...]
> Having read all the posts on studlyCaps on this list, and understanding
> that studlyCaps was the std. for all new OO APIs I found the following a
> little odd:
>
> The documentation at
> http://s
On Sat, 2004-04-03 at 20:00, Jochem Maas wrote:
[...]
> Having read all the posts on studlyCaps on this list, and understanding
> that studlyCaps was the std. for all new OO APIs I found the following a
> little odd:
>
> The documentation at
> http://sitten-polizei.de/php/reflection_api/docs/lan
> On Mon, 2003-12-22 at 16:05, Hans Lellelid wrote:
>> Hi -
>>
>> We're using the Reflection API in a project for which I'm lead
>> developer.
>> Seems to be something changed between beta-2 and beta-3. We're now
>> getting the following exception when calling getClass() on a class hint:
> [...]
>
On Mon, 2003-12-22 at 16:05, Hans Lellelid wrote:
> Hi -
>
> We're using the Reflection API in a project for which I'm lead developer.
> Seems to be something changed between beta-2 and beta-3. We're now
> getting the following exception when calling getClass() on a class hint:
[...]
Works fine
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2003 8:02 PM
> On Tue, 2 Dec 2003, George Schlossnagle wrote:
>
> >
> > On Dec 2, 2003, at 1:18 PM, Derick Rethans wrote:
> >
> > > On Tue, 2 Dec 2003, George Schlossnagle wrote:
> > >
> > >> I'd like to convert the r
On Tue, 2 Dec 2003, Christian Stocker wrote:
> > This raises my question of my the new Exception class uses CamelCaps instead
> > of underscores?
> >
> > For instance, its methods are: getMessage(), getCode(), etc.
> >
> > I don't think any other built-in method or packaged extension does this.
>
On 12/2/03 7:51 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 2 Dec 2003, George Schlossnagle wrote:
On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote:
George Schlossnagle wrote:
I'd like to convert the reflection API to the current php standard of
CamelCaps (instead of underscores) for i
On Tue, 2 Dec 2003, George Schlossnagle wrote:
>
> On Dec 2, 2003, at 1:18 PM, Derick Rethans wrote:
>
> > On Tue, 2 Dec 2003, George Schlossnagle wrote:
> >
> >> I'd like to convert the reflection API to the current php standard of
> >> CamelCaps (instead of underscores) for it's class and method
On Dec 2, 2003, at 1:51 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 2 Dec 2003, George Schlossnagle wrote:
On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote:
George Schlossnagle wrote:
I'd like to convert the reflection API to the current php standard
of
CamelCaps (instead of underscores)
On Tue, 2 Dec 2003, George Schlossnagle wrote:
> On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote:
>
> > George Schlossnagle wrote:
> >> I'd like to convert the reflection API to the current php standard of
> >> CamelCaps (instead of underscores) for it's class and method names.
> >
> > Why
On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote:
George Schlossnagle wrote:
I'd like to convert the reflection API to the current php standard of
CamelCaps (instead of underscores) for it's class and method names.
Why deviate from PEAR CS in this?
Well, as the classes are builtin's it's not
George Schlossnagle wrote:
> I'd like to convert the reflection API to the current php standard of
> CamelCaps (instead of underscores) for it's class and method names.
Why deviate from PEAR CS in this?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker
On Dec 2, 2003, at 1:18 PM, Derick Rethans wrote:
On Tue, 2 Dec 2003, George Schlossnagle wrote:
I'd like to convert the reflection API to the current php standard of
CamelCaps (instead of underscores) for it's class and method names.
Any objections?
yes
Care to elaborate?
George
--
PHP Interna
On Tue, 2 Dec 2003, George Schlossnagle wrote:
> I'd like to convert the reflection API to the current php standard of
> CamelCaps (instead of underscores) for it's class and method names.
> Any objections?
yes
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visi
Hello George,
Tuesday, December 2, 2003, 6:58:58 PM, you wrote:
> I'd like to convert the reflection API to the current php standard of
> CamelCaps (instead of underscores) for it's class and method names.
> Any objections?
No objections. Strong agreement.'
--
Best regards,
Marcus
having had a quick think about this, here some thoughts that may affect it.
What is the API going to be used for.
a) replacement for method_exists(), call_user_func() in code
.. which makes sense for the object methods...
b) quick testing of what an interface is - as in print_r() is quicker
than o
At 06:40 PM 3/7/2003 -0400, Jon Parise wrote:
On Thu, Jul 03, 2003 at 03:36:58PM +0200, moshe doron wrote:
> > It's not an annoyance - it's not my spec, I'm just implementing it.
> > I'm happy to change the code to work via properties instead, it's not a
> > major change. I would like to settle o
On Thu, Jul 03, 2003 at 03:36:58PM +0200, moshe doron wrote:
> > It's not an annoyance - it's not my spec, I'm just implementing it.
> > I'm happy to change the code to work via properties instead, it's not a
> > major change. I would like to settle on a concensus first.
>
> +1 (maybe both)?
On Wed, 02 Jul 2003, Andi Gutmans wrote:
> I've already said so, but I definitely prefer methods.
So do I. Overloading properties is a bit of magical powder that's
appropriate only in some cases.
-Andrei
* There is no knowledge that is not power. -- Ralph Waldo Emerson *
--
PHP Internals - PHP
1 - 100 of 135 matches
Mail list logo
