Hi,
public function foo()
{
$bar= new Bar;
[...]
}
When I want to test the foo() method, I want to stub out the usage of
the Bar class, for example, and have Bar::doSomething() return a
pre-configured value instead of performing its normal operation.
This is where you'd star
Johannes Schlüter wrote:
> The only need I see is mocking objects for a unit test. This is usually
> done on a test system so installing such an extension shouldn't be to
> hard (especially for somebody who is able to do unit tests using mock
> objects...)
This is unnecessary in a well-designed p
For an extension, which the current implementation is, using the
register function is the best approach I see. Else we would have to to
I would prefer some special function to new handler. This feature has
very narrow use (I still not entirely convinced it even belongs to core
- it's too kludg
Hi,
On Tue, 2007-10-02 at 15:54 +0200, Sebastian Bergmann wrote:
> Guilherme Blanco schrieb:
> > Altho I found this idea really interesting, I have a suggestion for
> > it. Instead of use a function to handle new overloads, I suggest a
> > magic method, something like __new.
>
> __new() was what
Hello Arne,
yep, those are the tricky parts. I would pea for having final respected.
For private we need to investigate further.
marcus
Wednesday, October 3, 2007, 4:21:40 PM, you wrote:
> On Wed, 2007-10-03 at 07:24 +0200, Sebastian Bergmann wrote:
>> Stanislav Malyshev schrieb:
>> > Thanks,
Hello Stanislav,
new Foo will still return a Foo instance!
marcus
Wednesday, October 3, 2007, 12:00:12 AM, you wrote:
>> Problem is the cost of setting up these, by registering implementations,
>> performing reflection and so on is expensive especially considering the
>> stateless nature of P
Sebastian Bergmann schrieb:
>> would it be possible to overload final classes?
> Of course. We are not changing the class declaration (compile-time) but
> intercept the object creation (run-time).
I may have been unclear here: a class may pose for a class that contains
final methods. The posing
On Wed, 2007-10-03 at 07:24 +0200, Sebastian Bergmann wrote:
> Stanislav Malyshev schrieb:
> > Thanks, will look at these. I'm extremely uncomfortable with engine
> > change that would allow "new Foo" produce an object that is not Foo.
>
> The restriction
>
>"A class may only pose as one of
Stanislav Malyshev schrieb:
> lot of implications what have unintended - i.e. how typehints are
> supposed to work with this? How reflection and autoloading would work?
Typehints continue working because of the restriction that applies to
this mechanism (see other mail(s)).
Reflection{Class|Ob
David Zülke schrieb:
> would it be possible to overload final classes?
Of course. We are not changing the class declaration (compile-time) but
intercept the object creation (run-time).
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B1
Stanislav Malyshev schrieb:
> Thanks, will look at these. I'm extremely uncomfortable with engine
> change that would allow "new Foo" produce an object that is not Foo.
The restriction
"A class may only pose as one of its direct or indirect superclasses."
I mentioned ensures that "new Foo"
Jared Williams schrieb:
> I think they end up using the dependency injection pattern.
Of course you can argue that the code was badly {designed|written} in
the example I showed and should be refactored before testing. More often
than not, though, you cannot do this (3rd party code, for example
Problem is the cost of setting up these, by registering implementations,
performing reflection and so on is expensive especially considering the
stateless nature of PHP.
Thanks, will look at these. I'm extremely uncomfortable with engine
change that would allow "new Foo" produce an object that
October 2007 21:21
> To: Sebastian Bergmann
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Class Posing
>
> > Stubs / Mock Objects !== Unit Tests. Class Posing allows
> for better
> > stubs / mock objects which in turn are tools to write better unit
> &g
Stubs / Mock Objects !== Unit Tests. Class Posing allows for better
stubs / mock objects which in turn are tools to write better unit
tests.
OK, I see that. The question is - does any of the known unit test
systems use mock objects? Does it do that in the language that doesn't
allow "new Fo
Stanislav Malyshev schrieb:
> As far as I know, Java has unit tests but doesn't allow replacing
> classes. How does it work in Java?
Stubs / Mock Objects !== Unit Tests. Class Posing allows for better
stubs / mock objects which in turn are tools to write better unit
tests.
--
Sebastian Bergma
Like I said before, the factory and singleton patterns are just example
applications of this mechanism.
Right, but I'd like to see why we *need* it - i.e. what it allows to do
that other things don't. I'm afraid that we might have a case of
featuritis here (not meaning this specific proposal
Stanislav Malyshev schrieb:
> This looks like factory pattern. What's wrong with implementing it as
> factory?
Like I said before, the factory and singleton patterns are just example
applications of this mechanism.
What I want to use them for in PHPUnit is improving the Mock Objects
system.
Earlier this year, Johannes implemented class posing for PHP as follows:
This looks like factory pattern. What's wrong with implementing it as
factory?
However, to make this a viable mechanism that can be used in tools such
as PHPUnit (for which I could really use this functionality)
Ideally think I'd prefer it finer grained...
interface A
{
}
class AImpl implements A
{
}
register('A', function() { return new AImpl(); });
register('Foo', function() { return new Bar(); });
$foo = new Foo();
$a = new A();
Would also require fun
Richard Quadling schrieb:
> You're code looks like a factory. Is that your intention? Maybe
> __factory would be a more obvious name?
The application of this mechanism is not limited to implementing
factories and singletons.
--
Sebastian Bergmann http://sebastian-bergm
Guilherme Blanco schrieb:
> Altho I found this idea really interesting, I have a suggestion for
> it. Instead of use a function to handle new overloads, I suggest a
> magic method, something like __new.
__new() was what I initially proposed to Johannes but IIRC there were
some performance implic
On 02/10/2007, David Zülke <[EMAIL PROTECTED]> wrote:
> would it be possible to overload final classes?
>
> - David
>
>
> Am 02.10.2007 um 11:32 schrieb Sebastian Bergmann:
>
> > From [1]:
> >
> >Objective-C permits a class to wholly replace another class
> > within a
> >program. The repla
would it be possible to overload final classes?
- David
Am 02.10.2007 um 11:32 schrieb Sebastian Bergmann:
From [1]:
Objective-C permits a class to wholly replace another class
within a
program. The replacing class is said to "pose as" the target class.
All messages sent to the
Hi Sebastian and PHP list,
That's a very interesting idea and I'd use it too. Yesterday night I
was developing a set of classes that it could apply this idea too.
Altho I found this idea really interesting, I have a suggestion for
it. Instead of use a function to handle new overloads, I suggest
25 matches
Mail list logo
