Page 2 of 2

Posted: Mon Sep 04, 2006 1:28 am
by timvw
arborint wrote:
timvw wrote:Do we actually want properties? Here are a couple of observations from the C# world:
I find this question a little startling because properties are really an essential part of objects.
But how would you define properties? I don't see how they are any different than other methods...

There are (imho) two options:

- Or you consider the property as a regular method (controlled access to the object's data)
- Or you consider the property as (uncontrolled) direct access to a piece of data in the object... This results in the same effect as making the data public...

Posted: Mon Sep 04, 2006 3:38 am
by Jenk
As far as finding out if the property is available by trying '$obj->prop = 1' etc.. how does that differ from any other accessor?

object chaining has been around since objects have been in the php engine :)

Posted: Mon Sep 04, 2006 5:12 am
by Chris Corbyn
Jenk wrote:As far as finding out if the property is available by trying '$obj->prop = 1' etc.. how does that differ from any other accessor?

object chaining has been around since objects have been in the php engine :)
$obj->prop = 1

I think this is sort of the point. Do you want developers to make assignments to properties in this fashion? There problem, not yours no? Ohh... email support can get very tedious when it's down to people doing things they shouldn't be doing ;)

Not only that. Let's take PHPMailer as an example of where accessors should have been used.

$mail->Body = 'Foo';

Ok, good that works.

How about:

$mail->body = 'Foo';

No? WTF? Mail not sending. But I specified a body and it never gave me an error :? Hmm... Let's email support :)

Properties are an integral part of objects, I don't think that's in dispute ;) Accessing them should be controlled (ok ok so there are varying views on this) IMO.

__get() and __set() are still accessors. They just allow access control to be handled via properties.

Posted: Mon Sep 04, 2006 6:32 am
by Jenk
My point was referring to how does 'testing' if an accessor works by simply trrying it differes from using a direct property assignment, to a setter?

They are in essence the same is the answer :)

$obj->prop = 1;

May work, may fail.

$obj->setProp(1);

May work, may fail. We don't know yet :)

It just seemed that a point was being made that setters are more resillient to the above than directly setting properties.. which is wrong, they are 'equal' on this matter. :) (Besides, if it's properly done it'll have all the doc's needed :p)

Posted: Mon Sep 04, 2006 7:16 am
by feyd
I like to use __isset() too. :)

Posted: Mon Sep 04, 2006 7:22 am
by Jenk
.. and __call() is normally used by me :)

Posted: Mon Sep 04, 2006 11:05 am
by timvw
Jenk wrote:My point was referring to how does 'testing' if an accessor works by simply trrying it differes from using a direct property assignment, to a setter?

They are in essence the same is the answer :)

$obj->prop = 1;

May work, may fail.

$obj->setProp(1);

May work, may fail. We don't know yet :)

It just seemed that a point was being made that setters are more resillient to the above than directly setting properties.. which is wrong, they are 'equal' on this matter. :) (Besides, if it's properly done it'll have all the doc's needed :p)
Actually, when you're programming against the interface you know exactly which methods exists...
On the other hand, you don't know which variables/properties the implementation will have...

Posted: Mon Sep 04, 2006 11:10 am
by Jenk
Ah yes.. interfaces.