[PHP-DEV] Random Monday thought.

2013-06-03 Thread Richard Quadling 
Hi.

Recently the setters/getters rfc was declined.

Other than the vote, was there any technical reasons?

I've been sitting here and had a thought.

Currently, if I use ...

?php
class some_base_class {}
?

I can, sort of, think of this as ...

?php
class some_base_class extends \stdClass {}
?

in as much as \stdClass has no constants, properties or methods. In fact,
no behaviour at all.

Now, could it be possible that I could have another PHP maintained base
class or interface that DID support setters/getters?

So, I would have to make the decision at develop time ...

?php
class some_base_class extends \stdClassThatHasSetterGetterSupport {}
?

sort of thing.

So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
variable/property handling to be used is the original style.

But for those base classes that do extend from
\stdClassThatHasSetterGetterSupport, then these would have property support.


Is this even possible/feasible?

Whilst the vote went against the initial rfc, I'm happy to accept that
(though I wish it had passed as I like the black boxing and the semantic
cleanliness it would provide - IMHO).


To me, if the internals operated as ...

?php
class \stdClassThatHasSetterGetterSupport extends \stdClass {}
?

add if that was enough to enable setters/getters, then COULD this be a way
forward for PHP supporting new functionality without breaking base
functionality?

In essence, turning PHP's internals into a sort of OOP framework.

Regards,

Richard.


-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

Re: [PHP-DEV] Random Monday thought.

2013-06-03 Thread Nikita Popov 
On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.comwrote:

 Hi.

 Recently the setters/getters rfc was declined.

 Other than the vote, was there any technical reasons?

 I've been sitting here and had a thought.

 Currently, if I use ...

 ?php
 class some_base_class {}
 ?

 I can, sort of, think of this as ...

 ?php
 class some_base_class extends \stdClass {}
 ?

 in as much as \stdClass has no constants, properties or methods. In fact,
 no behaviour at all.

 Now, could it be possible that I could have another PHP maintained base
 class or interface that DID support setters/getters?

 So, I would have to make the decision at develop time ...

 ?php
 class some_base_class extends \stdClassThatHasSetterGetterSupport {}
 ?

 sort of thing.

 So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
 variable/property handling to be used is the original style.

 But for those base classes that do extend from
 \stdClassThatHasSetterGetterSupport, then these would have property
 support.


 Is this even possible/feasible?

 Whilst the vote went against the initial rfc, I'm happy to accept that
 (though I wish it had passed as I like the black boxing and the semantic
 cleanliness it would provide - IMHO).


 To me, if the internals operated as ...

 ?php
 class \stdClassThatHasSetterGetterSupport extends \stdClass {}
 ?

 add if that was enough to enable setters/getters, then COULD this be a way
 forward for PHP supporting new functionality without breaking base
 functionality?

 In essence, turning PHP's internals into a sort of OOP framework.

 Regards,

 Richard.


PHP does not support multiple inheritance. So no, this doesn't solve really
the issue.

Nikita

Re: [PHP-DEV] Random Monday thought.

2013-06-03 Thread Richard Quadling 
On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:

 On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.comwrote:

 Hi.

 Recently the setters/getters rfc was declined.

 Other than the vote, was there any technical reasons?

 I've been sitting here and had a thought.

 Currently, if I use ...

 ?php
 class some_base_class {}
 ?

 I can, sort of, think of this as ...

 ?php
 class some_base_class extends \stdClass {}
 ?

 in as much as \stdClass has no constants, properties or methods. In fact,
 no behaviour at all.

 Now, could it be possible that I could have another PHP maintained base
 class or interface that DID support setters/getters?

 So, I would have to make the decision at develop time ...

 ?php
 class some_base_class extends \stdClassThatHasSetterGetterSupport {}
 ?

 sort of thing.

 So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
 variable/property handling to be used is the original style.

 But for those base classes that do extend from
 \stdClassThatHasSetterGetterSupport, then these would have property
 support.


 Is this even possible/feasible?

 Whilst the vote went against the initial rfc, I'm happy to accept that
 (though I wish it had passed as I like the black boxing and the semantic
 cleanliness it would provide - IMHO).


 To me, if the internals operated as ...

 ?php
 class \stdClassThatHasSetterGetterSupport extends \stdClass {}
 ?

 add if that was enough to enable setters/getters, then COULD this be a way
 forward for PHP supporting new functionality without breaking base
 functionality?

 In essence, turning PHP's internals into a sort of OOP framework.

 Regards,

 Richard.


 PHP does not support multiple inheritance. So no, this doesn't solve
 really the issue.

 Nikita



I'm not talking about multiple inheritance, but of extension.

A new internal PHP base class which internally extends from stdClass, but
is a class that provides additional functionality, specifically
setter/getter logic.

So, from userland, I can not extend and get the current stdClass, or I can
choose \stdClassThatHasSetterGetterSupport and get that.

And if I so wish, I can implement
SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.

Richard.

-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

Re: [PHP-DEV] Random Monday thought.

2013-06-03 Thread Brandon Wamboldt 
I think the point was that if somebody wants to extend one another class,
maybe one of the SPL classes for example, they can't also extend the base
class with getter/setter support so it's an incomplete solution that will
frustrate many users.


On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadl...@gmail.comwrote:

 On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:

  On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.com
 wrote:
 
  Hi.
 
  Recently the setters/getters rfc was declined.
 
  Other than the vote, was there any technical reasons?
 
  I've been sitting here and had a thought.
 
  Currently, if I use ...
 
  ?php
  class some_base_class {}
  ?
 
  I can, sort of, think of this as ...
 
  ?php
  class some_base_class extends \stdClass {}
  ?
 
  in as much as \stdClass has no constants, properties or methods. In
 fact,
  no behaviour at all.
 
  Now, could it be possible that I could have another PHP maintained base
  class or interface that DID support setters/getters?
 
  So, I would have to make the decision at develop time ...
 
  ?php
  class some_base_class extends \stdClassThatHasSetterGetterSupport {}
  ?
 
  sort of thing.
 
  So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
  variable/property handling to be used is the original style.
 
  But for those base classes that do extend from
  \stdClassThatHasSetterGetterSupport, then these would have property
  support.
 
 
  Is this even possible/feasible?
 
  Whilst the vote went against the initial rfc, I'm happy to accept that
  (though I wish it had passed as I like the black boxing and the semantic
  cleanliness it would provide - IMHO).
 
 
  To me, if the internals operated as ...
 
  ?php
  class \stdClassThatHasSetterGetterSupport extends \stdClass {}
  ?
 
  add if that was enough to enable setters/getters, then COULD this be a
 way
  forward for PHP supporting new functionality without breaking base
  functionality?
 
  In essence, turning PHP's internals into a sort of OOP framework.
 
  Regards,
 
  Richard.
 
 
  PHP does not support multiple inheritance. So no, this doesn't solve
  really the issue.
 
  Nikita
 


 I'm not talking about multiple inheritance, but of extension.

 A new internal PHP base class which internally extends from stdClass, but
 is a class that provides additional functionality, specifically
 setter/getter logic.

 So, from userland, I can not extend and get the current stdClass, or I can
 choose \stdClassThatHasSetterGetterSupport and get that.

 And if I so wish, I can implement
 SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.

 Richard.

 --
 Richard Quadling
 Twitter : @RQuadling
 EE : http://e-e.com/M_248814.html
 Zend : http://bit.ly/9O8vFY




-- 
*Brandon Wamboldt*
Software Engineer

Resume/CV http://brandonwamboldt.com/cv/  - Personal
Site/Bloghttp://brandonwamboldt.ca/
 - LinkedIn http://ca.linkedin.com/in/brandonwamboldt - StackOverflow
Careers Profile http://careers.stackoverflow.com/brandonwamboldt - GitHub
Profile https://github.com/brandonwamboldt

Re: [PHP-DEV] Random Monday thought.

2013-06-03 Thread Kalle Sommer Nielsen 
Hi Nikita

2013/6/3 Nikita Popov nikita@gmail.com:
 PHP does not support multiple inheritance. So no, this doesn't solve really
 the issue.

This is also why this makes a lot more sense to implement as an
Interface as we can implement more than one per class, much like we do
with ArrayAccess.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Random Monday thought.

2013-06-03 Thread Richard Quadling 
On 3 June 2013 18:22, Brandon Wamboldt bran...@brandonwamboldt.ca wrote:

 I think the point was that if somebody wants to extend one another class,
 maybe one of the SPL classes for example, they can't also extend the base
 class with getter/setter support so it's an incomplete solution that will
 frustrate many users.


 On Mon, Jun 3, 2013 at 2:20 PM, Richard Quadling rquadl...@gmail.comwrote:

 On 3 June 2013 17:55, Nikita Popov nikita@gmail.com wrote:

  On Mon, Jun 3, 2013 at 6:49 PM, Richard Quadling rquadl...@gmail.com
 wrote:
 
  Hi.
 
  Recently the setters/getters rfc was declined.
 
  Other than the vote, was there any technical reasons?
 
  I've been sitting here and had a thought.
 
  Currently, if I use ...
 
  ?php
  class some_base_class {}
  ?
 
  I can, sort of, think of this as ...
 
  ?php
  class some_base_class extends \stdClass {}
  ?
 
  in as much as \stdClass has no constants, properties or methods. In
 fact,
  no behaviour at all.
 
  Now, could it be possible that I could have another PHP maintained base
  class or interface that DID support setters/getters?
 
  So, I would have to make the decision at develop time ...
 
  ?php
  class some_base_class extends \stdClassThatHasSetterGetterSupport {}
  ?
 
  sort of thing.
 
  So, for classes NOT extending \stdClassThatHasSetterGetterSupport, the
  variable/property handling to be used is the original style.
 
  But for those base classes that do extend from
  \stdClassThatHasSetterGetterSupport, then these would have property
  support.
 
 
  Is this even possible/feasible?
 
  Whilst the vote went against the initial rfc, I'm happy to accept that
  (though I wish it had passed as I like the black boxing and the
 semantic
  cleanliness it would provide - IMHO).
 
 
  To me, if the internals operated as ...
 
  ?php
  class \stdClassThatHasSetterGetterSupport extends \stdClass {}
  ?
 
  add if that was enough to enable setters/getters, then COULD this be a
 way
  forward for PHP supporting new functionality without breaking base
  functionality?
 
  In essence, turning PHP's internals into a sort of OOP framework.
 
  Regards,
 
  Richard.
 
 
  PHP does not support multiple inheritance. So no, this doesn't solve
  really the issue.
 
  Nikita
 


 I'm not talking about multiple inheritance, but of extension.

 A new internal PHP base class which internally extends from stdClass, but
 is a class that provides additional functionality, specifically
 setter/getter logic.

 So, from userland, I can not extend and get the current stdClass, or I can
 choose \stdClassThatHasSetterGetterSupport and get that.

 And if I so wish, I can implement
 SomeOtherPHPSuppliedIterfaceLikeIteratorOrWhatever.

 Richard.


Ah. DOH!

Would having an interface that swapped the default property accessor logic
be any better?

So, I could say ...

?php
class myBase implements \PHPMaintainedSetterGetterLogic {}
?

Hmmm...

I know it is still not perfect.

Shame.

I really would have liked setter/getter.


-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

Re: [PHP-DEV] Random Monday thought.

2013-06-03 Thread Galen Wright-Watson 
On Mon, Jun 3, 2013 at 10:30 AM, Richard Quadling rquadl...@gmail.comwrote:

 On 3 June 2013 18:22, Brandon Wamboldt bran...@brandonwamboldt.ca wrote:

  I think the point was that if somebody wants to extend one another class,
  maybe one of the SPL classes for example, they can't also extend the base
  class with getter/setter support so it's an incomplete solution that will
  frustrate many users.
  [...]
 
 Ah. DOH!

 Would having an interface that swapped the default property accessor logic
 be any better?


Or a trait (Accessable, Accessored, Accessorable)? Is it possible to
have a trait implemented internally? Though it seems that this would still
sometimes run afoul of mixing new accessor logic with old.