SitePoint Sponsor

User Tag List

Page 9 of 13 FirstFirst ... 5678910111213 LastLast
Results 201 to 225 of 325
  1. #201
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think there are three main issues that we are trying to resolve here, so let me summarize what I think they are.

    1. What is the minimum implementation to define this interface. The question here is whether to include support for isset() and unset()? Or is there an extended interface?

    2. What does the inteface look like. This question is whether to support get()/set(), __get()/__set() (i.e. $o->prop = 'value', or getXxx()/setXxx()? Do we support one or several?

    3. What this interface is for. There are desires for everything from PHPBeans to a basis for lightweight containers to a simple abstraction of properties and arrays. What do we know and what do we really need?
    Christopher

  2. #202
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Re: discussion of Keyed vs. Properties. I'm fine either way. There was movement toward Keyed when I put the code together over the weekend, so that's what I went with. It does make sense, maybe not when read in every case as "Object implements Keyed", but when translated into English as "Object is Keyed" it works fine. I do like the fact that it would be much less likely to be in conflict with someone elses "Properties" iterator. One final thing in favor of Keyed, "StoreItem is Keyed" implies that it has the behavior of a Keyed object, while "StoreItem is Properties" implies that the StoreItem is just properties. Basically, Keyed implies a state of being while Properties implies being something.
    Well, it should be noted that it's more like "Object does Keyed".
    1. What is the minimum implementation to define this interface. The question here is whether to include support for isset() and unset()? Or is there an extended interface?
    My vote is for extended. As Marcus points out, it's _much_ easier to, for a number of reasons, add functionality via an extension mechanism than it is to remove functionality at a later date. Furthermore, by having an inherently lightweight base, you are free to extend at whim without carrying on someone else's pet peeve.

    I've successfully moved in, time to...ehm...get my books

    Regards,

    Tyler Tompkins

  3. #203
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    Errorhandling is like wearing a seatbelt, you can choose to wear it tight, or loose, or not at all. And we know what happens when you choose to not wear it all and and then something bad happens, but the law shouldn't enforce common sense, because it makes things more complicated and troublesome on some people than its worth.
    I don't see this effort as trying to define the law so to speak but rather as trying to come to agreement on what it means to support a specific interface. No one is made to support anything but I'm sure we all admit that agreeing to provide support implies certain obligations. Your point on getting overly complicated is well appreciated and I think arborint's last post does indeed sum up our current status.

    One last thing on __unset. __unset/__isset were not introduced initially with 5.0.x but were added in 5.1 (and late in the 5.1 cycle) -- that's a fairly long gestation interval. We can repeat that ommission but do we really have any reason to believe we won't later come to the same conclusion as to the need? IMO, the absence of these two callbacks is one of the reasons 5.0.x is a futile branch to be working with. At this point though, I think I've perhaps said too much on the topic. I'll leave it alone for awhile

  4. #204
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On __unset()/__isset() I am still wondering if these are the right thing to use just because PHP does it that way. Does unset($o->dbRow) make sense or should deleting be specific to the property like $o->dbRow->remove().

    Or to generalize that you would need to make every property an object with (for example) exists() and remove() methods. So you would do $o->myprop->exists() rather than isset($o->myprop)
    Christopher

  5. #205
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    Or to generalize that you would need to make every property an object with (for example) exists() and remove() methods. So you would do $o->myprop->exists() rather than isset($o->myprop)
    That's an implementation issue. Is your Keyed object an aggregate of other Value Objects? If that's the case, then $o->myprop->exists() might be a good idea. At that point, you're probably doing some fancy initialization on __get() anyhow to insure that it returns at least a blank object, so __isset()/__unset() aren't going to do much for you.

    It looks like there's only a few of us who are in favor of __unset(), and it also seems that those of us who are also realize that it can much more easily be added in later if it is as necessary as we think it will be.

    As for exceptions, I'm still planning on pulling specific mentions of them at this time.

    Once I get everything together, I'll post a copy here and of course it'll be in the SVN server.

  6. #206
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    It looks like there's only a few of us who are in favor of __unset(), and it also seems that those of us who are also realize that it can much more easily be added in later if it is as necessary as we think it will be.
    Easily? It is going to be a PITA since it will make type hinting that much less useful. :'( Oh well, I tried my best.

  7. #207
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Would benefits would you say type hinting can provide?

  8. #208
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Easily? It is going to be a PITA since it will make type hinting that much less useful. :'( Oh well, I tried my best.
    I read back though the thread and the responses for _isset()/__unset() and even _get()/__set()/__call() . It seems that those for a magic interface want to do specific things in the implementation. I assume that this is from experience. For example the above comment that not having __unset() makes type hinting difficult.

    Many of the comments have been unspecific. For example the above comment does not say _how_ it makes type hinting difficult, nor allows others to offer other possible solutions (which may or may not be better). I think it might make sense to hear more specifically why going certain directions with the interface will be a better choice for implementations. Perhaps even some prototype implementaions to show the advantages and disadvantages of, for example, $o->xxx = 'value' vs $o->set('xxx', 'value') vs $o->setXxx('value').
    Christopher

  9. #209
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Easily? It is going to be a PITA since it will make type hinting that much less useful.
    How so? You can rely on the JBKeyed interface if you need to have __unset() and Keyed where it's not necessary. Once we move to having __unset() as part of Keyed or having a more specific version of Keyed with __unset(), grep -Rn until all the JBKeyeds are gone. Not an elegant solution, but I think Marcus is right, we need to keep everything out until it's been proven necessary. As we're working for everybody's "necessary", sometimes things will have to evolve at a slower pace.

    Again, I think it's worth nothing that that JSR-170 took nearly 3 years to develop into what it is now. I'm sure those more familiar with Java could cite similar cases where things that seem like they could be whipped up in a few days or weeks time took months or years to evolve into what they are now. Look at it this way: we've got our first community based standard interface on the way

  10. #210
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Would benefits would you say type hinting can provide?
    It has to do with generic handlers. If I typehint on the extended interface I expressly won't be able to recieve the base interface. If I typehint on the base interface, I'm going to have to switch in my code to see if I can safely call a method (__unset) and get uniform behaviour -- which really makes me wonder what the point of an interface is. Moreso, because implements is polymorphic, the "extended" interface may not even be an extended interface but rather just another interface with the additional methods meaning you might implement several interfaces on a class. This suggests that I will need to resort to using is_callable and I'm right back to where I was before interfaces.

    Never-the-less, I really don't think I should be arguing the point anymore at this time -- I don't think it is productive. Maybe I'm the only one who cares about doing things that way -- I can respect the decisions being made (it may indeed lead to other solutions that I am having trouble seeing at the moment) and I know that I don't have to support these particular interfaces if I don't find them appropriate for my case.

    One thing I would suggest though: whatever names are chosen for the interfaces, it may be prudent to consider not using generic names but rather prefix them with the standard's project name. Others may want to use Keyed or Properties (or whatever) in their own projects without stepping on (or being stepped on) by the "standards" naming.

    Best regards.

  11. #211
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    McGruff,

    You've asked this question before, for example (I hate to make a quote from another, older thread, but...)

    The only time I've felt I needed to check the class type of a passed-in object was to distinguish between two classes with the same interface: one would silently do some authorisation checks, the standard class does not.
    http://www.sitepoint.com/forums/show...8&postcount=13

    With Interfaces and Type Hinting you do not need to make that distinction. Here is what I was reading a while back, whilst trying to get a grip on the benifits of using Interfaces, et al

    Proves a very insightful read

    http://www.javaworld.com/javaworld/j...erface-p2.html

    If that doesn't convince you of the benifits, then I don't know.

  12. #212
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm open to ideas about why type hints might be useful in php in general but this isn't the place to discuss that beyond what they might bring to Keyed.

  13. #213
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    It has to do with generic handlers. If I typehint on the extended interface I expressly won't be able to recieve the base interface. If I typehint on the base interface, I'm going to have to switch in my code to see if I can safely call a method (__unset) and get uniform behaviour -- which really makes me wonder what the point of an interface is. Moreso, because implements is polymorphic, the "extended" interface may not even be an extended interface but rather just another interface with the additional methods meaning you might implement several interfaces on a class. This suggests that I will need to resort to using is_callable and I'm right back to where I was before interfaces.
    Here's what I would do, Jay: over the next few weeks work with the interface that we come up with and document the use cases where having __unset() is valuable. I'll be doing the same as I can. I think the that is going to be the key to adding to any extra methods to any of the interfaces.

    Quote Originally Posted by jayboots
    Never-the-less, I really don't think I should be arguing the point anymore at this time -- I don't think it is productive....
    I think you're right - but I think it's true of anything said for or against the interface right now. We need to see it in the wild. Will it be useful? What's missing? What isn't getting used? This has been a learning process for me, and hopefully this will help make the process of identifying and outlining future interfaces an easier task.

    I am going to try my hardest to have this interface ready for final approval tomorrow. I'll post it when I have it ready.

  14. #214
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    It has to do with generic handlers. If I typehint on the extended interface I expressly won't be able to recieve the base interface. If I typehint on the base interface, I'm going to have to switch in my code to see if I can safely call a method (__unset) and get uniform behaviour -- which really makes me wonder what the point of an interface is.
    This is interesting. And three things occur to me as I read it:
    1. Type hinting seems to require a higher level of standardization.
    2. A similar situation would be easier to handle in Java with method overloading.
    3. It really has nothing to do with type hinting. It's much simpler; the real problem is that you want to use a certain behavior (__unset), and that means you can't plug in a component that doesn't have that behavior.

    Ooops, I guess (3) contradicts (1).
    Last edited by dagfinn; Sep 21, 2005 at 00:43.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #215
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    Here's what I would do, Jay: over the next few weeks work with the interface that we come up with and document the use cases where having __unset() is valuable.
    That seems like a smart thing to do. Or even make it a "version 1.1" thing. Considering the fact that we are targeting people who are not necessarily following this discussion, the first thing we want is to encourage uptake. We want to avoid people turning away because it seems unnecessaritly over-designed. It's possible to publish both interfaces and make it entirely up to component developers which one to use. And then, when and if there is a strong consensus that the extended interface is better (and real use cases to show why), then there can be a strong recommendation to implement it.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  16. #216
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    For the extended interface (assuming we end up with one) we should consider having a "get_value_or_use_default_if_property_does_not_exist" method.
    $value = $props->getSomeNameWeCanArgueAbout($name,$defaultValue = FALSE)

    I know the internals have had discussions on this though I don't see anything in PHP 5 as of yet. Having such a method partially eliminates the question of what to do when a property does not exist.

  17. #217
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In reference to the __isset() discussion I noticed something interesting on a page that tests what different variables return in PHP. The interesting thing is that $v = NULL; and unset($v) both return isset($v) == false. Same with arrays. That means that in some implementations you would need to resort to array_key_exists() or something like that to get the behavior that some people seem to want.

    The variable test chart page is at:

    http://www.deformedweb.co.uk/php_variable_tests.php
    Christopher

  18. #218
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    In reference to the __isset() discussion I noticed something interesting on a page that tests what different variables return in PHP. The interesting thing is that $v = NULL; and unset($v) both return isset($v) == false.
    Yeah. Annoying, isn't it ?

    We should certainly agree on whether NULL is an actual value or not. Does $dataspace->set('key', NULL) imply $dataspace->unset('key')

  19. #219
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    unset() shouldn't return anything, its a construct/void/function in php4+ versions. (in fact if you try to get a value, you should be getting an error) but yes isset() does return false on any variable that is null.

    however it depends on what you are using isset() for, are you using isset to check the value of a property in a loosely typed lanuage that uses nulls, or are you checking to see if the property exists?

    because you do not have to check to see if the actual property has a value if you are using metadata in a way to define what public/protected properties a class has.
    Last edited by mx2k; Sep 23, 2005 at 11:08.

  20. #220
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Yeah. Annoying, isn't it ?
    Not really.

    If NULL means _not_ set as it appears to logically do, then $dataspace->set('key', NULL) is the same as $dataspace->unset('key'), and $dataspace->get('key') != NULL is the same as $dataspace->isset('key'). That simplifies the interface to get()/set().
    Christopher

  21. #221
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    however it depends on what you are using isset() for, are you using isset to check the value of a property in a loosely typed lanuage that uses nulls, or are you checking to see if the property exists?
    Since we are talking about PHP, those two things are apparently the same.
    Christopher

  22. #222
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    And at least under PHP 5:
    PHP Code:
    $a NULL;
    if (isset(
    $a)) echo "A is set\n";
    else           echo 
    "A is not set\n";
    echo 
    $a;
    echo 
    $b
    Yields:
    A is not set

    Notice: Undefined variable: b in C:\ahundiak\step\eclipse\part21\Part21.php on line 181

    So while $a is not set it IS still defined. If you unset($a) then you get an undefined notice. So $a=NULL is not exactly the same as unset($a)

  23. #223
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak
    So while $a is not set it IS still defined.
    Appearently the zend-developers couldn't agree on what the meaning of "being set" is. It's a matter of preferences if the one or the other may feel more correct, however mixing the two meanings together is rather confusing. I think it's a mistake that they didn't choose one and stuck with it.

    Ultimately I think it's a natural conclusion in a loosely typed language,would be that NULL == undefined. To avoid confusion, I would prefer IDataSpace to abide to this rule, rather than trying to distinguish between the two situations. But above all, I would want to stick with one, and only one, of the meanings.

  24. #224
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Since we are talking about PHP, those two things are apparently the same.
    depends on your implementation.

    you could have an array of setters & getters and other metadata to see if a property exists. rather than checking a property's value to see if it exists or is set.

  25. #225
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    depends on your implementation.

    you could have an array of setters & getters and other metadata to see if a property exists. rather than checking a property's value to see if it exists or is set.
    I don't think it matters how it is implemented internally. It is whether the interface is:
    PHP Code:
    // no magic
    $o->set('xxx'NULL);

    // or with __call()
    $o->setXxx(NULL);

    // or with __set()
    $o->xxx NULL;

    // or with __unset()
    unset($o->xxx); 
    The same variations go for isset() except rather than passing or assigning NULL it is:
    PHP Code:
    // no magic
    $o->get('xxx') == NULL

    // or with __call()
    $o->getXxx() == NULL;

    // or with __set()
    $o->xxx == NULL;

    // or with __unset()
    isset($o->xxx); 
    Christopher


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •