Matthew Weier O'Phinney [2006-05-04 20:03 UTC] I like it. Some comments:
* A load() method that would load up a new string would be nice; that way the same object could be utilized many times.
* If you'd be willing to walk the PHP5 path, you could use overloading to mimic your get() method: $path->golden, etc.
* It might be cool to be able to build paths based on an array and/or associative array.
Christian Weiske [2006-05-04 20:06 UTC] While I see the usefulness of this class, I think that it's not enough for a whole package. How does PEAR handle such small things?
Philippe Jausions [2006-05-04 20:15 UTC] I see this could be useful for parsing PATH_INFO type of strings...
Some problems though, what if a value has the value of a key name? I guess this is not really specific to the package itself, but the get($key) method could lead to bugs or unexpected behaviours.
Martin Jansen [2006-05-05 08:19 UTC] Looks like a handy thing, but I'm not sure about the name. What do you think of e.g. "Text_PathNavigator"?
Also, have you considered adding iterator support? One could then walk through the input string using
foreach ($p as $node) {
echo $node;
}
which is pretty nifty IMO.
Lukas Smith [2006-05-05 10:41 UTC] There is some overlap with my recent proposal here, however this package would be more in the direction of a tool that could be used to create something like my mod_rewrite parser ..
Denny Shimkoski [2006-05-06 00:11 UTC] Hello all and thanks for the prompt feedback.
I've updated the class according to some of the suggestions and uploaded it here: http://bytebrite.com/pear/path.phps
You can copy and paste to test it locally or just view the saved output in the comments at the bottom of the file.
To address each individual directly --
Matthew, inspiration of method load(), to you I give thanks. The method accepts strings and associative arrays.
I don't think your second suggestion will work though, since it's pretty much impossible to tell what's a variable and what's a value. Probably best to leave that to the particular application.
Christian, it's not too small, it's just highly efficient! Ha ha! We have once again succeeded in bending the language to our designs!
Philippe, in practice I've found the numeric indexing scheme works best. The application decides what is what and where is what (what?!). Sometimes the other access method comes in handy though.
Martin, I'm not stuck on the name. I think PathArray is apt though, as the class basically represents an array of information that's delimited by strings. In any case, whatever the group decides is fine by me.
As for the iterator, the toArray method provides a way to do this in a pairwise fashion. Alternatively, the user can access the $vars member directly, which is a numerically indexed array of the entire path.
Lukas, I took a look at your proposal. It does seem that this might come in handy there.
Thanks again for all of your input. Looking forward to the next round.
bertrand Gugger [2006-05-06 02:43 UTC] Version numbering is not right, proposals use 0.0.x , first release 0.1.0
anyway 3 numbers
You should present php soure , not text
php -s source.php > source.php.html does the job.
Why should that be in Text ? yes , everything is text.
If you use PHP license , 3.0 is too low
I don't see no interest in this paackage but guess more confusion from it.
This is idiot , search $this->...
bertrand Gugger [2006-05-06 02:58 UTC] Sorry , bad english (or logic)
I was meaning:
I don't see *any* interest in this paackage
Martin Jansen [2006-05-08 11:13 UTC] Denny,
I still think a name without "Array" in it is better, because for the users of the package it does not really matter how the the components of the path are stored internally. What matters for them is a slick API, which is why I'd still love to see real iterator support. The toArray() method is fine, but it looks a lot less sexy than being able to directly iterate over the instances.
Denny Shimkoski [2006-05-08 22:32 UTC] I've update the class according to the most recent feedback and posted it here: http://bytebrite.com/pear/path.html
Thanks for the tips, Bertrand. I've changed the license to MIT and formatted the source using php -s.
As for why it should be in Text, I couldn't think of a more logical place to put it.
As for the lack of interest, you may be right. However, it wouldn't hurt to have this little utility around when you need it. Furthermore, I don't feel that including it in the repository will hurt PEAR's image. So, why not?
Martin, you sold me on the name change. It is now Text_PathNavigator. I also added support for iterators, but indirectly.
Basically, the user has to call $it = $p->getIterator() and then operate on $it, which is an ArrayIterator instance.
The reason I did it this way is because I didn't want to force PHP5 on users, and, as far as I know, the implements keyword would cause PHP4 to choke. Am I mistaken on this point? Or can you think of a clever workaround, aside from simply defining two distinct classes?
Thanks again,
Denny
Martin Jansen [2006-05-09 08:27 UTC] You are of course correct when assuming that "implements" will cause a parse error in PHP 4. I think getIterator() is a nice compromise.
Considering the implementation of this method, I'd probably return null instead of false there if ArrayIterator does not exist.
Martin Jansen [2006-05-09 09:04 UTC] You are of course correct when assuming that "implements" will cause a parse error in PHP 4. I think getIterator() is a nice compromise.
Considering the implementation of this method, I'd probably return null instead of false there if ArrayIterator does not exist.
Martin Jansen [2006-05-14 19:26 UTC] May I ask what the status of the proposal is? I think it is safe to call for votes now.
Denny Shimkoski [2006-05-14 20:09 UTC] Sorry for the delay. I was caught up in another development task.
The getIterator() method now returns null if an ArrayIterator class isn't found.
I'm starting the voting process now.
|
