SitePoint Sponsor

User Tag List

Page 5 of 13 FirstFirst 123456789 ... LastLast
Results 101 to 125 of 325
  1. #101
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    To emulate something like [level][easy] simply do key = "level.easy";
    You may be able to emulate uniqueness of key, but you cannot emulate depth and hierarchy that way. What if I want to get back an array of all my levels?

    PHP Code:
    $game['levels'][] = 'easy';
    $game['levels'][] = 'medium';
    $game['levels'][] = 'hard'
    It is not using them as namespaces that I think is so useful about _get and _set, its the ability to use complex object hierarchies as though they were native PHP arrays, both for "setting" as well as for "getting".

    (BTW, I am just assuming here that PHP5's _set and _get have the ability to cope with deep property access like above, I've never actually tested it)
    Garcia

  2. #102
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ghurtado, you can't chain property accesses if any but the last element in the chain results in a call to __set.

    $obj->game->level = 10; // Does not work if the game property of obj is virtual.

    With a setViaPath() method, you can.

    illusina,
    Here is an example of how I'm using this in WACT.

    A fragment from the model:
    PHP Code:
    class HangmanGame extends AttributeBasedDataSourceSupport {
        var 
    $level 
    A fragment from the controller:
    PHP Code:
    $gameController->addParameter(new GetParameter('level''game.level')); 
    The 'game.level' binds the input _GET parameter 'level' to the level property of the game object. SetViaPath() is useful in these input bindings.

  3. #103
    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 Selkirk
    Ghurtado, you can't chain property accesses if any but the last element in the chain results in a call to __set.

    $obj->game->level = 10; // Does not work if the game property of obj is virtual.
    I think you're wrong. I just tested it, and it seems to work.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  4. #104
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Something like:
    PHP Code:
    echo $data->getViaPath('levels.easy'); 
    is no different than:
    PHP Code:
    $data->levels['easy']; 
    Actually I think that there is a big difference these to styles. The second assumes that 'levels' is an array, but the first makes no such assumption of how it is implemented internally. And I know from experience of building and using DataSpace containers that I want the ability to abstract it. It also could be something like:
    PHP Code:
    $data->levels->easy;
    // or
    $data->context[$current]->levels['easy'];
    // or
    $data->find("SELECT * FROM levels WHERE difficulty='easy'"); 
    Christopher

  5. #105
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I should have code highligted the style I personally prefer, namely: $game->level->easy. That makes all access uniform and means that $game doesn't have to know how actually get to "easy" (or even know it is there) -- it only has to know about "level" which then surfaces "easy". Then again I vaguely recall running into a variation of this problem at some point:
    you can't chain property accesses if any but the last element in the chain results in a call to __set.
    but I'm afraid that I've experimented with so many styles recently that I have lost track of how it actually arose. oops.

    There is clearly something to be said for dot-notation and I think it deserves more attention but since it isn't surfaced to the language I think it still represents a different type of overhead while looking a little bit artificial (not the dot-notation itself, just the fact that it is stringified and could require lots of knowledge in a top level object about lower level paths).

    To beat the dynamic horse a bit more and as a possibly extreme example of intercepting, in one experiment I've virtualized all object behaviour by routing every magic method through __call which then dispatches through a held object (so the entire public interface of the object must be implemented virtually). This way it is possible to even virtualize the magic handling -- for example, I can have a stack of held objects and have __call dispatch to each in turn (or until bailout). Yet with a little bit of logic in __call I can change that behaviour at runtime by swapping in (or adding or removing or even ignoring) held dispatch objects. Behaviour is thus completely dynamic and intercepted calls (including all the property calls) see the container (and all of its virtual properties and methods). Parametric? Polymorphic? Why not? I wouldn't mention it as it is still a little sketchy and in all honesty I'm not really convinced it is entirely valuable compared to a more straight-forward approach (I had to write a function to pretty-up the backtrace as the indirection accumulates calls quickly) but the discussion seems to be lending itself in that way, at least at the moment . I can post a skeleton of one of the experiments if someone thinks it is interesting enough (well, I think that ghurtado might be interested).

    I'm rambling so I think I should instead pause and take time to listen to and consider all the other points being raised in the discussion.

    Greetings.

  6. #106
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is this the process that's supposed to take 500 million years? In that perspective, the fast pace of this thread seems not strictly necessary. Is someone trying to break the lightspeed barrier?

    Seriously, this happens all the time in this forum. But my problem is that I prefer to think about large design issues for a while before responding. But it's hardly possible here, so let me just put down a couple of the ideas that occur to me.

    Marcus is right. Keeping the ambition level down is critical. It might be more realistic to have slow convergence of frameworks in the direction of similar interfaces rather than some "standard" that everyone will be expected to follow. The discussion that's going on here is meaningful anyway of course.

    I'm thinking in terms of Eric Evans' Domain-Driven Design. The book uses the concept of "knowledge-rich design". It occurs to me that the knowledge in a technical software domain can be as difficult to get at as the knowledge in a non-software domain (cargo shipping is one of Evans' examples). As Marcus points out, there are few experienced framework developmers.

    Then there's another concept from Evans: refactoring to deeper insight. How do we know that the conceptual model embodied in a set of interfaces is stable enough to survive over time without preventing refactoring to deeper insight?

    Selkirk's template example is illuminating: it's not just about flexibility, it's also about the fact that a standard template engine has a least three different responsibilities: keeping data, combining the data with the actual template, and handling files. So it's conceptual as well as technical.

    This may be too philosophical, at least for those who haven't read Evans. I hope it makes sense.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  7. #107
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How about applying the Tracer Bullet principle to the whole idea? Define a single interface (or a small set for one purpose) and try to make a couple of frameworks interoperate by using it before going any further in defining "standards"? Proof of concept.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  8. #108
    SitePoint Addict chiefmonkey's Avatar
    Join Date
    Aug 2002
    Posts
    207
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would certainly be interested in helping, although I have more of a Java background than PHP (that may help or be a hinderance)

    George
    Got Sig!

  9. #109
    SitePoint Guru dbevfat's Avatar
    Join Date
    Dec 2004
    Location
    ljubljana, slovenia
    Posts
    684
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    How about applying the Tracer Bullet principle to the whole idea? Define a single interface (or a small set for one purpose) and try to make a couple of frameworks interoperate by using it before going any further in defining "standards"? Proof of concept.
    This could be very interesting. And the DataSource interface is just the place to start, I believe. Could be adapted to frameworks like Mojavi and Wact, and on the other hand to template engines like Smarty.

    I'll start:
    PHP Code:
    interface DataSource
    {

    j/k

    I am serious about this being a good idea, though.

  10. #110
    SitePoint Wizard DougBTX's Avatar
    Join Date
    Nov 2001
    Location
    Bath, UK
    Posts
    2,498
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    convergence of frameworks
    Has anyone made a list of common functionality between the PHP frameworks in question?

    See what we want to do in each framework, then work out how we want to do them.

    Douglas
    Hello World

  11. #111
    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
    To beat the dynamic horse a bit more and as a possibly extreme example of intercepting, in one experiment I've virtualized all object behaviour by routing every magic method through __call which then dispatches through a held object (so the entire public interface of the object must be implemented virtually).
    Two things, completely off-topic... First, isn't that like a Mock of sorts? Second, why not just use DI or some home grown manager and swap out the objects before you load them? That seems like very dangerous water to be treading on...


    Back on topic... I didn't think you could chain together __get() methods, but I was wrong:
    PHP Code:
    class {
        public function 
    __get($key) { return $this->$key; }
        public function 
    __set($key$value) { $this->$key $value; }
    }

    $a = new A();
    $b = new A();
    $b->txt "Hello World!\n";
    $a->$b;
    echo 
    $a->b->txt
    Works just look you'd expect. And apparently, they have been adjusted (as of 5.0.4 to allow you to use array access as well. If you hide txt in an array (associate or numeric) you can pull it out. This was actually one of my stumbling blocks with using the magic methods - I distinctly remember arrays choking on them at some point in the past. Maybe I was thinking of __call().


    Ok - so what do we want to name this? I've seen DataSpace, DataSource (which to me implies that it knows how to set itself up), Node (which implies others to me, probably by virtue of the way I've worked with it), ValueContainer, Values, ComonentValues... did I miss any? I think it's far to say that if there's a common name out there we can latch onto, that much the better as people will more easily recognize it. Another thing to keep in mind is name collisions.

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

    Regarding the tracer bullet comment from dagfinn, that is my thinking as well. I think a Properties/Map/KeyValues class is a good test of the feasability of a project. After all, if you cannot standardise a configuration file or a database row, the project is dead in the water.

    Sorry Jeff, but I think the following is your fault...

    Your simple starting interface has suddenly grown into something that can be dropped in to a template. This is a hell of a complex problem and massive feature creep. You can drop any data structure into a template . You are going to have an inteface for any data structure? There already is one, it's called XSchema. Still want one?

    Also the performance argument is a bit lame for dictating the interface. If you want something fast than just add an asHash() method (you'll need one anyway) and then do the key look-up on the resulting array. Do that within a dynamic proxy (Travis - that was the pattern you were after) to get member access if you want performace. If you eschew method look-ups then you break reflection and you won't have any methods for your interface to enforce anyway.

    Another thing missing is the clone behaviour. Whilst making this object a value object makes sense for simple strings, it's basically a container, You would expect shallow copy behaviour just like an array.

    Anyway, back to tracer bullet. How about the standard defines just the KeyIndexed interface (hint hint) and we get to see it in the next version of WACT, Mojavi and Changes?

    yours, Marcus

    p.s. Chained lookup using __get() works fine in PHP5 (I haven't tried setting properties), but depending on your version of PHP4 can actually cause a spectacular crash. The [] (array emulation) behaviour is spotty and buggy, but I havent tried it in PHP5.1 yet. I don't trust it though given Zend's track record.

    p.p.s. Suggest KeyValues, KeyIndexed, KeyLookup, Keyed (I like that one) or Properties. "DataSource" and "DataSpace" say zilch and are more on the implementation side anyway.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #113
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    706
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Figuring out names that are acceptable to everyone seems to be an exercise in futility. Why not abstract the names themselves like the drug companies do? Pick a theme such as Lord of the Rings and start using characters. So DataSource becomes Frodo.

  14. #114
    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
    Do that within a dynamic proxy (Travis - that was the pattern you were after) to get member access if you want performace.
    Of course... Thanks.

    Quote Originally Posted by lastcraft
    p.p.s. Suggest KeyValues, KeyIndexed, KeyLookup, Keyed (I like that one) or Properties. "DataSource" and "DataSpace" say zilch and are more on the implementation side anyway.
    Agreed on the last point. They seem to carry an awful lot of implied baggage to me.

    I don't see where you're going with Key* though? I'm thinking ValueProxy and MutableValueProxy. Explains exactly what it is and what it does. Thoughts?

    I just set up an SVN server @ https://svn.opensir.org/svn/. I've also added a first draft of the ValueProxy and MutableValueProxy interfaces (which are still mobile with svn mv if another name comes up). If anyone wants write access to the trunk, PM me and I'll get it set up.

  15. #115
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    I think you're wrong. I just tested it, and it seems to work.
    PHP Code:
    class testMe {
        public function 
    __set($name$value) {
        }
    }
    $test = new TestMe();
    $test->blah->blah FALSE
    Fatal error: Cannot access undefined property for object with overloaded property access

  16. #116
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Anyway, back to tracer bullet. How about the standard defines just the KeyIndexed interface (hint hint) and we get to see it in the next version of WACT, Mojavi and Changes?
    I agree. We need to prove we can come to a conclusion in one area before tackling others.

    So can we all agree on this:

    PHP Code:
    interface Properties {
        public function 
    __get($property);
        public function 
    __set($property$value);
        public function 
    __isset($property);
        public function 
    __unset($property);

    I will also need Path access (at least for now). I don't sense general agreement on this, but thats ok. It can be something WACT specific:

    PHP Code:
    interface StructuredProperties extends Properties {
        public function 
    getViaPath($path);
        public function 
    setViaPath($path$value);
        public function 
    hasPath($property);
        public function 
    unsetViaPath($path);

    I will also need meta data for the properties. I think this is an area where will can also reach consensus. This is important for tool interoperability.

    PHP Code:
    interface PropertyInfo {

    Can we agree to keep the meta data interfaces separate from the Properties interface, leaving Properties as just the magic methods?

  17. #117
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak
    So DataSource becomes Frodo.
    A new hire actually bragged to me once that he used this method to name his variables. We fired him shortly after.

    So here is the new interface:
    PHP Code:
    class BewareTheJabberwock extends my_son {
        function 
    TheJawsThatBite();
        function 
    TheClawsThatCatch();
        function 
    BewareTheJubjubBird();
        function 
    ShunTheFumiousBandersnatch();


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

    Quote Originally Posted by Travis S
    I don't see where you're going with Key* though? I'm thinking ValueProxy and MutableValueProxy. Explains exactly what it is and what it does. Thoughts?
    No it doesn't, it describes an imlementation. Here is the context...
    PHP Code:
    class DataSpace implements KeyLookup { ... } 
    It has to read well as part of an implements line...
    PHP Code:
    class DataSpace implements Keyed { ... }
    class 
    DataSpace implements KeyValues { ... }
    class 
    DataSpace implements KeyIndexed { ... } 
    See what I mean?

    By the way, your post earlier about a read only interface won't work without a lot of machinations. For example, say you have this...
    PHP Code:
    interface Gettable { }
    interface 
    SettableAndGettable implements Gettable { } 
    No matter which one you type hint with, you have not enforced read only behaviour.

    You would have to have...
    PHP Code:
    interface Gettable { }
    interface 
    Settable {}
    class 
    SomethingSettableAndGettable implements GettableSettable { } 
    It really isn't worth the effort is it? Especially when you can all too easily hack around PHP to get what you want anyway. I don't think it's worth it.

    Regarding your template droppable version, that should be called Templateable...
    PHP Code:
    class Person implements Templateable { ... } 
    Keeps it separate from Keyed and emphasizes what a very specialist interface it is.

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

  19. #119
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    And apparently, they have been adjusted (as of 5.0.4 to allow you to use array access as well. If you hide txt in an array (associate or numeric) you can pull it out.
    So this works in 5.0.4?
    echo array('key'=>'value')->key;

  20. #120
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    PHP Code:
    class testMe {
          public function 
    __set($name$value) {
          }
      }
      
    $test = new TestMe();
      
    $test->blah->blah FALSE
    Fatal error: Cannot access undefined property for object with overloaded property access
    We can code around these problems by supplying some real implementation:

    PHP Code:
    class TestMe {
         private 
    $vars = array();
         public function 
    __get($name) {
             if (isset(
    $this->vars[$name])) {
                 return 
    $this->vars[$name];
             } else if (
    $name == 'blah') {
                 
    $this->vars[$name] = new StdClass;
                 return 
    $this->vars[$name];
             }
         }    
         public function 
    __set($name$value) {
             if (
    $name=='blah') {
                 
    $this->vars[$name] = new StdClass;
             } else {
                 
    $this->vars[$name] = $value;
             }
     
         }
     }
     
    $test = new TestMe();
     
    $test->blah->blah 'foo';
     echo 
    $test->blah->blah;  // result: foo 
    Of course, the implementation should be generalized -- here I just want to show that it should be possible to avoid snafus. I only tested on 5.1RC1. I don't see the point in targetting anything earlier.

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

    Quote Originally Posted by Selkirk
    I will also need Path access (at least for now). I don't sense general agreement on this, but thats ok. It can be something WACT specific:
    Possibly called Hiearchical?

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

  22. #122
    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
    It has to read well as part of an implements line...
    PHP Code:
    class DataSpace implements Keyed { ... }
    class 
    DataSpace implements KeyValues { ... }
    class 
    DataSpace implements KeyIndexed { ... } 
    See what I mean?
    Ok... You're working from the point of view that interfaces should answer the question "Is ...?", correct? Makes sense and should help avoid naming collisions.

    edit - changed "Is a...?" to "Is...?"

    Quote Originally Posted by lastcraft
    By the way, your post earlier about a read only interface won't work without a lot of machinations. For example, say you have this...
    PHP Code:
    interface Gettable { }
    interface 
    SettableAndGettable implements Gettable { } 
    No matter which one you type hint with, you have not enforced read only behaviour.
    Hmm... I'm going to disagree here, though it wouldn't be the first time I've been wrong.

    PHP Code:
    class MySpecialObject {
        function 
    readSomeValue(Gettable $values) {
            
    // do something reading wise
        
    }

    With that I'm asking for at least Gettable. If I get something more, thats fine, but I'm defining that all readSomeValue() needs to have access to is get(). Am I missing something?

  23. #123
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    I agree. We need to prove we can come to a conclusion in one area before tackling others.

    So can we all agree on this:

    PHP Code:
    interface Properties {
        public function 
    __get($property);
        public function 
    __set($property$value);
        public function 
    __isset($property);
        public function 
    __unset($property);

    So we're back to magic methods?

    I would adjust them to:

    PHP Code:
    interface Properties {
        public function 
    __get($name);
        public function 
    __set($name$value);
        public function 
    __isset($name);
        public function 
    __unset($name);

    Minor thing, but it sticks with the manual's definition of them.


    That said - it seems to me there might be a high name collision rate with Properties. NamedProperties, KeyedProperties, IndexedProperties? No - strike the last, it implies $properties->value[1]->subvalue[2]->etc.

  24. #124
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    fwiw: I like $key, $value mainly because it implies a lookup.

  25. #125
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    So we're back to magic methods?

    I would adjust them to:

    PHP Code:
    interface Properties {
        public function 
    __get($name);
        public function 
    __set($name$value);
        public function 
    __isset($name);
        public function 
    __unset($name);

    While I agree with the magic methods I think it is ignoring reality to not have get() and set(), so:
    PHP Code:
    interface Properties {
        public function 
    get($name);
        public function 
    set($name$value);
        public function 
    propertytIsSet($name);  // ? name
        
    public function propertyUnSet($name);  // ? name
        
    public function __get($name);
        public function 
    __set($name$value);
        public function 
    __isset($name);
        public function 
    __unset($name);

    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
  •