SitePoint Sponsor |
|
User Tag List
Results 151 to 175 of 325
-
Sep 14, 2005, 23:12 #151
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Travis S
Christopher
-
Sep 14, 2005, 23:15 #152
- Join Date
- Mar 2005
- Posts
- 53
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Hello everyone,
Following the thread again. And again amazed at how much people can go in circles. I suppose what puzzles me is why, in a thread about an application code repository, we're discussing the semantics of magical overload operators. While the __get/__set discussion is valid, I don't believe that _this_ is the place for it.
@Travis: I've been browsing around your phpCR -- it looks interesting, what is your reason for wanting to set it aside in favor of this? More popular support, or...?
@Selkirk: Do you think we can come to a reasonable conclusion regarding a "Properties" interface? Having set()/get() are going to be mandatory, in my opinion, simply because they are exposed and accessible.
Now that I think about it, perhaps this thread should fork into get/set and Application Code Reposistory. Thoughts?
Regards,
Tyler Tompkins
-
Sep 14, 2005, 23:55 #153
- Join Date
- Sep 2003
- Location
- Wixom, Michigan
- Posts
- 591
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by illusina
Garcia
-
Sep 15, 2005, 07:00 #154
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
illusina: Thanks - I think phpCR is interesting and has a lot of potential too. My intent with this is to bring phpCR into its own as a PHP interface library by making the adjustments that might seem necessary to move it into a PHP realm. Whether they are needed, or even a good thing, I've yet to determine. As this conversation continues in circles though, I don't know that changing it with a concensus is going to be possible - yet. Hopefully we can settle on one interface soon as see how well it works into several frameworks. If we can get our feet wet with a few smaller interfaces, maybe in time we'll be able to figure out what needs to be done for a full fledged content repository.
-
Sep 15, 2005, 07:01 #155
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
If you amke the effort to follow it, it's not going circles. It's most definitely on topic, because if this problem cannot be solved, then neither can any other. Forking the thread will just trash the thread as it finally makes progress. The reasoning is:
1) We want standard interfaces
2) To be standard people actually have to use them
3) This means they must work with the majority of code
4) Writing interfaces is thus hard
5) Can we prove that the project is feasible with just one
6) Let's try it with a KeyValues interface
7) Oh dear it's more complicated than we thought, but let's battle through.
If this argument cannot be followed in a single thread then the competency to write an interface library is just not there. It's freakin' intense and you have to get your hands really dirty.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 15, 2005, 07:28 #156
- Join Date
- Jul 2004
- Location
- Oklahoma
- Posts
- 119
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I'm going to re-iterate something Marcus hinted at earlier. Designing an interface is nearly impossible. Abstracting an interface out of existing implementations is much easier. Instead of trying to come up with an interface in isolation, why not go find the places in the major frameworks or libraries that these sorts of things are being done, and find the common ground?
I realize that a lot of the proposed interfaces may not be in common use, but I think taking a set of implementations and dissecting the common bits out is going to be a lot moe productive, faster, than the current method. Surely a simple Values object like we're looking at right now has been used before, several times. It's easier to see the potential implementation 'gotchas' when there are already implementations to look at.
-
Sep 15, 2005, 07:53 #157
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by illusina
I would like to see __set()/__get() as well, but I think I've made all the arguments that I can in favor of that.
For this to work, we all have to get used to the idea that no perfect solution for this is possible in PHP. Until PHP implements a "real" property mechanism with support for getters and setters and reflection as part of the language, anything we do with "virtual" properties is going to have a few warts.
We should also discuss the Java style getXXX() and setXXX().
-
Sep 15, 2005, 09:18 #158
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
I agree with illusina that get()/set() are necessary because that's how everyone does it currently. The question of how we want people to do it in the future determines whether and how we add __set()/__get() or getXXX() and setXXX().
I would like to comment about the design process in this forum because I know it can feel like we are going in circles. Unlike most projects where there is a lead and a group of likeminded people, this process is decidedly democratic and therefore slower and messier. But the thing I have found from going through this a couple times is that it is very rewarding in hindsight because the market of ideas gives a much richer basis for going forward. However we do need to acknowledge that this process makes getting a complete design difficult in one pass (which is probably not a bad thing).
So I would propose that we acknowledge what we know and what we don't know, agree on what we agree on and push what we don't down the road, go off and implement something to see what the reality of our decisions is, then come back and "circle" again. It sounds rather Scrum like.Christopher
-
Sep 15, 2005, 13:20 #159
- Join Date
- Mar 2005
- Posts
- 53
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
. I know that it does go somewhere, but I simply feel that this thread would be better focused on goals and intentions rather than implementation (so that, rather than having two parallel threads within one, we can have one go and discuss one matter, and another another matter).
@Marcus: I didn't catch what the KeyedValues interface was. Simply another name for a "Properties" interface?
why not go find the places in the major frameworks or libraries that these sorts of things are being done, and find the common ground?
Unlike most projects where there is a lead and a group of likeminded people, this process is decidedly democratic and therefore slower and messier.
For this to work, we all have to get used to the idea that no perfect solution for this is possible in PHP. Until PHP implements a "real" property mechanism with support for getters and setters and reflection as part of the language, anything we do with "virtual" properties is going to have a few warts.
Regards,
Tyler Tompkins
-
Sep 15, 2005, 15:30 #160
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by illusina
. Sorry, I was just typing very hastily in an attempt to head off a thread fork. I think forking would have been a disaster. Some of the most productive threads on SitePoint have been long ones.
Originally Posted by illusina
We haven't worked out an SP etiquette for posting abstracts at the top of posts to allow people to skip the stuff they are not interested in. Hmm...another social software project is born...
Originally Posted by illusina
Originally Posted by illusina
Regarding Properties/KeyValues/Keyed there are a host of libraries to look at and just about every interface seems to be used: PEAR:: DB, PEAR:: DB_DataObject, Changes, Wact persistence, Propel, Wact Dataspace, J2EE properties, etc, etc.
Originally Posted by illusina
If you are not using C++ this won't mean a whole lot. Basically Boost is an exquisitely written small class library. A boost for PHP would be a wonderful thing (sigh).
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 15, 2005, 16:32 #161
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
We have the peers. We just need to keep things going at the review part.
So:
get()/set()?
__get()/__set()?
getXxx()/setXxx()?
What's in for the first pass? For example the Skeleton code is very basic and only uses get()/set(). What is a common minimum that WACT or Mojavi would use?Christopher
-
Sep 15, 2005, 17:10 #162
- Join Date
- May 2003
- Location
- Calgary, Alberta, Canada
- Posts
- 275
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
__get()/__set() is a non starter for me. I really dislike the use of this for many of the reasons already mentioned.
By get()/set() I assume you mean get('propertyName')/set('propertyName, 'value')? Im not a fan of this either. When comparing an interface like this to a get*()/set*('value') interface, like Fowler says, its about comparing an implicit interface to an explicit interface. Using the implicit interface, you have to look into the code to figure out how to do something (eg. How do I get the id of this User? Do I type get('id') or get('userId')?) Using an explicit Interface getting the Id is made obvious by the interface of the class because it has a getIdentity() method.
There are other disadvantages that come up in common situations using the get()/set() interface.
That said Im not even sure what types of objects youre expecting to impliment this interface. Depending on the answer to that question I might change my mind.I guess what Im saying is that both styles have advantages depending on their use. Maybe two seperate interfaces?
Could someone explain what value I would get out of using a framework that implemented these interfaces? Or what value a framework gets from implementing these interfaces? Sorry if this was covered, but this isnt immediately obvious to me.
-
Sep 15, 2005, 17:32 #163
- Join Date
- Mar 2005
- Posts
- 53
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
? As of this moment, Mojavi 3.0.0-DEV -- a framework that was written by my predecessor -- uses a single convention in two implementations for get/set operations. Within the Request class, for example, there is a getParameter/setParameter method battery Request also has a getAttribute/setAttribute method battery for IMC (inter module communication).
Now, regarding which one I would use...
Firstly, it should be noted that I'm taking this from a composition based design perspective. That is, my classes that use a Properties-implementation object or what-have-you will be composed of said object. They will not, for all the power within me, extend this a Properties-implementation class. Mojavi 3 was designed such that numerous classes extended from base "ParameterHolder" class, which provided all the setParameters/getParameters methods for numerous classes. Now, while this design choice worked, I have a great distaste for this sort of design manuevering. If an object is going to extend/inherit something, it should _be_ one of those somethings.
Now, since I'm approaching this from a composition perspective, it might be useful to show why a simple set/get might be a bad idea.
Let's say I have one Properties-implementation object composed into a Request object (for example). To address these, I might take the route of taking __call() and facading unknown methods calls to the inner Properties-implementation object. Now, if I wanted to add a second object to be composed, I would have to invent some sort of a regex to determine which of the two inner Properties-implementation objects I want to talk to. For example:
PHP Code:// .........
$obj = new SomeObject($propObj1, $propObj2)
// $obj is my __call enabled object composed of two other objects
$obj->setAttribute('somekey', 'some value');
$value = $obj->getParameter('somekey'); // error, no param
// ........
In closing, I feel it would be useful to keep in mind that composition based design is also an option for these objects.
Time for dinner!
Regards,
Tyler Tompkins
-
Sep 15, 2005, 20:14 #164
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
For our reference, here are the internal "interfaces" of the options:
Code:void set ( string name, mixed value ) mixed get ( string name ) void __set ( string name, mixed value ) mixed __get ( string name ) mixed __call ( string name, array arguments )
__call would require both a naming convention and some string ops on the name.Christopher
-
Sep 15, 2005, 23:15 #165
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
How about something specialized and yet simple like an interface for a URL object? Java already has that in the standard library. I haven't seen anything with a reasonable interface in PHP.
I don't want to derail the ongoing discussion; just consider it.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Sep 16, 2005, 06:40 #166
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi.
I'd have preferred to go down this route (mor espcialised role). Frankly Java has only started adding interface libraries after already having a class library. Building a lower level class library makes more sense to me. However, right now I don't want to derail an ongoing discussion.
So what is a Properties class (or KeyValues interface) used for? Database row, configuration, and what else?
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 16, 2005, 07:01 #167
-
Sep 16, 2005, 07:41 #168
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Jason Sweat ZCE - jsweat_php@yahoo.com
Book: PHP Patterns
Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
Detestable (adjective): software that isn't testable.
-
Sep 16, 2005, 07:59 #169
- Join Date
- Aug 2003
- Location
- Toronto
- Posts
- 300
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
-
Sep 16, 2005, 09:21 #170
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Random thoughts then:
So typical usage is like this...
PHP Code:class Request implements Properties { ... }
class Row implements Properties { ... }
class Configuration implements Properties { ... }
class Session implements Properties { ... }
Apart from caching mechanisms, I cannot see any need to decorate these objects or to proxy them further. They all seem pretty dead end value objects to me.
The following all look fine to me...
PHP Code:$memento = $session->get('thing');
$memento = $session['thing'];
$memento = $session->getThing();
$field = $row->thing;
$field = $row['thing'];
$field = $row->get('thing');
$setting = $configuration->get('thing');
$setting = $configuration->getThing();
$setting = $configuration['thing'];
$parameter = $request->get('thing');
$parameter = $request['thing'];
The accessor syntax (methods) and member syntax (__get()) have the problem that property keys are limited. I am swinging around to the square bracket syntax, but I bet there are a whole host of implementation problems with that. The simple get($name) syntax has the least problems, although it's not very exciting.
For testing the simplest is the array syntax (square brackets), because you can simply drop in a hash. As these classes are value objects though, I don't see any pressing need to mock these classes. Just pass in a bare Properties class instead (note the nameclash, the interface should be called something else).
It seems that the constraints on this interface are not so tight after all, at least for the examples proposed so far.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Sep 16, 2005, 10:53 #171PHP Code:
$setting = $configuration->get('thing');
$setting = $configuration->getThing();
$setting = $configuration['thing'];
PHP Code:$settings = $configuration->get('items');
$settings = $configuration->getItems;
$settings = $configuration->Items;
$settings = $configuration; //$configuration is the array
//
$settings = $configuration->get('items');
$setting = $settings['Thing'];
$setting = $configuration->getItem('Thing');
$setting = $configuration->Items['Thing'];
$setting = $configuration['Thing'];
$parameter = $request->Item('email');
$parameter = $request->getItem('email');
$parameter = $request->items->get('email');
-
Sep 16, 2005, 11:14 #172
- Join Date
- Aug 2004
- Location
- California
- Posts
- 1,672
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
And for set:
PHP Code:$configuration->set('Thing', $setting);
$configuration->setThing($setting);
$configuration->Thing = $setting;
$configuration['Thing'] = $setting; // needs SPL I assume
And what about path access?PHP Code:$configuration->set('Items/Thing', $setting);
$configuration->setItem_Thing($setting); // or some naming convention
// but
$configuration->Items->Thing = $setting;
$configuration['Items']['Thing'] = $setting; // SPL ?
$configuration->Items['Thing'] = $setting; // does this work with __set()?
Christopher
-
Sep 16, 2005, 11:31 #173
- Join Date
- Jan 2003
- Posts
- 5,748
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
PHP Code:$configuration['Thing'] = $setting; // needs SPL I assume
-
Sep 16, 2005, 12:48 #174
- Join Date
- Oct 2004
- Location
- Kansas City, MO
- Posts
- 68
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by arborint
Seriously, what's next, IntObject in which you can treat an object as an int? You can already sort of do with __toString() and echo'able objects, but I still don't know if its right.
As for the various interfaces, 1 and 3 both suffer from lack of real introspection. You would have to create a means of exposing the values it contains. For #2 to work, you would almost have to define __call to intercept all of the values, run some sort of preg on it to figure out what is being "set". At that point, we might as well release an abstract class with that implemented so people can extend it.
All this said, I would be for 1 or 3. I like 1 because it is easily backwards compatible. It's only problem is that you loose the ability do $properties->array[3]->value->names[4].
I can see where that adds extra flexibility, and as someone said, if this is going to be PHP, why not use PHP's methods for doing it. This example brings up another point: should it be assumed that if an array is set within a Properties value that it is itself a nested Properties?
Ok - where are we on name? Marcus' Keyed is sort of growing on me. Nice, short, and simply answers "this Container is Keyed" - "this Container is Properties" makes since too, but Keyed does describe exactly what you should expect.
One quick note... I do like the idea of having a series of classes that define generic behaviors, such as URL, URI, File, Directory, SymLink, etc., etc. At that point, we're starting to move to direct competition with PEAR. Maybe that's a good thing, but that's not what I had in mind with this. I don't know the history of Java and how its evolved as I haven't done much with it until the last year, and even then its been minimal, so maybe I am going at this backwards. If that's the general concensus, maybe we do need to relook at what we're doing here and start with a code repository of basic objects. I would still like to see them done as interfaces first, then everybody can create their own implementation based off of the File, URL, and such interface. I think I said it earlier, but a possible outgrowth of this interface repository would be a code repository of what's considered "best practices" for each of the interfaces. After all, there are only so many ways you can implement File.
-
Sep 16, 2005, 13:02 #175
- Join Date
- Mar 2005
- Posts
- 53
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
All of these are possible, but the last I'm against. Changing the behavior of an object via magic methods is ok, but changing the behavior of an internal type leads down a road that I think has a lot of boogie men waying to jump out and beat you up.
Ok - where are we on name? Marcus' Keyed is sort of growing on me. Nice, short, and simply answers "this Container is Keyed" - "this Container is Properties" makes since too, but Keyed does describe exactly what you should expect
I personally feel that "Properties" isn't a very useful name. "Mutable" is a rather...well....loaded term to use as an interface. Mutatorable maybe
. The only problem I forsee with this one is the lack of "get" in the "Mutable" interface description.
Keyed, however, does imply some interesting things. For an object to "implement" a "Keyed" interface you think to yourself that it has, somehow, provided "Keyed" methods. Seems fairly logical to me. Thoughts?
Regards,
Tyler Tompkins
Bookmarks