And these people shouldn't have personality/ego problems. This is why Stig is really suited to the job but unfortunately he doesn't have the time (I will not comment on whether he has the skill as I don't know). Diving off-topic, but sometimes people forget that personality can count for as much as skill - if the lead can't get on with the developers then nothing will go right.Originally posted by voostind
- A couple of knowledgable and/or experienced people should run the project.
How should they be handled?(Do you really want 'sequences' in PEAR DB? Short answer: NO!)
Do you not feel that coding standards are good then? I like them as it means that I can easily read new code - pull a random class from PHPClasses and try reading it straight off and I'd have problems. What? no whitespace in this file???- Those responsible for the library (the guys/women I just mentioned) must provide a guideline of what code should look like. I don't mean that in the sense of "Use tabs instead of spaces" or something like that. I mean it more like this: "If a function/method returns an object, it should always be of the same class.". Those guidelines force a programmer into thinking about what he's coding much better.
I understand what you mean though - there are more important standards that can be set than how the code should look
I'm going to disagree. Because these methods (and the get*() ones ) are so useful they should be in PEAR - but in a separate class that extends the standard database one. I feel taht it's better to have these useful tools distributed with the code to prevent everyone from having to write their own, but I agree with you that they shouldn't be in the main library.[b]So the method shouldn't be there. If an application needs something like 'fetchOne', let the application programmer put it in his/her own code.[B]
Nice of you to say soOh and a small point about all of you here: you are typically NOT the 'awful coders' I'm talked about in my previous post. Reason: your being here shows that you are aware of the difficulties of programming, and of the eagerness to learn.