SitePoint Sponsor |
|
User Tag List
Results 251 to 275 of 325
-
Sep 29, 2005, 10:37 #251
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
As a personal aside, despite the fact that I agree that it is better to start small and grow, I am a little leary of the blanket "it is harder to pull it out" metaphor. After all, we are still in the very start of the design stage and I would expect that no one is seriously going to depend on any of this work for quite some time. At any rate, I don't think it should be used as a stick to beat away ideas or discussions. I am not suggesting that is the case, but I can imagine it happening as progress mounts and we get into even more complicated and challenging areas.
Best regards to all.
-
Sep 29, 2005, 10:43 #252
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
-
Sep 29, 2005, 12:14 #253
- Join Date
- Aug 2005
- Location
- Santa Rosa, CA
- Posts
- 67
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Hey folks, I hope I'm not butting in, but I breezed through some of the posts here recently and wanted to say that I really like the idea of having a standard PHP interface repository. The PHP project I'm currently working on will be used by the public (developers, that is), so I'm using a lot of interfaces so my classes are loosely coupled. Some of these interfaces are basic and could easily be "standardized" based on the functionality.
Here's one I'd like to tackle right away: value filtering. I think it'd be great if there were a couple of interfaces to define how to find and execute filters on values (values being either native PHP types or value objects). Here's my idea of what they are:
1. FilterRegistry -- you could request a filter based on name, and you could get a list of filters that would apply to the supplied value. FilterRegistry is a singleton.
2. Filter -- a filter would take an input value and return an output value. In addition, it would have a way to specify filter options (either ahead of time or as part of the filtering method call itself). (Implementation note: it would raise some kind of exception if the value supplied is not supported by the filter.)
What do you think? Maybe if people like the idea we should talk in a different thread? I don't want to interrupt you folks' thought processes on the Keyed/Properties/Whatever interface (good stuff!).
Jared
-
Sep 29, 2005, 12:27 #254
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Originally Posted by Travis S
Originally Posted by Travis S
Christopher
-
Sep 29, 2005, 13:44 #255
- Join Date
- Dec 2004
- Location
- ljubljana, slovenia
- Posts
- 684
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
About the naming:
I feel that Keyed is a name that more suits an object that reads/writes values in (key, value) pairs:
$obj->get('key')
And name Properties feel more like accessing the object's properties:
$obj->property
It's that an object has a property, but holds a value for a key. Which might just as well mean the same thing. Maybe I'm totally off, I'm not a native English speaker, but it feels so.
Just thought I'd mention it.
Regards
PS. Still not happy with __get/__set, because I still think using any magical overloading should be considered as an implementation detail. An interface user should have an option to use magical overloading or not. I do believe I have a point here.
-
Sep 29, 2005, 14:04 #256
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dbevfat
PHP Code:class KeyedAssignable implements Keyed {
function __get($key) {
return self::get($key);
}
function __set($key, $value) {
self::set($key, $value);
}
}
Christopher
-
Sep 29, 2005, 17:14 #257
- Join Date
- Feb 2002
- Posts
- 625
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I really really don't see the point of overloading in an interface like this one.
As said before, this is an implementation detail.
-
Sep 30, 2005, 13:39 #258
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
Another problem with overload in PHP4.4 is that it makes the current crop of reference problems ten times worse. Looks like the reference "fixes" have not caught up with __get() and __set() usage.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 30, 2005, 14:06 #259
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
So what about the very basic:
PHP Code:<?php
/**
* This file contains {@link Keyed}.
*
* @package OpenSIR
*/
/**
* Provides an interface for storing and retrieving any number of "Keyed"
* properties
*
* This interfaces is meant to be used by any object that should expose values
* to match a given key.
*
* @package OpenSIR
* @author Travis Swicegood <development@domain51.com>
* @author Collectively authored via
* {@link http://www.sitepoint.com/forums/showthread.php?t=298611}.
* @license http://www.gnu.org/copyleft/lesser.html LGPL
*/
interface Keyed
{
/**
* Retrieves a mixed value from this container by its given <i>$key</i>.
*
* If <i>exists($key) == FALSE</i> the value of NULL is returned.
*
* @param string
* @return mixed
*/
public function get($key);
/**
* Sets the property of a given <i>$key</i> to a given <i>$value</i>.
*
* @param string
* @param mixed
*/
public function set($key, $value);
/**
* Returns <i>TRUE</i> if a given property is set, <i>FALSE</i> otherwise.
*
* @param string
* @return boolean
*/
public function exists($key); // or hasKey() or keyExists() ??
}
?>Christopher
-
Sep 30, 2005, 14:43 #260
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Now I think I know how some of the PEAR guys feels...
Ok - if I remember correctly, I originally stated that I liked the idea of get()/set() versus __get()/__set() and having two interfaces such as Keyed and MagicalKeyed. If I remember correctly, at the time the concensus was using __get()/__set() seemed to make the most sense as it took advantage of one of the new PHP features to make things easier. There are still a hundred different ways to store the values once you get to __set() - defining that you must use __set() is no more of an implementation detail imo than defining set().
Marcus - as far as PHP 4.x, this isn't being considered for use in PHP 4 other than directly calling __get() instead of using the overloading. I've heard of nothing but problems with that whole feature.
Re: opensir.library.php - you're right to an extent arborint. We're not going to need it... yet. I'm fine with pull it out of the next release I tag until we get to the point we need it like I've done with Exceptions
-
Sep 30, 2005, 15:08 #261
- Join Date
- Jun 2004
- Location
- Copenhagen, Denmark
- Posts
- 6,157
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Originally Posted by Travis S
Originally Posted by Travis S
-
Sep 30, 2005, 15:11 #262
Why not simply implement both get()/set() and _get()/_set() ?
-
Sep 30, 2005, 15:15 #263
- Join Date
- May 2005
- Location
- Finland
- Posts
- 608
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
-
Sep 30, 2005, 15:29 #264
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Originally Posted by Travis S
Originally Posted by Travis S
Originally Posted by Travis S
Christopher
-
Sep 30, 2005, 15:35 #265
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Ezku
Christopher
-
Sep 30, 2005, 19:06 #266
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-> is the standard property access notation for PHP. When PHP gets native support for accessor methods, they will work with ->. Notice that I say when. I'm optimistic about this one, but forward compatibility guessing is dicey at best.
Some implementation experiments have me thinking that it might be a bad idea to allow direct calls of the magic methods. Ala $obj->__get(). It may be best to leave it to the engine to make these calls.
Not to mention that the benefit of being lightweight enough not to have to declare a specific interface or parent class.
I think its best to define how the client might expect to access the properties of the object, rather than to define how the object might like its clients to access it. I hope that the difference in perspective is clear.
I'm pretty much at a standstill on this. I need to do tons of research and try out implementations before I can comment much further, but don't have the time right now.
-
Oct 1, 2005, 00:09 #267
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Here is one direction for research.
zend_object_handler.c has a function that looks like this:
PHP Code:zval *zend_std_read_property(zval *object, zval *member, int type TSRMLS_DC)
{
zend_object *zobj;
zval *tmp_member = NULL;
zval **retval;
zval *rv = NULL;
zend_property_info *property_info;
int silent;
zend_bool use_get;
silent = (type == BP_VAR_IS);
zobj = Z_OBJ_P(object);
use_get = (zobj->ce->__get && !zobj->in_get);
...
/* make zend_get_property_info silent if we have getter - we may want to use it */
property_info = zend_get_property_info(zobj->ce, member, use_get TSRMLS_CC);
if (!property_info || zend_hash_quick_find(zobj->properties, property_info->name, property_info->name_length+1, property_info->h, (void **) &retval) == FAILURE) {
if (use_get) {
/* have getter - try with it! */
zobj->in_get = 1; /* prevent circular getting */
rv = zend_std_call_getter(object, member TSRMLS_CC);
zobj->in_get = 0;
if (rv) {
retval = &rv;
} else {
retval = &EG(uninitialized_zval_ptr);
}
} else {
if (!silent) {
zend_error(E_NOTICE,"Undefined property: %s::$%s", zobj->ce->name, Z_STRVAL_P(member));
}
retval = &EG(uninitialized_zval_ptr);
}
}
...
return *retval;
}
PHP Code:typedef struct _zend_property_info {
zend_uint flags;
char *name;
int name_length;
ulong h;
char *doc_comment;
int doc_comment_len;
} zend_property_info;
PHP Code:char *getter;
char *setter;
PHP Code:class myClass {
private $myX;
public property $x read getX write setX;
private function getX() {
return $this->myX;
}
private function setX($x) {
$this->myX = $x;
}
}
My question is what does the logic in zend_std_read_property have to look like to support this? Some pseudo code like:
PHP Code:if (!property_info) {
// call __get
} else if (property_info->getter) {
// call getter method
} else {
// call zend_hash_quick_find
// if not found call __get
}
Am I the only one who thinks that native accessor methods would be a good thing?
Does this help explain why I favor ->?
-
Oct 1, 2005, 09:44 #268
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
It's a little hard to know how to respond to this, but I think it needs responding to. I will try to stretch my toes and see if I can touch the ground.
Originally Posted by Selkirk
) or create a standard interface for simple keyed containers. As objects are already containers of a sort, I don't think it makes sense to keep returning to them for keyed containers. I think I may want my classes that implement the Keyed interface to still have regular properties and also have separate keyed access. I don't think I want to loose anything; I want to gain a simple container standard.
Originally Posted by Selkirk
Originally Posted by Selkirk
Originally Posted by Selkirk
Originally Posted by Selkirk
I would suggest that we split the discussions of an expanded object behavior for PHP5 and a minimal keyed container, because that is what is causing the circling here. Then those interested in expanded object behavior for PHP5 can see if it is possible and those interested a minimal keyed container can see if it is worthwhile.Christopher
-
Oct 1, 2005, 14:06 #269
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
Originally Posted by arborint
-
Oct 1, 2005, 14:53 #270
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by jayboots
Originally Posted by jayboots
Christopher
-
Oct 1, 2005, 14:59 #271
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I cannot see any benifit of supporting PHP4 and it has nothing to do with Interfaces. In fact there would be several factors to consider first, such as that PHP4 uses references for example. How does that effect the design... In regards for example, if someone uses a PHP4 library with PHP5, based on what this discussion provides?
That is a BC issue which could (proberly will actually) cloud the wider discussion later. Also consider just how much of use will you get from a PHP4 implementation in regards to how long PHP4 will be continued to be supported?
-
Oct 3, 2005, 06:58 #272
- Join Date
- Feb 2002
- Posts
- 625
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Erm..you guys, stop mixing up DESIGN issues with IMPLEMENTATION issues. An interface does not enforce any implementation details or rules, all it requires is for you to IMPLEMENT the methods layed out in the interface.
I think the interface posted by arborint (here) perfectly demonstrates how NOT to design an interface (comment wise that is).
Otherwise it is just fine. Personally I vote for the name Keyed and to use the methods as outlined in that very post. I also think using exists() serves the most general purpose.
For example one possible usage of Keyed might look like (this example is only for demonstration purposes, I'm not saying this is how it should be implemented!)
PHP Code:<?php
interface IKeyed
{
public function get($key);
public function set($key, $value);
public function exists($key);
}
class Keyed implements IKeyed
{
protected $values = array();
function __construct($key, $value)
{
$this->set($key, $value);
}
function get($key)
{
return $this->values[$key];
}
function set($key, $value)
{
$this->values[$key] = $value;
}
function exists($key)
{
return array_key_exists($key, $this->values);
}
}
class Tag extends Keyed
{
protected $name;
protected $value;
function __construct($name, $value)
{
$this->set('name', $name);
$this->set('value', $value);
}
function render()
{
return $this->get('name') . '="'
. $this->get('value') . '"';
}
}
$tag = new Tag('name', 'datune');
if($tag->exists('name')) echo $tag->render();
?>
To see if a TAG exists or if it has a key (?).
Now let's exchange every single instance of the word Tag with for example a button, or an image list, or a ini like config file etc...
$button->exists('search');
$imageList->exists('smile');
$config->exists('dbName');
Here I think looking at possible implementations helps to find the "most likely best suited" method names.
But as you can see, when DESIGNING an INTERFACE, there is no need to think about WHAT a certain method might return and what not, or whether it should return false or null.
I believe what needs to be focused on is to agree upon a common interface, which will allow us individuals to go nuts and implement a version of Keyed the way we think it should be, and then allows users(=other developers) to pick out of a repository whichever version they prefer.
If there is one thing I would love to see happen within this community then it would be to agree upon a fixed set of interfaces and truly push that forward and try to create a standard. (for starters a standard within this community, don't set out to be the next great thing trying to show pear how it should be, instead start simple, stay simple!)
-
Oct 3, 2005, 08:47 #273
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
OK, so we have:
1 vote for changing PHP's internals
1 vote for get/set/has
1 votes for get/set/exists
Well it's a start.Christopher
-
Oct 3, 2005, 08:54 #274
- Join Date
- Nov 2003
- Location
- Huntsville AL
- Posts
- 706
- Mentioned
- 4 Post(s)
- Tagged
- 1 Thread(s)
Originally Posted by datune
I'm wondering what the rest of the community thinks? Maybe we need to decide just what a PHP interface should be?
For myself, I just don't understand why you would not want to define boundary conditions. When I do:
$x = $request->get('something');
I really need to know what will happen if 'something' does not exist. Exception? ErrorTrigger? NULL?
The notion that each implementor should decide seem to eliminate any possibility of sharing classes based on interface support.
I actually reread the entire thread trying to figure out what happened to exceptions. There are over 30 posts in which exceptions were pretty much assumed. And then they went away.
It just seems to me that interfaces are contracts and not specifying what a method is supposed to do kind of makes the contract worthless.
-
Oct 3, 2005, 09:38 #275
- Join Date
- Feb 2002
- Posts
- 625
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
@ahundiak
Maybe we need to decide just what a PHP interface should be
It seems that you are not comfortable with the difference of an interface and it's actual body (implementation).
Here, let me help by quoting Bruce from TIJ:
An interface says, “This is what all classes that implement this particular interface will look like.” Thus, any code that uses a particular interface knows what methods might be called for that interface, and that’s all. So the interface is used to establish a “protocol” between classes. (Some object-oriented programming languages have a keyword called protocol to do the same thing.)
To make a class that conforms to a particular interface (or group of interfaces), use the implements keyword, which says, “The interface is what it looks like, but now I’m going to say how it works.”
For example, you ALWAYS expect get() to return false, HOW it computes it to be false you don't care about. That's what you are looking for, which has nothing to do with designing interfaces.
This hopefully clears things up
Bookmarks