Ideas on hooking into the object cast handler

• Thus wrote Robert Silva:

I'm working on creating object wrappers for native php types. With ZE2 and
the cast_object object handler, I am able to "unbox" the objects to their
native php types with simple casts, but as ZE2 currently stands, (to my
knowledge at least) there is no way to hook into the (object)native_type
cast. Currently, when you cast a native value to an object using
(object)$native_val, it calls convert_to_object which simply converts the
native type to an array. I was hoping some of you more familiar with the ZE
than I had some ideas of how it may be modified to allow an extension to
hook into the convert_to_object function. Looked around for some
implementation of an extension registering a callback inside the engine but
couldn't find any examples. Here is a userland example of what I am trying
to accomplish:

$intObj = new PInt32(5); // Int object wrapper
$phpInt = (int)$intObj; // Calls the cast_object handler for the PInt32 obj

I was actually thinking about this the other day, my idea was to
force an object declaration to tell everyone that it can be casted,
so ZE2 will define all the different type of interfaces:

/* ZE2 defined interface represented in php /
interface Castable {
function __toString();
function __toInt();
function __toFloat();
function __toArray();
function __toObject($objname); / questionable */
}

Then if a object wishes to be converted to a paticular type it
would simply implement the interface:

class Foo implements Castable {
...
function __toString() {
return "I am a string";
}
...all the rest of the interface definitions
}

The questionable toObject() would provide the possiblities of
something like:

$newObj = (OtherObject) $FooObject;

But, iirc, the above will probably involve a lot of rewriting of
the parsing.

Curt

First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!

Hey,

I don't think explicit object casting is of much use. How does (float) $obj
improve your life much more than $obj->toFloat()?
Don't forget that implicit casting doesn't make a lot of sense because
"1",1, and 1.0 are all potentially the same in PHP.
When you have something like: $num1 + $num2 then PHP looks at both operands
in order to decide what it will do. Having an object that can convert into
every native type wouldn't fit in with this dynamic typing. How would the
engine know which one you want?

The only cast I think is useful is the toString() cast as it's also pretty
well defined when we need this (concatenation, printing).

Andi

At 05:16 AM 9/25/2004 +0000, Curt Zirzow wrote:

• Thus wrote Robert Silva:

I'm working on creating object wrappers for native php types. With ZE2 and
the cast_object object handler, I am able to "unbox" the objects to their
native php types with simple casts, but as ZE2 currently stands, (to my
knowledge at least) there is no way to hook into the (object)native_type
cast. Currently, when you cast a native value to an object using
(object)$native_val, it calls convert_to_object which simply converts the
native type to an array. I was hoping some of you more familiar with the ZE
than I had some ideas of how it may be modified to allow an extension to
hook into the convert_to_object function. Looked around for some
implementation of an extension registering a callback inside the engine but
couldn't find any examples. Here is a userland example of what I am trying
to accomplish:

$intObj = new PInt32(5); // Int object wrapper
$phpInt = (int)$intObj; // Calls the cast_object handler for the PInt32 obj

I was actually thinking about this the other day, my idea was to
force an object declaration to tell everyone that it can be casted,
so ZE2 will define all the different type of interfaces:

/* ZE2 defined interface represented in php /
interface Castable {
function __toString();
function __toInt();
function __toFloat();
function __toArray();
function __toObject($objname); / questionable */
}

Then if a object wishes to be converted to a paticular type it
would simply implement the interface:

class Foo implements Castable {
...
function __toString() {
return "I am a string";
}
...all the rest of the interface definitions
}

The questionable toObject() would provide the possiblities of
something like:

$newObj = (OtherObject) $FooObject;

But, iirc, the above will probably involve a lot of rewriting of
the parsing.

Curt

First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!