12 messages in com.perforce.p4ruby[p4ruby] Canvassing opinions...| From | Sent On | Attachments |
|---|---|---|
| Tony Smith | 07 Dec 2004 09:12 | |
| Bennett, Patrick | 07 Dec 2004 09:42 | |
| Tony Smith | 07 Dec 2004 10:08 | |
| Bennett, Patrick | 07 Dec 2004 10:24 | |
| Shackelford, John-Mason | 07 Dec 2004 11:08 | |
| Johan Nilsson | 08 Dec 2004 00:11 | |
| Tony Smith | 08 Dec 2004 06:25 | |
| Bennett, Patrick | 08 Dec 2004 06:42 | |
| Shackelford, John-Mason | 08 Dec 2004 08:18 | |
| Tony Smith | 08 Dec 2004 08:20 | |
| Tony Smith | 08 Dec 2004 08:24 | |
| Tony Smith | 09 Dec 2004 05:47 |
| Subject: | [p4ruby] Canvassing opinions... |
|---|---|
| From: | Tony Smith (to...@smee.org) |
| Date: | 12/08/2004 06:25:47 AM |
| List: | com.perforce.p4ruby |
Hi John-Mason,
I've copied the list on this since you seem to be approaching this from the opposite point of view to Patrick.
I do like the idea of having a spec object.
A few comments about implementation... since you asked. :)
Absolutely!
Rather than maintaining compatibility by subclassing Hash, I'd rather see an option on P4 that would allow me to get back the new Spec object which would have its own inheritance hierarchy. I suggest this because I can't think of a case in which I actually need the functionality provided by Hash (except the ability to iterate through its keys) but I would like to be able to add behaviors (and your accessor methods) without having to worry about the collisions and the complexity / unintended consequences of inheriting all of the Hash functionality.
An interesting point, however don't you always have this problem when you subclass someone else's work? Even if I did as you suggest, you'd still have to worry about name collisions in future versions of the P4::Spec class - no? The methods and behaviour of Hash are at least well understood and well documented so you get a head start.
I did toy with defining P4::Spec as a subclass of Object and implementing the standard hash-style methods, but backwards compatibility is important to me and I don't know which Hash methods people have used so it seemed best to me to go with a Hash subclass.
Of course, most of the time I find myself writing objects to represent the Perforce model so as to hide the low level details of dealing with specs. It would be helpful to have the spec keys / accessors documented (I find myself working with them in IRB before coding so I know what in there), but other than that my interaction with them are relatively short-lived simple operations.
Ah thereby hangs a tale. I can't document them since they can vary depending on your server version and to a lesser extent on the exact command you issue. I can easily implement a method to tell you at run time what the fields are, but it's not something P4Ruby can know until you connect to your server. Essentially, I'm relying on the server to tell me what fields are in what specs - this gives us very good forwards and backwards compatibility.
Tony