SitePoint Sponsor

User Tag List

Page 4 of 13 FirstFirst 12345678 ... LastLast
Results 76 to 100 of 325
  1. #76
    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
    Sorry to interrupt you guys but I think I lost the plot of this one. There seems to be a lot of excellent discussion but I think maybe also some neglect of the differences that PHP poses compared to other languages.... Feel free to straighten me out if I'm a backasswards here.
    No... thanks for the reality check. I have a tendency to want to remain as language agnostic as possible and sometimes I need to be reminded that this is PHP.

    On reason you're seeing a lot of those other methods are because they are a from a straight Java port. When I did it originally, there wasn't much interest in seeing how it might work other than curious observers. Now that we're getting a discussion going here I'm completely up for reworking it partially or entirely with the ends of making it the best standard PHP can offer.

    All that time though, I would like to keep an eye towards interoperability to some degree with languages. To the extent we can learn from JCR and realistically use JCR as a model in PHP, great let's use it. To the extent it hinders us in PHP, let's drop it.

    Quote Originally Posted by jayboots
    (of course, by the time I post this, no doubt 10 messages will have already been posted on this thread addressing my points much better than I ever could...)
    This is a fast paced thread for sure...

    Ok, to come back to code...

    PHP Code:
    /**
     * Considered a straight container of raw PHP values
     */
    interface Node
    {
        
    /**
         * This Node's instance name
         *
         * @return string
         */
        
    public function getName();
        
        
    /**
         * Returns an array of known properties
         *
         * @return array
         */
        
    public function getPropertyNames();
        
        
    // accessors and such
        
    public function __get($name);
        public function 
    __set($name$value);
        public function 
    __isset($name);
        public function 
    __unset($name);
    }

    interface 
    NestedNode extends Node
    {
        
    /**
         * Returns the parent of this or throws an exception
         *
         * @return Node
         */
        
    public function getParent();
        
        public function 
    getPath();
        public function 
    hasNodes();
        public function 
    hasNode($name);
        public function 
    getNode($name);
        
    /*
         * or if you want to allow jumping to grandchildren instead of
         * just child nodes
         */
        
    public function getNode($relPath);

    What am I leaving out? I know there's got to be lots of somethings missing there.

    Tyler - where at?

  2. #77
    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
    One thing - I'm not a fan of relying exclusively on __get()/__set() (see my original extension of DataSource - something along the lines of MagicalDataSource). I think their use is an implementation decision that's best left up to the implementor. If you code relies on it, then rely on MagicalDataSource.
    For me this is the wrong way around to approach this. I think the use cases are most important. We should be asking ourselves, "What do we want our code to look like?" and then use the best that PHP has to offer to implement that. I know selkirk is big on use cases.

    I would also like to make another point/request: that this interface library be housed independently from the various frameworks. It should be a place where all the core contributors feels equal. I setup the sourceforge AP3 space for just this kind of place to take things like this from ideas to prototype. Many here already have access and it can be configured in any way the core group feels is necessary. Or setup a new project.

    I might also suggest that lastcraft's lamplib sourceforge project might be a good place to house it. I can't (and wouldn't) speak for Marcus, but I have the impression that this is the kind core stuff that he intended to house there.
    Christopher

  3. #78
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Travis,

    Freenode is fine.

    I would like to propose that, instead of going straight into some implementations, we first outline what different things we're going to work on? For example, work out how naming conventions should work, and perhaps things like "recommended practices" or things of that nature. However, like a lot of other things I tend to work on, I don't want to become overly bueracratic [sic]. I want this thing to be open, but I want it to be designed well. Catch 22 if you ask me.


    Here's a small list I'd like to propose outlining:

    * Cache layer
    * DataSpace/Container layer
    * View/Renderer/Template layer
    * Datasource (not Dataspace)
    * Exceptions layer (just some common stuff)
    * Datastuctures layer (things like filter-chains, stacks, etc)
    * Logging layer
    * User layer (essentially a composite container for roles, permissions, etc)
    * Validator layer

    Now, I know that isn't a modest list, but I'd like to throw it all out there just to get some feedback from you guys. Am I making this too big?

    Regards,

    Tyler Tompkins

  4. #79
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @illusina: to continue your thought, it might be prudent to have class naming and file layout standards in light of autoload.

  5. #80
    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
    For me this is the wrong way around to approach this. I think the use cases are most important. We should be asking ourselves, "What do we want our code to look like?" and then use the best that PHP has to offer to implement that. I know selkirk is big on use cases.
    Good point... I think we've got the basics down on in that we want a DataSpace'esque object that can house any number of properties. Those should be extended to allow nesting so we can build more complex object relationships. Or am I out in left field?

    I would also like to make another point/request: that this interface library be housed independently from the various frameworks.
    Definitely - that's why I'm glad we've got people from WACT and Mojavi offering ideas. I'll be more than happy to put together a SVN repository to house it and I've also registered an SF project to house it. Does anybody have a SVN to CVS mirroring tool that won't require me getting the swig bindings up and running on my SVN server? (long story, but with an entire weekend devoted to that task, all I got was a different error message in the end).

  6. #81
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    Here's a small list I'd like to propose outlining:

    * Cache layer
    * DataSpace/Container layer
    * View/Renderer/Template layer
    * Datasource (not Dataspace)
    * Exceptions layer (just some common stuff)
    * Datastuctures layer (things like filter-chains, stacks, etc)
    * Logging layer
    * User layer (essentially a composite container for roles, permissions, etc)
    * Validator layer
    I think I might leave out the View/Renderer/Template and User layers for now. I'm not a big fan of Loggers so I'd be interested in how others feel about that. I would add a Filter layer.
    Christopher

  7. #82
    SitePoint Enthusiast
    Join Date
    Oct 2004
    Location
    Kansas City, MO
    Posts
    68
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by illusina
    However, like a lot of other things I tend to work on, I don't want to become overly bueracratic [sic]. I want this thing to be open, but I want it to be designed well. Catch 22 if you ask me.
    I think we can get something to come out of this... it might just take more than a few days worth of posts

    * Cache layer
    Isn't this an extension of a storage type object? It's just a specialized with a built in Specification to it.

    * DataSpace/Container layer
    I think this is the most critical to figure out - everything else happens from the data. Can't cache without it, can't view if there's nothing to view, etc.

    * View/Renderer/Template layer
    This one might be the most difficult...

    * Datasource (not Dataspace)
    By Datasource are you meaning like a collection of Dataspaces? There's a lot of possible meanings here, so I don't want to read anything into it.

    * Exceptions layer (just some common stuff)
    Agreed. This might turn into more of a best practices type thing - plus there's a ton of new Exceptions in PHP 5.1.

    * Datastuctures layer (things like filter-chains, stacks, etc)
    Maybe it's just the "stacks" that's jumping out and clouding my vision, but how would this differ from what's in SPL?

    * Logging layer
    This moves into more of an implementation thing here. At it's abstract, though we would want an Observer and Observable interface where logging could be plugged into.

    * User layer (essentially a composite container for roles, permissions, etc)
    Again, this would be hard to implement without getting into implementations. These last two might be best left until all of the raw data is stored and such, and then focus on a common library way of bringing them together. We could always wimp out like JCR did and implement a blank Credentials interface to signify that MyObject should be viewed as good enough to use YourObject.

    * Validator layer
    A Parameterized Specification pattern? Maybe a standardized way to define a valid Specification - SpecificationDefinition? - and assume that it is passed a DataSpace/Node. You construct it a certain way, then it will always be able to return true or false on isValid(). Thoughts?

    Now, I know that isn't a modest list, but I'd like to throw it all out there just to get some feedback from you guys. Am I making this too big?
    I think there's a few areas where you venture awfully close to more solid concepts. I think its a matter of baby steps out from the epicenter. As was originally pointed out by someone else - I've forgot who now - the DataSpace/Source/Node type object is where things start. Everything seems to radiate out from that.

    @illusina: to continue your thought, it might be prudent to have class naming and file layout standards in light of autoload.
    Does anyone have any thoughts on this? I personally, do not like PEAR's assumption that everything exists in the include_path. I would prefer to define a standard interface_path kind of constant, and have that used to figure out where everything is.

    One thought - what about including a finder class as one concrete class for loading files?

    PHP Code:
    $loader = new InterfaceFinder();
    $loader->load('Node');
    $node = new Node(); 
    That gives us a lot more freedom with names directory structures and whatnot. To start with, it could be a flat directory of files and as they seemed to congel we can start to move them around into a more sensible directory structure. Seems kind of anti-OO to couple ourselves to a particular data structure.

    As far as actual naming - I'm always a fan of "Name.class|interface|abstract|exception.php". Makes it easier to figure out what you're loading. Of course, if we hide this behind a loader it doesn't make any difference so long as we come up with a standard means of naming so the finder knows what to look for.

  8. #83
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Travis S
    Does anyone have any thoughts on this? I personally, do not like PEAR's assumption that everything exists in the include_path. I would prefer to define a standard interface_path kind of constant, and have that used to figure out where everything is.

    One thought - what about including a finder class as one concrete class for loading files?

    PHP Code:
    $loader = new InterfaceFinder();
         
    $loader->load('Node');
         
    $node = new Node(); 
    I agree about the include path. With autoload we don't have to care about such things. I also agree about a standardized loader mechanism (I posted a generic one for autoloading in another thread that can adopt arbitrary behaviours).

    The point of autoload though is that you don't ever explicitly call the loader. We just mention classnames and they get loaded magically. That implies standardized class naming. I like "I" and "A" prefixes for interfaces and abstract classes; however, it doesn't really matter what the consensus is -- if it is chosen to have "Interface" as a prefix or even a suffix, that's fine -- as long as it is standardized to keep the autoloading mechanics simplified.

    As far as file naming, it is less of an issue since we can always adapt the autoloader behaviour -- but class naming standards are critical in my view simply because they are concretely referenced in code. Without class naming standards, autoloading is a pita.

  9. #84
    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
    I agree about the include path. With autoload we don't have to care about such things. I also agree about a standardized loader mechanism (I posted a generic one for autoloading in another thread that can adopt arbitrary behaviours). The point of autoload though is that don't ever have to explicitly call the loader. We just mention classnames and they get loaded magically. The thing is, that means you have to have standardized class naming. I like "I" and "A" prefixes for interfaces and abstract classes; however, it doesn't really matter what the consensus is -- if it is chosen to have "Interface" as a prefix or even a suffix, that's fine -- as long as it is standardized to keep the autoloading mechanics simplified. As far as file naming, it is less of an issue since we can always adapt the autoloader behaviour -- but class naming standards are critical in my view.
    I've never relied on __autoload(), is it possible to chain them together? I think the route to go might be to create our own loader, then suggest that it be used inside __autoload() so developers can still use it for their own purposes while falling back on $finder->load() prior to failing.

    As for naming - I would be against including full "Interface" or "Abstract" in the name unless it's describing what it does. In my development, I try to adopt the name that makes the most sense. I've started naming interfaces as ConcreteIdea, then naming my implementation d51ConcreteIdea. The most recent example I have is InterfaceContainer (a container of interfaces). That could be adopted to iInterfaceContainer, but I wonder if that's necessary?

    As far as interface to file mapping - I would do a one to one. ConcreteIdea.interface.php contains ConcreteIdea. If ConcreteIdea relies on AsphaltIdea, should ConcreteIdea be responsible for loading that dependency? This is the route I went with phpCR. Going this route, all of the interface dependencies are already loaded when you include the entry point.

    Any other ideas or suggestions on how to go about all this?

  10. #85
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Travis: You can make them chainable if you choose a standard mechanism. I stack them in the one I posted in this thread: http://www.sitepoint.com/forums/showthread.php?t=255407 but anyone of them in the stack could be a chain if you wished.

    From what I can tell, as of 5.1, SPL now has methods to do similar which will hopefully lead to more uniform autoload management.

  11. #86
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dang! This is a fast moving thread. I can hardly get anything done today that I'm supposed to. Its quite exciting.

    Working backwards....

    IRC is fine with me, but I can never get it to work right. Links and explicit instructions are appreciated.

    illusina, for now, I think we should limit the scope to seeing if we can get a DataSource that we can all agree on. If we can get that far, then we can bring up a new subject area.

    Quote Originally Posted by arborint
    I would also like to make another point/request: that this interface library be housed independently from the various frameworks.
    I agree.

    Travis, regarding the Node interface. I'm uncomfortable with the getName() method. I think this interface should be about the properties and only the properties. In fact, back when I was still calling it DataSpace, I contemplated changing the name to ComponentProperties so that you would say xxx implements ComponentProperties. I did say that this interface was 1/2 of a component model, didn't I?

    Travis, Here is a use case to show using paths with PHP arrays. Remember that not every element in the path is an object.:
    PHP Code:
    class Game extends SomeDataSourceClass {
        var 
    $levels = array('easy' => 10'medium' => 5'hard' => 3);
        var 
    $word;
    }
    function 
    dumpIt(DataSource $data) {
        echo 
    $data->getViaPath('levels.easy');
        echo 
    $data->word;

    Quote Originally Posted by Travis S
    One thing - I'm not a fan of relying exclusively on __get()/__set()
    I don't mind shadowing each of the methods with a non-magical version. But in a minimalistic sense, thats not necessary. __isset and __unset weren't added until 5.1, so to be compatible with 5.0, you have to make the calls directly, rather than use the isset() and unset() functions.

    Are we really down to something like this?
    PHP Code:
    interface DataSource 
        public function 
    getDataSourceInfo(); 
        public function 
    __get($property); 
        public function 
    __set($property$value); 
        public function 
    __isset($property); 
        public function 
    __unset($property); 
    }

    interface 
    StructuredDataSource extends DataSource 
        public function 
    getViaPath($path);
        public function 
    setViaPath($path$value);
        public function 
    hasPath($path);
        public function 
    unsetViaPath($path);

    Wow. Svelte. I like it. I'm slightly uncomfortable about a few things, but I think I can live with it. I'm gonna post a link to this thread on the WACT mailing list.

    There are some semantic things to work out like what does __isset return if a property has a null value and what does __get do if you call it directly instead of letting it be called automatically by PHP. These will all come up in a test suite, tho.

  12. #87
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Again, budding in:
    PHP Code:
    class Game extends SomeDataSourceClass 
           var 
    $levels = array('easy' => 10'medium' => 5'hard' => 3); 
           var 
    $word
       } 
    public "real" properties don't really make sense with __get/__set in effect. Actually, I think they are counter-productive because you have to do special things in your magic methods to even know about them and even then, your magic won't get called when they are accessed.

    Something like:
    PHP Code:
    echo $data->getViaPath('levels.easy'); 
    is no different than:
    PHP Code:
    $data->levels['easy']; 
    and some might be tempted to define $levels as new ArrayObject(array(...)) to get $data->levels->easy. Or you can go the other way and have everything look like arrays (eg: $data['levels']['easy']) -- but either way, accessor methods seem redundant to me.

  13. #88
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I don't think mandating __autoload() schemes is appropriate for an interface repository. we cannot possibly achieve consensus there.

    We're going to have at least four interfaces and a dozen exceptions. Will they all be in separate files? I'm not worried about the exceptions because they can be lazy loaded by the implementations, but I don't like the idea of having the interfaces spread across too many files.

  14. #89
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This might turn into more of a best practices type thing - plus there's a ton of new Exceptions in PHP 5.1.
    Is there any documentation on this somewhere, where I can take a look

    The point of autoload though is that you don't ever explicitly call the loader. We just mention classnames and they get loaded magically.
    This removes the responsibility of fetching the actual file away from you, the developer. That was the original intention of the feature, wasn't it?

    Where the file resides, and the name of the file is not really revalant in that case, what is important is the naming of the interfaces and classes as put forward.

    I'm slightly uncomfortable about a few things, but I think I can live with it.
    Can I ask what are you not too happy with Selkirk?

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

    Just a note to temper enthusiasm just a little. The greatclass libraries (Java, STL) have come about over some years of work by very experienced developers in their fields. It's not very easy to be an experienced framework developer, because they take so long to develop. Developing highly abstract framework interfaces looks a bit like building momentum the hard way. I don't see any easy way to get buy-in from other framework authors for anything except a handful of classes for example.

    My instincts are...

    1) Only establish interfaces for things that are already common ground as these are proven interfaces. No bells, no whistles. Don't try to imagine what you should have (the implementers can do that). An interface is a minimum interoperability requirement. What operations are you going to want to perform on every framework ever written (that's the interface). Not so easy to answer, is it? Trying to add things that might be nice gets you into the horrific mess that is the SPL RecursiveIteratorIterator.

    2) Start with simpler interfaces. Things like URI, Stream, Writer, Reader, Request that are barely above implementations (and can have reference implementations in places). PHP doesn't even have a class library, let alone a Framework interop standard. One of the things that helps Java developers stay on message is that they have a vocabulary of idioms from the bundled standard library. It helps to set the tone. PHP does not have that, and the SPL suffers from the armchair general imagining ahead syndrome that I just mentioned. Really it means going out to see what interfaces are in common right now, and only using commonality. Simply documenting that a bunch ofinterfaces are typical in the real world will help establish them as standard. The database connection interface is one that everyone has done.

    Tactically I would set DataSource/DataSpace (Yuk, prefer the objective C name) as just the get/set behaviour and stop there. No XPath, no nothing. Build something with that interface and prove that you can stick with it across two frameworks.

    I've seen too many grandiose interface plans just get ignored.

    yours, Marcus

    p.s. I am still following this thread with interest though, especially with framework authors finally showing some convergence.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  16. #91
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Again, budding in:
    Please do.
    Quote Originally Posted by jayboots
    public "real" properties don't really make sense with __get/__set in effect. Actually, I think they are counter-productive because you have to do special things in your magic methods to even know about them and even then, your magic won't get called when they are accessed.
    "real" properties are much faster than __get/__set. Sometimes you just don't need that extra stuff, so why not take advantage of simple "real" properties when they will work just fine? Also, You can't stop someone from calling __get() on your object directly, so __get() probably needs to be aware of the fact anyway. I think its up to the particular object implementation.

  17. #92
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    @Selkirk: I don't see the issue in calling __get() directly if someone is so inclined. $foo->__get('bar') will do whatever $foo->bar does. The difference to me is that __get() can be trained to also retrieve from a real concrete public property if called directly, but not otherwise since it won't be called by the engine which is really the issue I am after.

    While it is certainly faster to use real properties, it prevents you from catching access in a uniform way. I see this as the point of a "property" as opposed to a straight member variable -- properties are accessed indirectly via userland code. For example, if I wanted to log all property access on a given object I can construct a __get that permits observers as well as the basic property mechanism. More generally, I can create a mechanism that controls how __get works so that the runtime behaviour is mutable (so as to chain behaviours, for example).

    You lose that ability if you define concrete public properties, or more aptly, it becomes somewhat broken because it is not uniform across concrete and virtual properties. If you don't need that stuff then you might just as well derive from a less dynamically styled class/interface. In that respect, I think you have to choose one "public property" style or the other (virtual properties only, concrete properties only) for a given class.

    Best Regards.

  18. #93
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Can I ask what are you not too happy with Selkirk?
    I didn't say I was unhappy. I said I was uncomfortable. Thats not necessarily a bad thing.

    What bothers me most is breaking the Path methods off into a separate interface. With only the magic methods, DataSource looks too anemic to bother declaring. Not declaring it at all would certainly fix Marcus' dislike of the name. I can take or leave the base DataSource class. Mostly leave. However, I still need the path access, meta-data, and exceptions.

  19. #94
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    @Selkirk: I don't see the issue in calling __get() directly if someone is so inclined. $foo->__get('bar') will do whatever $foo->bar does. The difference to me is that __get() can be trained to also retrieve from a real concrete public property if called directly, but not otherwise since it won't be called by the engine which is really the issue I am after.

    While it is certainly faster to use real properties, it prevents you from catching access in a uniform way. I see this as the point of a "property" as opposed to a straight member variable -- properties are accessed indirectly via userland code. For example, if I wanted to log all property access on a given object I can construct a __get that permits observers as well as the basic property mechanism. More generally, I can create a mechanism that controls how __get works so that the runtime behaviour is mutable (so as to chain behaviours, for example).

    You lose that ability if you define concrete public properties, or more aptly, it becomes somewhat broken because it is not uniform across concrete and virtual properties. If you don't need that stuff then you might just as well derive from a less dynamically styled class/interface. In that respect, I think you have to choose one "public property" style or the other (virtual properties only, concrete properties only) for a given class.

    Best Regards.
    Precisely what was aching to say . Yep, that's about right.

  20. #95
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    If you don't need that stuff then you might just as well derive from a less dynamically styled class/interface.
    Sometimes you don't need the capability that the magic methods provide but you do need the meta-data or Path access. Thus, it can be useful to inherit from a base class that provides these, but still declare "real" public properties. You would inherit from a class designed for this purpose. I agree that mixing styles in the same class would be bad.

  21. #96
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Tactically I would set DataSource/DataSpace (Yuk, prefer the objective C name) as just the get/set behaviour and stop there. No XPath, no nothing. Build something with that interface and prove that you can stick with it across two frameworks.
    I agree entirely, minimalistic approaches to interface design is certainly a better option given that 1) things can be extended 2) one will get bogged down in the superflous details of implementation if they are considering every possible application. That's not to say that an interface author needs not worry about implementation, but rather that they shouldn't design explicitly for one implementation or another.

    @autload discussion:

    Mojavi 3 currently uses an autoload.ini configuration file to feed, through an associative array, a list of class names and their respective filepaths to the __autoload() function. Now, I don't particularly like this scheme because Mojavi relies too heavily on it in the first place and it eats a lot of cycles. Adapting this sort of technique might be useful for our purposes, but not in this form most certainly.

    I've never relied on __autoload(), is it possible to chain them together? I think the route to go might be to create our own loader, then suggest that it be used inside __autoload() so developers can still use it for their own purposes while falling back on $finder->load() prior to failing.
    Very easily.

    I don't think mandating __autoload() schemes is appropriate for an interface repository. we cannot possibly achieve consensus there.

    We're going to have at least four interfaces and a dozen exceptions. Will they all be in separate files? I'm not worried about the exceptions because they can be lazy loaded by the implementations, but I don't like the idea of having the interfaces spread across too many files.
    Yes and no, IMO. I don't believe that the repostiory would be in place mandating schemes, however, suggesting/providing ways of doing things might not be too out-of-line. Keep in mind that there was/is discussion of using DI, which would handle all/almost all dependency matters theoretically (I'd imagine based upon configurations rather than runtime arguments).

    ... An interface is a minimum interoperability requirement.
    Very well said.

    illusina, for now, I think we should limit the scope to seeing if we can get a DataSource that we can all agree on. If we can get that far, then we can bring up a new subject area.
    I suppose starting on a specific part of the project would be good to start working out kinks that we'll hit later. Are you stuck on the name "DataSource"; because personally I don't like it .

    Regards,

    Tyler Tompkins

  22. #97
    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
    1) Only establish interfaces for things that are already common ground as these are proven interfaces. No bells, no whistles.
    Very good point - and one of the reasons I had to specify that __get()/__set() are a particular behavior. I can understand their use, but that's one more learning curve we through people who are picking up these interfaces in 6 months from now. "But wait, I just accessed it as a property, and it's not a property? How come?" get()/set(), while not as pretty, are definitely much more straight forward for new and new-to-PHP coders. To take the simplified view one step further (and Jason or Marcus, or anyone else for that matter if I'm defining a pattern here please let me know - I'd much rather use the common name)

    PHP Code:
    interface ValueContainer {
        
    /**
         * Returns a mixed value with a given name or NULL if does not exist
         *
         * @return mixed|null
         */
        
    public function get($name);
    }

    interface 
    MutableValueContainer extends ValueContainer {
        public function 
    set($name$value);

    That would be a ValueObject - but it's a collection. The simplest is read-only - seems like there's not much use to it, but if you want to provide a read-only API to developers, its better to not have set() laying around asking to be called. In addition, I would see any View/Template-type interfaces only relying on a read-only version.

    Also, I've pulled the isset() - state reports can be made via a decorator. Returning null allows some level of introspection via "is_null($value->get('value')) do not set thing".

    Thoughts, comments?


    Quote Originally Posted by lastcraft
    PHP doesn't even have a class library, let alone a Framework interop standard. One of the things that helps Java developers stay on message is that they have a vocabulary of idioms from the bundled standard library. It helps to set the tone. PHP does not have that...
    But, but... we've got PEAR


    Quote Originally Posted by lastcraft
    Really it means going out to see what interfaces are in common right now, and only using commonality. Simply documenting that a bunch ofinterfaces are typical in the real world will help establish them as standard. The database connection interface is one that everyone has done.
    And there seems to be a done of ways to do it...

    Quote Originally Posted by lastcraft
    (Yuk, prefer the objective C name)
    I'm not familiar with objective C - what is the standard there?

    Quote Originally Posted by lastcraft
    I've seen too many grandiose interface plans just get ignored.
    Sigh... Yup - phpCR is proof of that


    Quote Originally Posted by lastcraft
    p.s. I am still following this thread with interest though, especially with framework authors finally showing some convergence.
    Glad to hear that... I was wondering if you were going to chime in.

  23. #98
    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 don't think mandating __autoload() schemes is appropriate for an interface repository. we cannot possibly achieve consensus there.

    We're going to have at least four interfaces and a dozen exceptions. Will they all be in separate files? I'm not worried about the exceptions because they can be lazy loaded by the implementations, but I don't like the idea of having the interfaces spread across too many files.
    Personally - a single hit for each interface doesn't bother me as in the grand scheme of things I consider that a small hit. Through in some caching and it wouldn't hardly be recognizable. That said, I'm not completely opposed to some form of grouping. That would make it harder to do lazy-loading/autoloading as we'd have to map the requested interface to a group file. Bearing that in mind, I would like to keep them as seperate files - that way an auto loader doesn't have to have any mapping logic.

  24. #99
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I must say that I fully agree with Jayboots on his position regarding __get and __set. Maybe I am the only one, but they are the single most feature I am the most excited about with PHP5. It is not interfaces or type hints, or even exceptions, although all of these were much needed.

    I just see so much value in using those magic methods (and even __call too), specially for the design of a Dataspace. You provide the perfect hook point for a decorator, and all sort of clever wrappers and AOP-style patterns become possible.

    Quote Originally Posted by jayboots
    Something like:
    PHP Code:
    echo $data->getViaPath('levels.easy'); 
    is no different than:
    PHP Code:
    $data->levels['easy']; 
    Well, they are a little bit different. The first example tastes a little bit like Java. The second one has a distinct PHP aroma, but this one:
    PHP Code:
    $data['levels']['easy'
    Thats walks and quacks like PHP all over the yard. For me, if all three allow the same implementation through a different language, this last one is how PHP is "meant" to be. Personally (and this is a very personal believe likely to stir some controversy), I believe that in any sufficiently advanced language, method calls are indistiguishable from property accesses. What PHP does with __set and __get is half way there: it lets us intercept property access with methods.
    Garcia

  25. #100
    SitePoint Enthusiast
    Join Date
    Mar 2005
    Posts
    53
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado

    Well, they are a little bit different. The first example tastes a little bit like Java. The second one has a distinct PHP aroma, but this one:
    PHP Code:
     $data['levels']['easy'
    Thats walks and quacks like PHP all over the yard. For me, if all three allow the same implementation through a different language, this last one is how PHP is "meant" to be. Personally (and this is a very personal believe likely to stir some controversy), I believe that in any sufficiently advanced language, method calls are indistiguishable from property accesses. What PHP does with __set and __get is half way there: it lets us intercept property access with methods.
    I must say I don't see the merit of using a namespace approach to most applications. Unless there is a strict and mandatory need for namespaces (most notably in userland code/developer code), namespaces can be "faked" used a flat namespace. For example:

    To emulate something like [level][easy] simply do key = "level.easy"; As a developer you know what you mean, and you don't need the extra overhead parsing the dots out and accessing the appropriate index on a possibly existing sub-array. There are examples, however, where another level of namespace came become mandatory simply because there needs to be a point where a developer can be certain their data isn't going to be trampled. Thoughts?

    Regards,

    Tyler Tompkins


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
  •