Re: AW: [PEAR-DEV] Package proposal Science_Weather
| From: | Stefan Neufeind | Date: | Fri, 22 Aug 2003 12:59:47 +0000 |
| Subject: | Re: AW: [PEAR-DEV] Package proposal Science_Weather | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-20397@lists.php.net to get a copy of this message | ||
On 22 Aug 2003 at 13:36, Stephan Schmidt wrote:
> > I wrote a small class which retreives XML data from weather.com. As
> > there's no _working_ code out there, doing that task, I'd thought
> > that it might be a good addition to PEAR. It is available under
> > http://www.pc4p.net/downloads/Science_Weather-1.0.tgz
>
> Basically I like the class very much, but I'd like to see it renamed
> to Science_Weather_WetterDotCom. I don't think that it's useful to go
> and create a unified interface for all services that are available, as
> they probably won't be interchangeable. I guess different services
> will provide different information and so using a distinct name for
> the class should be enough...
>
> If the name is changed, I'm +1 for this package, Coding style is
> great, PEAR dependency could be removed...
I agree with Stephan that you can't provide all functionality of a
service in a common way. What I thought of was returning an array
where the structure of the returned data is the same for all
services. E.g. have fields like "temperature", "climate", "humidity"
etc. that are fixed. If the class provides these information it
should be that these fields will be filled and not that they are
completely different in all implementations. For sure there are still
maybe some fields that one service provides and the other doesn't.
But that's no problem if you're using an associative array.
We shouldn't create too many packages for this and too many diverted
classes - my oppinion. Only to have *one package* Science_Weather is
agreed already, right? But if we have several classes in this package
I also expect to see a "common way" to talk to all services - a
common structure, common functions etc.
Stefan