> 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
Stanislav Malyshev wrote:
DR>>If it returns false, the engine can throw an error on the line where
DR>>it was used, not inside the __get() method itself, as that doesn't
DR>>help debugging your code (as you don't usually know where it was
DR>>called from).
That I understand. However, you sti
DR>>Problem 1 is the least of the 3 problems, but introducing the keyword
DR>>also 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.
DR>>If I'm not wrong, __isset() checks if something is *set* not if it's
DR>>available
Hello Andi,
Saturday, August 27, 2005, 1:45:43 AM, you wrote:
> At 04:27 PM 8/26/2005, Marcus Boerger wrote:
>>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 t
At 04:27 PM 8/26/2005, Marcus Boerger wrote:
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
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 examp
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...
Interesting, How do you do that? There is no __isset or __unset.
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 be
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
implementa
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 8/26/200
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 ou
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 PH
-
>> From: Lukas Smith [mailto:[EMAIL PROTECTED]
>> Sent: Friday, August 26, 2005 12: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
t; 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/property_overload
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 pr
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 prop
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 pr
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 anymor
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
On Thu, 25 Aug 2005, Stanislav Malyshev wrote:
> DR>>If nobody as any better idea on how to solve it I'd like to start
> DR>>implementing 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 guar
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, 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 v
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 stating tha
DR>>If nobody as any better idea on how to solve it I'd like to start
DR>>implementing 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
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
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:
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 nobod
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 method
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 to
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
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 thos
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 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 th
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"
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 th
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 abst
DR>>> How about a __have_prop() method that you can call to find out if a
certain
DR>>> virtual property exists?
DR>>
DR>>Works for me, but it needs to be able to called statically (::) and
DR>>dynamically (->).
I must be missing something, because I don't understand one simple thing:
if you ne
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 e
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
On Wed, 3 Aug 2005, Andrei Zmievski wrote:
> The whole point of these "virtual" properties is that their names can be
> parameterized. If you have 1000 of these variables (in a DB or somewhere), how
> would you declare them as "abstract" or "virtual"?
Then you don't do it - it's not a requirement
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
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
implement
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 me
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().
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
46 matches
Mail list logo
