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 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
--
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
