Re: [PEPr] +1 for Networking::Net_IDNA

Stefan Neufeind wrote:

- Matthias seems to be a very reasonable person & sounds like he is going to make whatever changes are proven to be needed.

There are different ways that the class might take. And we already discussed that topic a while back (can dig up the archives, if you like). And at that point several people agreed upon features that should be added. Unfortunately it took David a while to add them, and then came the new proposal. I know at the current stage it's late - but the missing features ("changes needed" in my eyes) are the reason for -1 on my side. It's really not against the "quality of code" or even personally Matthias.

...Sounds like it should have been a conditional +1, then. No?

- I tend do disagree with your desire to constantly abstract classes into uber-classes (I think you had also suggested rolling Net_Geo and Net_GeoIP into one class). Net_GeoIP is certainly an implementation class & if Matthias says this is also then that makes sense to me.

Haven't looked at Net_Geo/Net_GeoIP yet, unfortunately. But you seem to know me quite well by assuming things I don't know myself :-)

Ok, I guess wrong Stefan :) -- apologies. The sentiment is very familiar on PEAR lists, though.

- I think that php5 interfaces can solve the aforementioned problem of API, anyway. And they can be added after the fact (when there's more than 1 implementation, for example).

Could you explain that in a bit more detail? Which way would you propose?

Well as has been discussed on list before, interfaces provide a nice way of consolidating a core API & encouraging other packages to implement to it. I don't know enough about this specific package or what you feel is missing to give you a good example for Net_IDNA, but the popular example from the past is Template, for example: interface ITemplate { public function clear($name); public function assign($name, $value); public function parse($toFilename = null); public function render(); } Any template implementation would be encouraged to implement that interface & packages that used templates (e.g. QuickForm) would require a class that implemented ITemplate instead of having to have separate drivers for all the different engines in PEAR. There wouldn't even need to be any official policy on whether classes would be required to implement existing interfaces; simply, it would be the smart thing to do if you wanted your class to be used.

- As for the bit about copyright, I didn't understand why that contributed to a -1 either way.

It was *not*. As explained above, the reason for the vote was something else. Rest of my conditional statement was a "deep source review".

Ok. I guess I didn't see the relevance of it in your mail, then.

- As for PHP4 support being a requirement, of course I disagree with that :) You can always create a backport for PHP4 if you desire.

Agreed! But if it takes quite few changes or maybe even just needs testing, I don't see why it should not be doable (read: be done).

So why don't you do it?

If the concern about letting this in is that it precludes a competing implementation, then PEAR needs to fix that issue.

The "competing" is not the point. I just think that the interface and direction is completely different. Unfortunately voting has already started - and I don't know how we might solve such a "this or that way"-voting anyway. Maybe we find a consense for the package? Or otherwise could we maybe let the devs on the list do a "extraordinary" vote which way to go?

Let both packages into PEAR & they can do battle for users. Sounds fun to watch :)

It was not about the package itself, but with the way it tries to solve the problem (the limited API, in my eyes). Also note that there was an implementation already present and discussed with the devs. Unfortunately I wasn't able to speak up before and it was not yet proposed because David's additions were still missing up to today (which were a conditions by a few devs, before it should go to a proposal).

Ok, well, hopefully some sort of consensus can be reached, as you say. To me this isn't a big deal. I looked at the code & it was clear that a lot of work went into it. I liked the presence of tests & the PHP5 aspect would make it useful for me. Matthias seems to be willing to work on changes where they make sense. For me that was more than enough to warrant +1. Hans