SitePoint Sponsor

User Tag List

Page 10 of 13 FirstFirst ... 678910111213 LastLast
Results 226 to 250 of 325
  1. #226
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    // or with __set()
    $o->xxx = NULL;

    // or with __unset()
    unset($o->xxx);
    Actually, I see these as different.

    $o->foo = null;
    if ($o->foo) { // no error}

    unset($o->foo);
    if ($o->foo) { // error }

  2. #227
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aborint
    I don't think it matters how it is implemented internally. It is whether the interface is:
    to me it does, but it concerns me that depending on how you have set up properties, you can unset a property, which can cause issues and just doesn't seem right. i see
    unset($x->Property); being different than $x->Property = null as jayboots pointed out above.

    the isset()/unset() symbolizing opposites is misleading. isset is checking to see if the variable is not null, while unset, doesn't make a variable null, it completely destroys the variable. and completely destroying a property of a class.. my question is, does this make sense to destroy a property of a class...?

    thats been my concern with __unset() being placed with a properties interface, now __unset() could make sense in a collections interface where you would want to clear the collection or an item. but thats just me.

  3. #228
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    to me it does, but it concerns me that depending on how you have set up properties, you can unset a property, which can cause issues and just doesn't seem right. i see
    unset($x->Property); being different than $x->Property = null as jayboots pointed out above.
    My question is: do people think avoiding the error condition as a positive? I think I do for properties.

    Quote Originally Posted by mx2k
    the isset()/unset() symbolizing opposites is misleading. isset is checking to see if the variable is not null, while unset, doesn't make a variable null, it completely destroys the variable. and completely destroying a property of a class.. my question is, does this make sense to destroy a property of a class...?
    I see unset() and the undefined state of vars as artifacts of the memory manager of PHP. Do we want to embrace that artifact or always present NULL?

    Quote Originally Posted by mx2k
    thats been my concern with __unset() being placed with a properties interface, now __unset() could make sense in a collections interface where you would want to clear the collection or an item. but thats just me.
    I think collections, database record sets, etc. would probably be better off with explict methods (like delete() or remove() ) rather than using unset() or setting to NULL to remove and item/row.
    Christopher

  4. #229
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Quote Originally Posted by arborint
    My question is: do people think avoiding the error condition as a positive? I think I do for properties.
    But for properties shouldn't unset($o->foo) throw (or raise) an error under the current definition that is being considered since it would be an illegal operation? By the same token, attempting to access a non-existant property should result in an error condition AFAIC.

    Quote Originally Posted by arborint
    I see unset() and the undefined state of vars as artifacts of the memory manager of PHP. Do we want to embrace that artifact or always present NULL?
    I don't think it is about the memory manager. Null is a real value. The difference between testing for null and using isset is that isset supresses existance errors. Otherwise how can we distinguish a null value in PHP? That said, if you are saying that the default of a legal property should be null, then I agree. Yet that's what it would be anyhow, not? Maybe this is moot since we __unset isn't in the base interface.

    Quote Originally Posted by arborint
    I think collections, database record sets, etc. would probably be better off with explict methods (like delete() or remove() ) rather than using unset() or setting to NULL to remove and item/row.
    Obviously I don't think setting to null should be considered as an unset operator. I also would like my collection containers to support unset() for removal of items ... but maybe this line is straying from the current focus of properties.

  5. #230
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    But for properties shouldn't unset($o->foo) throw (or raise) an error under the current definition that is being considered since it would be an illegal operation?
    So if I my goal is to unset a property and it is already "unset" so my goal is met, I should get an error?
    Quote Originally Posted by jayboots
    By the same token, attempting to access a non-existant property should result in an error condition AFAIC.
    Why an error for normal access if the value NULL exists. It seems like if you are interested in the "defined?" (to borrow from Ruby) then you should have a way to check for that, but for normal access NULL seems like it makes more sense than an error.
    Quote Originally Posted by jayboots
    I don't think it is about the memory manager. Null is a real value. The difference between testing for null and using isset is that isset supresses existance errors. Otherwise how can we distinguish a null value in PHP? That said, if you are saying that the default of a legal property should be null, then I agree. yet that's what it would be anyhow, not?
    Well I think it is a memory manager artifact because vars start out as undefined which is just like NULL except it produces Notices. That may or may not be interesting to code inside a Properties/Keyed class, but outside think it should all look like NULL.
    Christopher

  6. #231
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    So if I my goal is to unset a property and it is already "unset" so my goal is met, I should get an error?
    I suppose it is fine to do nothing since __unset isn't in the base interface anyhow. If there is an extended interface that includes __unset, we may want to think of its behaviour separately. OTOH, what does it mean for a user to try to unset a property that can't be removed but can have a null value? It seems to me that you are proposing it should be set to null -- but that would mean implementing __unset...and I'm not going there There's a corollory as well: can a user add a property to these objects and if so how? By simply accessing or setting an unset property? I would think that that goes against the spirit of the interface.

    Quote Originally Posted by arborint
    Why an error for normal access if the value NULL exists. It seems like if you are interested in the "defined?" (to borrow from Ruby) then you should have a way to check for that, but for normal access NULL seems like it makes more sense than an error.
    I agree. I said non-existant property. Existant properties ought not throw errors on access even when null; we also have __isset in the interface to test if a property is supported rather than determining its value. I think we are probably arguing the same point on this one.

    One thing that bothers me: I can't help but think of properties as a subtype of collection but it seems that that is not what we are doing here.

    Best Regards.

  7. #232
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    subtype of collection
    subtype of a collection class? just curious as of your mindset, why does properties register as a subtype of a collection?

  8. #233
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by mx2k
    subtype of a collection class? just curious as of your mindset, why does properties register as a subtype of a collection?
    That's a surprising question, really. A very base reason is that they are almost always implemented as a hashtable (as in Java) which is nothing but an array in PHP or an ArrayObject in PHP 5. The main difference is that Properties (in Java) are typically considered persistent and are typically expected to be string values. Never-the-less, hashtable is a Collection in Java and more notably it is Collection that is a defined interface and not Properties which is only a sub class (at least in 1.4).

    Then there is also PropertyBag which some environments support and which some of our work sometimes touched on. I've seen alternative definitions for these but this one is not too far off what I most commonly see: http://support.sas.com/rnd/appdev/V2...opertyBag.html which at least provides means for adding/removing properties and sending events on value changes.

    Increasingly I think that Properties is not a very useful interface to have. Our definition will not help me exploit PHP 5.1's most unique features and if anything, threaten to limit them. It does not seem to make any attempt at clarifying the role of the magic methods in terms of providing automated get/set behaviours on a per property basis. In fact, our definition doesn't seem to do anything at all compared to a straight hash except for adding a global eventing on property change -- which is good but is also being perverted for certain cases instead of being treated generally and then refined for particular uses. Basically, I'm starting to think we took a wrong turn.

    I'm also curious. What definition of properties have you seen that did not derive from a collection?

  9. #234
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Increasingly I think that Properties is not a very useful interface to have. Our definition will not help me exploit PHP 5.1's most unique features and if anything, threaten to limit them.
    What unique features of PHP5.1 do you want to use? And how are they being limited?
    Quote Originally Posted by jayboots
    It does not seem to make any attempt at clarifying the role of the magic methods in terms of providing automated get/set behaviours on a per property basis. In fact, our definition doesn't seem to do anything at all compared to a straight hash except for adding a global eventing on property change -- which is good but is also being perverted for certain cases instead of being treated generally and then refined for particular uses. Basically, I'm starting to think we took a wrong turn.
    I think there is a confict here between those who want a powerful interface where they see a need and those who want a simple interface where they see the lack of any standard.
    Christopher

  10. #235
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    What unique features of PHP5.1 do you want to use? And how are they being limited?
    Well for me, the non-inclusion of __unset and the talk of changing PHP default behaviour is troubling to say the least -- particularly at the interface level as opposed to an abstract class. There is also the missing notion of dealing with the event system (__get/__set) in a parametric manner. Then there is the recently introduced but now pervasive idea in this thread that a specific use case should pattern the general case dwhen that in itself does not consider the general case. As for what I want to use it for, I've already elaborated on the type of things I am interested in so I see no reason to repeat them.

    Quote Originally Posted by arborint
    I think there is a confict here between those who want a powerful interface where they see a need and those who want a simple interface where they see the lack of any standard.
    Can you be more concise? What does "simple" mean to you as opposed to "powerful"? I want useful things that can be deployed over wide ranges of problem areas. As for standard interfaces should they not begin -- or at least have a nod -- towards the more general interfaces from which they would logically derive? Shouldn't our standards be general enough to cover wide usage? To put it another way. Perhaps we should have listened to some of the more general structural ideas that were raised in the thread concerning the investigation and logical deconstruction of components rather than picking a favoured class type to start our efforts at. You guys might be happy with the results but I can say that I am less so. Just an honest opinion, FWIW.

  11. #236
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Shouldn't our standards be general enough to cover wide usage?
    Nope

    But just how general are we talking about? If you are too general then you are going to have a bloated interface, which is not what you want. If you want my view, you got to keep your interface lean.

    If at a later date, you learn that there is more required, you can either extend (first choice), or have the class that implements the interface, implement another interface(s).

    But if you find that you need to implement more than 2 interfaces, then something has gone wrong, but you've not got that far into the discussion as far as I see it. Your all still arguing about technicalities, and to be honest, it looks like this discussion isn't going to go any further than that

  12. #237
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    [QUOTE=jayboots] I'm also curious. What definition of properties have you seen that did not derive from a collection?[\QUOTE]

    well you have to understand that i come from mostly a html/xhtml/css background, moved into php in order to keep things maintainable, and then ended up at a new business which works in nothing but dot net., so my experiences have been in php and dot net.

    with properties i see them as descriptors of an object, like $person->EyeColor = 'blue';
    $firstCartItem = $customer->ShoppingItems[0];

    so java i'm not too familar with, but in other languages hash tables are similar to collections except you define the key name and a couple of other minor differences.

    i'm at the point rather than just discussing in a forum, maybe create a forked project, with different implentations, and maybe two small apps to see how well those applications can be interwoven by using combinations of interfaces. Application often
    points out flaws that might not otherwise not be seen. and help build a consensus, and that way we can see the different ways various interfaces might be used.

  13. #238
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    If you want my view, you got to keep your interface lean.
    A few people have said either that or "slim". What is the definition of these terms, technically speaking? How does it categorically improve an interface? My first foray into this thread was to question the inordinate amount of methods that were being proposed in the interface so I do not think I am talking about bloating things. I'm talking about not missing key factors that are important to catch general needs which can then be refined into particular usage patterns. Interfaces are the most general of all class types so I think that is appropriate. Unfortunately, we seem to have an interface discussion that is really revolving around abstract class concepts if not concrete classes. Why? I'm suggesting that it is because Properties is actually not general enough to be an interface.

    If at a later date, you learn that there is more required, you can either extend (first choice), or have the class that implements the interface, implement another interface(s).
    You mean if we fail to understand the issues now we can just patch later? That's not design. We should discuss the generalities so that we can avoid patch work. We have time, yes?

  14. #239
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    A few people have said either that or "slim". What is the definition of these terms, technically speaking?
    It was my mistake for saying "simple." I meant minimal. That is what some are striving for. The minimum that most can agree on.
    Quote Originally Posted by jayboots
    You mean if we fail to understand the issues now we can just patch later? That's not design. We should discuss the generalities so that we can avoid patch work. We have time, yes?
    I don't claim to understand all the issues, that's why I am still involved in this converstation -- to learn.

    It is my impression that there are a couple of groups involved here. Travis_S already has a full concept of what he wanted, so we are forcing him to massively rewind (and he has been a good sport about it). Likewise selkrik and illusina have fully formed public frameworks that they come to the discussion with (and have probably gone off to sort out some common interfaces for). Most others are of the build-your-own school and are looking for more code reuse and standards.
    Christopher

  15. #240
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm talking about not missing key factors that are important to catch general needs which can then be refined into particular usage patterns.
    You are attempting to have an interface that catches everything. When one class implements this interface, it is being specific enough, for that given class. But at the opposite side of it, another class that would implement this interface is not specific enough, so you end up giving that interface more freedom...

    But then the first scenario the class that implements this interface would have to implement more that what it really should be implementing. I get the feeling that in this case, you are looking at two interfaces.

    By being lean or slim I would like to think that an interface has fewer have 3 or 4 public declarations, at most. Looking at some Java interfaces, which declare a dozon -or more - public declarations makes me look away for some reason.

  16. #241
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Regarding uset() being different from set(null), one example is a database row update. If you are setting a field of the update to be null, that update will then affect the row in the DB when it's executed. If you went unset() then that part of the update has dissappeared. Not the same thing at all.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  17. #242
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Regarding uset() being different from set(null), one example is a database row update. If you are setting a field of the update to be null, that update will then affect the row in the DB when it's executed. If you went unset() then that part of the update has dissappeared. Not the same thing at all.
    The problem is that according to PHP both undefined vars and vars set to null return false to isset(). It seems that both do the same thing, but one produces a warning.

    So to use that criteria you would need to implement an error handler to trap the 'Var not defined. ' errors. If it's that much trouble to do something simple, I would prefer to explicitly track whether records should be updated by tracking whether changes have been made rather than depend on unset()/isset().
    Christopher

  18. #243
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    You are attempting to have an interface that catches everything. When one class implements this interface, it is being specific enough, for that given class. But at the opposite side of it, another class that would implement this interface is not specific enough, so you end up giving that interface more freedom...

    But then the first scenario the class that implements this interface would have to implement more that what it really should be implementing. I get the feeling that in this case, you are looking at two interfaces.
    Well, not exactly. What I am after is an interface that captures the meaning of "Properties" in a fundamental and generic way. Otherwise it is not a Properties interface, is it? My view has been that this must include the notion that properties can be added and removed from a collection (the difference between my view and the current one is a single method) and I have stated that I don't see the merit in an interface that captures a certain type of properties as a fundamental unit; I'm also leaning towards the opinion that I am in this quandry because I don't see properties as a fundamental interface and we haven't really had a thorough discussion of when, where and how interfaces might be used. For example, many of the points that have been raised in the last few pages are worthy of abstract classes and it would seem more appropriate for the concrete classes being discussed to extend the abstracts rather than directly implement the interface. This has a huge impact on how we view the interface in terms of what it should include.

    Quote Originally Posted by Dr Livingston
    By being lean or slim I would like to think that an interface has fewer have 3 or 4 public declarations, at most. Looking at some Java interfaces, which declare a dozon -or more - public declarations makes me look away for some reason.
    This sounds arbitrary to me. I can appreciate the desire for conciseness and compactness (I share it!) but I think we should be open minded when interesting ourselves with modeling salient characteristics. There is not much you can describe with 3 or 4 methods -- for some purposes it is bound to be adequate but I can't see the logic in making that a hard and fast rule.

    Greetings.

  19. #244
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well there is no hard and fast rule to the amount of behaviour (the word I was looking for earlier) in an Interface, but minimalistic in real terms is better, than trying to capture more than what is adequate?

    By real terms I suppose I mean that if you can get away with 4 public methods declared in an Interface, then do so but if your edging on the idea that there may be another 2 public methods, use a separate Interface if possible.

    So you don't just have the one Interface to 'fit all' which is not really what you want either. As to your earlier point (quotation from above post) I think I've missed your point or what you were trying to get at.

    You mean if we fail to understand the issues now we can just patch later?
    Not really. Your still at the design stage at that moment. But on the other hand, if you realise one Interface is not suitable, you can adapt it via the Adapter pattern which suits most situations at some point in the future.

    Depends I suppose on just how fast and by how much your scripts change. If they change often then obviously the Interfaces are not going to settle down, but that's just my view on it all.

  20. #245
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    My view has been that this must include the notion that properties can be added and removed from a collection (the difference between my view and the current one is a single method)
    There are a number of different, but closely related interfaces here. If we take them together does it help in designing them? Here are some rough examples of some interfaces. My goal was not to propose these exact interfaces, but just to show the variations. And to prompt questions like: Would you want Collection or List to implement Properties?
    PHP Code:
    interface Properties {
    get($name) {}
    set($name$value) {}
    }

    interface 
    Collection {
    get($name) {}
    add($name$item) {}
    remove($name) {}
    }

    interface List {
    get($index) {}
    add($item) {}
    insert($index$item) {}
    remove($index) {}

    Christopher

  21. #246
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Travis, what's the current state of play for Keyed?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  22. #247
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Travis, what's the current state of play for Keyed?
    Here in a few hours I'll have an RC Last week was hectic for me followed by five days out of town. I'm just getting caught up on this thread.

    Jay - regarding unset(), I see your points, but I think we're going down the right path by not including it... at least at first. I justify this by asking a simple question: will the interface absolutely not work if we don't included __unset()? My answer is no, because all Keyed needs to do is be able to have values. To do that, you need to be able to set(), get(), and check to see if something isset(). unset() is an extra. In your use, it would be a necessary extra, but in a more broad sense, I believe it's a plain extra. As far as this being a "patch" if we add it in later, I don't think so. As Marcus has said here and many times before, we can add more later if we need it, it's harder to pull it out.

    As for the discussion of unset() versus $value = null, that's really something that should be left up to the implementor. Personally, I believe the discussion of errors on unknown value types don't belong in isset(), they belong in get() which would have been called after a false isset().

  23. #248
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    Here in a few hours I'll have an RC Last week was hectic for me followed by five days out of town. I'm just getting caught up on this thread.
    Ok... It's ready to go...

    You can get it from the SVN repository (recommended, as upgrading can be accomplished via "svn switch"):

    svn co https://svn.opensir.org/svn/tags/v0.1/ opensir

    Or if you just want to download the archive:

    https://svn.opensir.org/svn/tags/opensir-0.1.tar.bz2
    https://svn.opensir.org/svn/tags/opensir-0.1.tar.gz

  24. #249
    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)
    Code:
    opensir-0.1/src/opensir.library.php
    Isn't that a needless implementation-detail ? People should manage include-paths themselves, I think.

  25. #250
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    Code:
    opensir-0.1/src/opensir.library.php
    Isn't that a needless implementation-detail ? People should manage include-paths themselves, I think.
    A case could be made for that, however, as opensir grows it will need a uniform way for files to locate other opensir files internally so it can satisfy dependencies. One big thing I have against PEAR is it's requirement that code be placed inside the include_path. To keep from requiring that, we have to define a constant and we'll need one central location to store it - thus opensir.library.php.

    I named it library, as it provides an entry point for the library from the outside world. As the docs mention, it's entirely optional. You're more than welcome to call "include '/path/to/Keyed.interface.php';", which will go ahead and call the file to insure it knows how to communicate internally.


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
  •