Date: 06/29/99
- Next message: Rasmus Lerdorf: "Re: [PHP-DEV] overloading JNI return values"
- Previous message: fredm <email protected>: "[PHP-DEV] Bug #1627: Opendir does not behave the same on Windows platform as on Unix(Linux)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Uhm, you haven't looked at the right place then. You'd be happy to know
that in PHP 4.0,
$word = new COM("word.application");
$word->visible = true;
...
works fine. Make sure you look at the PHP 4.0 COM.c and not the PHP 3.0
one. I don't pretend to say it's very easy to understand, but it
implements OO syntax overloading for COM objects.
By the way, if we hadn't already done so, answering your question - it's
VERY VERY hard to do it. Luckily, we already did :)
Zeev
At 16:08 29/06/99 , Brian Schaffner wrote:
>Zeev/Andi:
>
>I looked at the COM implementation. It appears to allow "programmatic
>scripting" of COM objects. What would it take to "inject" COM objects into
>the parser symbol table?
>
>I think it would be much cool to do:
>
> <?
> $x = new com::MyClass();
> $y = $x->MyMethod("testing");
> ?>
>
>rather than:
>
> <?
> $x = com_load("MyClass");
> $y = com_invoke($x, "MyMethod", "testing");
> ?>
>
>particularly because you could build an abstraction layer around the
>"exteral object" support. then, to call a java class, or a corba class, or a
>next-generation-object class, you don't need a whole new set of PHP methods,
>you just need a new "instantiation operator":
>
> $x = new corba::ComeCorbaObject();
> $x = new java::SomeJavaClass();
>
>I'm assuming that in the hash table, $x would still be an "Object", but
>perhaps it would have a "modifier" field to indicate that it is "external",
>and/or a field to indicate that it's a "COM" or "JAVA", or whatever. Then,
>the parser would need some hooks for calling instantiation, methods,
>properties, and deletes on objects. I'm not a parser geek, but I would think
>that in the "object" code, it could examine the object and determine if it's
>external, and then use the appropriate external object code layer to do the
>work. I guess it would be a php component api. This doesn't seem to be too
>far removed from the "adding a constructor" discussion - so I'm not sure if
>the new parser is built to handle something like this. But I in theory it
>doesn't sound too difficult.
>
>-brian-
>
>--
>PHP Development Mailing List (http://www.php.net/)
>To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
>For additional commands, e-mail: php-dev-help <email protected>
>To contact the list administrators, e-mail: php-list-admin <email protected>
-- Zeev Suraski <zeev <email protected>> http://www.zend.com/ For a PGP public key, finger bourbon <email protected>-- PHP Development Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
- Next message: Rasmus Lerdorf: "Re: [PHP-DEV] overloading JNI return values"
- Previous message: fredm <email protected>: "[PHP-DEV] Bug #1627: Opendir does not behave the same on Windows platform as on Unix(Linux)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

