Re: [PHP-DEV] __toString(), __toArray()
Hello,
On Tue, Jan 12, 2010 at 11:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; }
}
$r = new Int;
This is an exemple where __cast would be very wrong. At the very
least, it should return a value that is an inhabitant of the requested
type! Do you really want (bool)new Int() to be Int 0?
as a result, you have three solutions:
1) have the engine issue an error in case the return value is not compatible
2) provide a return value for every possible types requested
3) throw an exception in case the cast is not handled
In the end, it looks way more complicated/magic than _simply_ defining
a toArray method that is used whenever you need an object to be an
array. You need an explicit cast anyway, so it's (array)$obj vs
$obj-toArray().
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
It appears that, mm w is talking about some aspect oriented feature.
I would welcome a magic method that would intercept calls/access to
existing methods/properties (not only inaccessible ones), in the same
sense that __getattribute__ works in Python for example IIRC. It may
also be a good time to unify properties and types in PHP (we see a lot
of problems with lambdas assigned to object properties).
But... that's certainly another topic.
On 1/13/2010 6:09 AM, mm w wrote:
I don't move any magics,I am worried about your knowledge of php,
there's people to give you money ? weird, set get call are only call
when something doesn't exist catch or catch-able concept is to be able
to catch any existing calls no the dynamic ones.
On Tue, Jan 12, 2010 at 6:59 PM, Clint Priestcpri...@warpmail.net wrote:
Eddie Drapkin wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
I agree, moving all magic to a single function doesn't help the situation at
all, it simply complicates it.
All this talk of too many magic functions is a little comical, its all
trying to overcome operator overloading type functionality in other
languages.
__get()/__set() would be equivalent to getters/setters supported by the c#
language
__toString(), __toArray() would be equivalent to operator String() in c++ (
if I remember correctly )
I would definitely love to be able to, at the very least, cast an object to
an array but I figured a more general purpose __cast() would be most
beneficial to all.
I think the ambiguity question for some functions accepting mixed as a
parameter type could be solved in aforementioned ways.
On Tue, Jan 12, 2010 at 9:11 PM, mm w0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more
carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkinoorza...@gmail.com
wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property,
set_property]
if (observed$type == set_property
somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps
only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15
: 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Ionut G. Stan
I'm under construction | http://blog.igstan.ro/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Etienne Kneuss wrote:
Hello,
On Tue, Jan 12, 2010 at 11:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } }
$r = new Int;
This is an exemple where __cast would be very wrong. At the very
least, it should return a value that is an inhabitant of the requested
type! Do you really want (bool)new Int() to be Int 0?
as a result, you have three solutions:
1) have the engine issue an error in case the return value is not compatible
2) provide a return value for every possible types requested
3) throw an exception in case the cast is not handled
In the end, it looks way more complicated/magic than _simply_ defining
a toArray method that is used whenever you need an object to be an
array. You need an explicit cast anyway, so it's (array)$obj vs
$obj-toArray().
One difference between these two possibilities is that consumers of an
array parameter could consume an object castable to an array whereas it
would need to have knowledge that -toArray() exists in the second scenario.
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; }
}
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0;
} }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0;
} }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved)
{
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 :
0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
I am not forcing anything, it's already there, that's definitely a
more useful magic, if people would add a new one, __cast is not
critical, catchable objects are __catch even if exists, so my point I
'd rather see useful requests than a unseful one e.g __cast
from my perspective __toString and __toArray , __callStatic should be
removed __callStatic is definitly a mistake.
On Tue, Jan 12, 2010 at 6:29 PM, Eddie Drapkin oorza...@gmail.com wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property
somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 :
0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Eddie Drapkin wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
I agree, moving all magic to a single function doesn't help the
situation at all, it simply complicates it.
All this talk of too many magic functions is a little comical, its all
trying to overcome operator overloading type functionality in other
languages.
__get()/__set() would be equivalent to getters/setters supported by the
c# language
__toString(), __toArray() would be equivalent to operator String() in
c++ ( if I remember correctly )
I would definitely love to be able to, at the very least, cast an object
to an array but I figured a more general purpose __cast() would be most
beneficial to all.
I think the ambiguity question for some functions accepting mixed as a
parameter type could be solved in aforementioned ways.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
I don't move any magics,I am worried about your knowledge of php,
there's people to give you money ? weird, set get call are only call
when something doesn't exist catch or catch-able concept is to be able
to catch any existing calls no the dynamic ones.
On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote:
Eddie Drapkin wrote:
What you're proposing is just forcing __call, _callStatic, __get and
__set into a single method, which does nothing to reduce the amount of
magic, only obfuscate it. And it certainly offers no alternative to
__cast, at least not that I can see.
I agree, moving all magic to a single function doesn't help the situation at
all, it simply complicates it.
All this talk of too many magic functions is a little comical, its all
trying to overcome operator overloading type functionality in other
languages.
__get()/__set() would be equivalent to getters/setters supported by the c#
language
__toString(), __toArray() would be equivalent to operator String() in c++ (
if I remember correctly )
I would definitely love to be able to, at the very least, cast an object to
an array but I figured a more general purpose __cast() would be most
beneficial to all.
I think the ambiguity question for some functions accepting mixed as a
parameter type could be solved in aforementioned ways.
On Tue, Jan 12, 2010 at 9:11 PM, mm w 0xcafef...@gmail.com wrote:
the multiplication of magic, the pointed point, need to read more
carefully
On Tue, Jan 12, 2010 at 6:10 PM, Eddie Drapkin oorza...@gmail.com
wrote:
How does this have *anything* to do with the discussion at hand?
On Tue, Jan 12, 2010 at 9:09 PM, mm w 0xcafef...@gmail.com wrote:
don't worry it's only for people who are working with MVC and
RootObject structure, there is too much magics already and __cast is
not needed at all,
as we cannot monkey patch to add an observer on itself, a nice
solution should have a catchable object so __catch any calls
function __catch($data, $type) {
if (method == $type) {
if (data[selector] = 'setValue' observedValueForKeyPath) {
$this-_setValue(($data['arg']);
return;
}
}
continue_natural_call();
}
we could imagine to have a root-object-built-in-class that is
naturally observable, or a root classObject at all, anyway it's only
something for people who are doing OO programming,
so don't worry
On Tue, Jan 12, 2010 at 2:40 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property,
set_property]
if (observed $type == set_property
somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps
only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15
: 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
I don't move any magics, I'm worried your knowledge of social skills? Theirs people be your friends? Weird On Jan 12, 2010 9:10 PM, mm w 0xcafef...@gmail.com wrote: I don't move any magics,I am worried about your knowledge of php, there's people to give you money ? weird, set get call are only call when something doesn't exist catch or catch-able concept is to be able to catch any existing calls no the dynamic ones. On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote: Eddie Drapkin wr... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub...
Re: [PHP-DEV] __toString(), __toArray()
:-D, without any magic, I am sorry if I hurt you I though you were tougher than a cookie, don't worry about my friends I have plenty on face-cooked, but for God Sake I am still eating alone at noon 8-) On Tue, Jan 12, 2010 at 9:50 PM, Chris Stockton chrisstockto...@gmail.com wrote: I don't move any magics, I'm worried your knowledge of social skills? Theirs people be your friends? Weird On Jan 12, 2010 9:10 PM, mm w 0xcafef...@gmail.com wrote: I don't move any magics,I am worried about your knowledge of php, there's people to give you money ? weird, set get call are only call when something doesn't exist catch or catch-able concept is to be able to catch any existing calls no the dynamic ones. On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote: Eddie Drapkin wr... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Hello, On Mon, Jan 11, 2010 at 7:31 PM, Clint Priest cpri...@warpmail.net wrote: I know there's been requests to add a __toArray() and most of the arguments against it is that there are too many magic functions already. I just thought I'd propose an alternative that would satisfy all of them. Why not a __cast($Type) magic function? I'd advance two reasons against this idea: 1) It's more self-explanatory to explicitly call the appropriate converting method, enough with implicit madness! 2) For some operations, you'd have to know the types in advance before knowing what operations needs to be performed: $obj1 + 2; Now what __cast should be called? Int? Float? Also, what about $obj1 + $obj2: Int? Float? Array? Another example: str_replace($obj1, bar, foo); what to call? __toString or __toArray? str_replace accepts both. IMHO it would only make sense to invoke methods on explicit casts only, otherwise it will just be a mess with PHP's current type juggling. But, as we seen with __toString, limiting the field of application was annoying (and it was later extended to nearly all string usages). So, what will it be? Inconsistent and Confusing or Limited and Annoying? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Hi! Why not a __cast($Type) magic function? The interesting thing is that in the engine the object handler is actually: typedef int (*zend_object_cast_t)(zval *readobj, zval *retval, int type TSRMLS_DC); i.e. the handler is already generic, but implementation API isn't - standard engine handler supports only IS_STRING (and IS_BOOL is a funny way - objects are always true). In other words, extensions already can do this, PHP programmer can't. 1) It's more self-explanatory to explicitly call the appropriate converting method, enough with implicit madness! This is probably the reason why the above was done - conversion to the string representation is a very frequent action (especially in the Web world where everything ends up being in the text page anyway ;) while conversion to numeric types is very special case and very ambiguous, as Etienne noted, and conversion to an array is also rather special case (a lot of cases where array-like syntax is called for are served by ArrayAccess). -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Etienne Kneuss wrote:
Hello,
On Mon, Jan 11, 2010 at 7:31 PM, Clint Priest cpri...@warpmail.net wrote:
I know there's been requests to add a __toArray() and most of the arguments
against it is that there are too many magic functions already. I just
thought I'd propose an alternative that would satisfy all of them.
Why not a __cast($Type) magic function?
I'd advance two reasons against this idea:
1) It's more self-explanatory to explicitly call the appropriate
converting method, enough with implicit madness!
2) For some operations, you'd have to know the types in advance before
knowing what operations needs to be performed:
$obj1 + 2;
Now what __cast should be called? Int? Float?
Wouldn't it make sense to be an integer since its being added to an integer?
Also, what about $obj1 + $obj2: Int? Float? Array?
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
Another example: str_replace($obj1, bar, foo); what to call?
__toString or __toArray? str_replace accepts both.
This is an interesting situation, could be resolved by attempting a
__cast('array') followed by a __cast('string') if the first call was
rejected (false, exception or something).
IMHO it would only make sense to invoke methods on explicit casts
only, otherwise it will just be a mess with PHP's current type
juggling. But, as we seen with __toString, limiting the field of
application was annoying (and it was later extended to nearly all
string usages).
I would agree with this as well, only called during explicit casts.
So, what will it be? Inconsistent and Confusing or Limited and Annoying?
One other alternative, probably not as easy would be to pass multiple
types to cast, much the way the Accepts: HTTP header does, providing a
list of possible cast types, in the preferred order.
One could even implement an interface such as:
interface Castable {
function GetCastableTypes();
}
or some such.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
On Mon, Jan 11, 2010 at 7:17 PM, Clint Priest cpri...@warpmail.net wrote:
Etienne Kneuss wrote:
Hello,
On Mon, Jan 11, 2010 at 7:31 PM, Clint Priest cpri...@warpmail.net
wrote:
I know there's been requests to add a __toArray() and most of the
arguments
against it is that there are too many magic functions already. I just
thought I'd propose an alternative that would satisfy all of them.
Why not a __cast($Type) magic function?
I'd advance two reasons against this idea:
1) It's more self-explanatory to explicitly call the appropriate
converting method, enough with implicit madness!
2) For some operations, you'd have to know the types in advance before
knowing what operations needs to be performed:
$obj1 + 2;
Now what __cast should be called? Int? Float?
Wouldn't it make sense to be an integer since its being added to an integer?
Also, what about $obj1 + $obj2: Int? Float? Array?
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
Another example: str_replace($obj1, bar, foo); what to call?
__toString or __toArray? str_replace accepts both.
This is an interesting situation, could be resolved by attempting a
__cast('array') followed by a __cast('string') if the first call was
rejected (false, exception or something).
IMHO it would only make sense to invoke methods on explicit casts
only, otherwise it will just be a mess with PHP's current type
juggling. But, as we seen with __toString, limiting the field of
application was annoying (and it was later extended to nearly all
string usages).
I would agree with this as well, only called during explicit casts.
So, what will it be? Inconsistent and Confusing or Limited and Annoying?
One other alternative, probably not as easy would be to pass multiple types
to cast, much the way the Accepts: HTTP header does, providing a list of
possible cast types, in the preferred order.
One could even implement an interface such as:
interface Castable {
function GetCastableTypes();
}
or some such.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
