It has more to do with problems with encapsulation and visibility.
Frederik made a nice summary of that, he will reply here:
Ok, here goes:
The way I see it properties in PHP should do the following:
1. Make it possible to override behavior when accessing properties
2. easy access to
DRProblem 1 is the least of the 3 problems, but introducing the keyword
DRalso helps solving the other two.
Strangely enough it is the agument I happen to hear most. I think it's not
PHP problem at all.
DRIf I'm not wrong, __isset() checks if something is *set* not if it's
DRavailable. The
Stanislav Malyshev wrote:
DRIf it returns false, the engine can throw an error on the line where
DRit was used, not inside the __get() method itself, as that doesn't
DRhelp debugging your code (as you don't usually know where it was
DRcalled from).
That I understand. However, you still
On Thu, 25 Aug 2005, Andi Gutmans wrote:
At 06:00 AM 8/25/2005, Edin Kadribasic wrote:
Derick Rethans wrote:
And how can you possibly argue that this more complex than all the other
OO crap that people are suggesting here
I belive that we should do our best to filter out this storm
I don't think __call/__get/__set should be resolving visibility.
Maybe that's the difference. It's main purpose is to allow exposing a
dynamic public interface.
I understand exactly where he was going with this, and I just don't
think PHP is the right place to do it.
Andi
At 02:55 AM
On Aug 26, 2005, at 5:55 AM, Derick Rethans wrote:
I'm just arguing that the current way that setters and getters are
implemented is broken. Instead of keeping a broken behavior I would
like
to see it fixed.
Derick,
It is not broken its incomplete. PHP doesn't really have an
Hello Andi,
Friday, August 26, 2005, 3:39:08 AM, you wrote:
At 06:00 AM 8/25/2005, Edin Kadribasic wrote:
Derick Rethans wrote:
And how can you possibly argue that this more complex than all the other
OO crap that people are suggesting here
I belive that we should do our best to filter
Hello Andi,
Saturday, August 27, 2005, 12:52:38 AM, you wrote:
At 11:32 AM 8/26/2005, Marcus Boerger wrote:
I don't see why the __get/__set/__isset/__unset methods themselves
can't check if the property exists and throw an exception if it
doesn't. I always do that in all my examples...
On Tue, 2 Aug 2005, Derick Rethans wrote:
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
If nobody
On 8/25/05, Derick Rethans [EMAIL PROTECTED] wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
I updated the proposal:
Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
If nobody as any better idea on how to solve it I'd like to start
implementing it.
I seem to remember that we had some voices here stating that the current
mechanisms are sufficient. Adding
DRIf nobody as any better idea on how to solve it I'd like to start
DRimplementing it.
Some questions about the RFC:
1. What exactly property public $x = 1; means? I.e., first of all, what
1 means - does it mean that __get guarantees to return 1 on __get(x)
if it was never set? Should PHP
On Thu, 25 Aug 2005, Christian Schneider wrote:
Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
If nobody as any better idea on how to solve it I'd like to start
implementing it.
I seem to remember that we had some voices here
Derick Rethans wrote:
And how can you possibly argue that this more complex than all the other
OO crap that people are suggesting here
I belive that we should do our best to filter out this storm of OO
feature requests. People want to make PHP look like some other OO
languages for no good
On Thu, 25 Aug 2005, Stanislav Malyshev wrote:
DRIf nobody as any better idea on how to solve it I'd like to start
DRimplementing it.
Some questions about the RFC:
1. What exactly property public $x = 1; means? I.e., first of all, what
1 means - does it mean that __get guarantees to
Derick Rethans wrote:
If you would have properly read the proposal you see that there are 3!
problems with it. And instead of whining about things, I actually spend
some time of contributing with patches too.
Let's agree to disagree. I easily work around these 3 problems here,
so my patch
On Thu, 25 Aug 2005, Edin Kadribasic wrote:
Derick Rethans wrote:
And how can you possibly argue that this more complex than all the other
OO crap that people are suggesting here
I belive that we should do our best to filter out this storm of OO
feature requests. People want to make
On Aug 25, 2005, at 8:01 AM, Derick Rethans wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
#1)
It seems to me that after declaring the property with the property
keyword, the property isn't so virtual
Hello Derick,
Thursday, August 25, 2005, 2:01:56 PM, you wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
I updated the proposal:
Derick Rethans wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
1) seems to be an issue in doxygen and phpDocumentor
2) this seems solveable with a non public set of arrays containing
information about the
Hello Derick,
Thursday, August 25, 2005, 2:01:56 PM, you wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
I updated the proposal:
; Tobias Schlitt
Subject: Re: [PHP-DEV] Property Overloading RFC
Derick Rethans wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
1) seems to be an issue in doxygen and phpDocumentor
2) this seems solveable
:03 AM
To: Derick Rethans
Cc: PHP Developers Mailing List; Jan Borsodi; Raymond Bosman; Frederik
Holljen; Tobias Schlitt
Subject: Re: [PHP-DEV] Property Overloading RFC
Derick Rethans wrote:
On Tue, 2 Aug 2005, Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl
At 06:00 AM 8/25/2005, Edin Kadribasic wrote:
Derick Rethans wrote:
And how can you possibly argue that this more complex than all the other
OO crap that people are suggesting here
I belive that we should do our best to filter out this storm of OO
feature requests. People want to make PHP
On Aug 2, 2005, at 9:05 AM, Derick Rethans wrote:
Problems:
1. There is no way to document the 'virtual' properties with any of
the existing
documentation tools (such as phpdoc and doxygen)
This sounds like a tool problem, not a language problem.
2. There is no way how the magic
On Mon, 8 Aug 2005, Andrei Zmievski wrote:
On Aug 4, 2005, at 12:09 AM, Derick Rethans wrote:
Then you don't do it - it's not a requirement... just an optional thing
(and ofcourse you can't do the __have_prop() thing then that you
suggested below.
Why not? _have_prop() should be able
On Aug 9, 2005, at 12:18 AM, Derick Rethans wrote:
Ah,you meant that __have_prop() should always return the full array of
things that are supported. That is fine, as long as we can have this
generated from the abstract properties that people declared (so that
they can be documented properly
Hi!
Sorry for wrong threading or if this solution was suggested before... i
currently don't have access to my mail client:)
3. There is no way for the magic methods to return a meaningfull error
when a property doesn't exist. Of course it is possible to throw an
error with trigger_error or
On Mon, 8 Aug 2005, Roland Tapken wrote:
3. There is no way for the magic methods to return a meaningfull error
when a property doesn't exist. Of course it is possible to throw an
error with trigger_error or throw in case a property doesn't exist
in a specific class, but the file and line
I got a quick tutorial from Derick :-) on what precisely will be the
affect on the requested functionality and the suggestion makes a whole
lot of sense. As weird declaring virtual properties it seems, there is
really no other alternative for solving the outlined problems in a
consistent manner.
On Aug 4, 2005, at 12:09 AM, Derick Rethans wrote:
Then you don't do it - it's not a requirement... just an optional thing
(and ofcourse you can't do the __have_prop() thing then that you
suggested below.
Why not? _have_prop() should be able to return true if the class does
handle one of
Derick Rethans wrote:
Problems:
1. There is no way to document the 'virtual' properties with any of the existing
documentation tools (such as phpdoc and doxygen)
Rather then adding abstract properties, why not simply document the
possible values inside the doc comments ala:
/**
* @var
On Sun, 7 Aug 2005, Ilia Alshanetsky wrote:
Derick Rethans wrote:
Problems:
1. There is no way to document the 'virtual' properties with any of the
existing
documentation tools (such as phpdoc and doxygen)
Rather then adding abstract properties, why not simply document the possible
On Thu, 4 Aug 2005, Lukas Smith wrote:
I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?
No, besides that would break BC, it would also not solve the problem of
returning errors correctly.
Derick
Derick Rethans wrote:
On Thu, 4 Aug 2005, Lukas Smith wrote:
I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?
No, besides that would break BC, it would also not solve the problem of
returning
DR How about a __have_prop() method that you can call to find out if a
certain
DR virtual property exists?
DR
DRWorks for me, but it needs to be able to called statically (::) and
DRdynamically (-).
I must be missing something, because I don't understand one simple thing:
if you need mechanism
On Aug 2, 2005, at 6:05 AM, Derick Rethans wrote:
Solutions:
- For problem 1. we can introduce a keyword (or use an existing
one) to define
that it is a virtual property ('abstract' or 'virtual' come to
mind). When
declaring it like this it's easy to document, and we can also
I wonder if it wouldnt be enough to be able to force the triggering of
__set(), __get() for all properties be enough to deal with your situation?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello!
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
Introduction:
PHP currently supports property overloading with the magic functions __get()
and __set(). Those methods are called
Derick Rethans wrote:
Hello!
we're finding some problems with property overloading (__get() and
__set()). Here is an RFC describing what we'd like to see changed.
Please comment on this.
Introduction:
PHP currently supports property overloading with the magic functions __get()
and __set().
My concern with the self::isVirtual() syntax would be...
class Base {
function __get($name) {
if (!self::isVirtual($name))
throw;
}
}
class Foo {
abstract public $bar = 1;
}
$f = new Foo;
echo $f-bar;
... Are these 'virtual' members going to work like static
41 matches
Mail list logo
