Hello,
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.
I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.
+1/-1/0?
Cheers,
-- Pierre
Hello,
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
-0.
I would rather move more extensions from core to PECL, than from PECL to core.
But to make it possible we need at least to make PECL version aware, so maintainers can
release packages for different PHP versions without having to use thousands of #ifdef's.
So I'm basically against it, but I can live with this as long as the package is actively maintained.
--
Wbr,
Antony Dovgal
I would rather move more extensions from core to PECL, than from PECL to
core.
From my experiences the problem with this is many shared hosts wont install
non core modules, so the more modules moved from core to pecl the less
flexible php will be and the less use it will be.
I understand the need to keep the core code maintained and as clean and lean
as possible, but we also need to look at what developers need to create
applications that can be used with mass virtual hosting.
Regards
Marco
From my experiences the problem with this is many shared hosts wont install
non core modules, so the more modules moved from core to pecl the less
flexible php will be and the less use it will be.I understand the need to keep the core code maintained and as clean and
lean
as possible, but we also need to look at what developers need to create
applications that can be used with mass virtual hosting.
This is a valid point, but it represents a chicken-and-egg problem.
Shared hosts are used to deploying PHP Proper and ignoring PECL, because
in the past, core was the only repository for everything.
As PECL grows in popularity (and as users demand more PECL
installations), we can hope this these hosts become more flexible.
At least that's what I think.
S
Shared hosts are used to deploying PHP Proper and ignoring PECL, because
in the past, core was the only repository for everything.As PECL grows in popularity (and as users demand more PECL
installations), we can hope this these hosts become more flexible.
I agree and I also hope this is the case.
Regards
Marco
Sean Coates wrote:
From my experiences the problem with this is many shared hosts wont install
non core modules, so the more modules moved from core to pecl the less
flexible php will be and the less use it will be.I understand the need to keep the core code maintained and as clean and
lean
as possible, but we also need to look at what developers need to create
applications that can be used with mass virtual hosting.This is a valid point, but it represents a chicken-and-egg problem.
Shared hosts are used to deploying PHP Proper and ignoring PECL, because
in the past, core was the only repository for everything.As PECL grows in popularity (and as users demand more PECL
installations), we can hope this these hosts become more flexible.At least that's what I think.
I think we should make this a PHP6 todo item. A new major version is a
better opportunity to get a change of minds, than a creeping slow
change, which is about creating sufficient pain in our users so that
shared hosters finally get the clue.
Until then we should add extensions that we think are reasonably
frequently required and move out the ones that we deem obscure. I think
zip is quite reasonable to get added.
As for the coordination of PECL packages that are symlinked to
internals, it sounds like this really needs some thinking before PHP6,
because there are already a number of extensions affected and it does
sound like its a little bumpy.
regards,
Lukas
I would rather move more extensions from core to PECL, than from
PECL to
core.From my experiences the problem with this is many shared hosts wont
install
non core modules, so the more modules moved from core to pecl the less
flexible php will be and the less use it will be.I understand the need to keep the core code maintained and as clean
and lean
as possible, but we also need to look at what developers need to
create
applications that can be used with mass virtual hosting.
Let's move MySQL to PECL, and then the hosts will have to re-think
that brain-less choice. :-)
I'm actually half-serious here...
Move enough crucial things to PECL, and they'll start being smart
about their install, or they'll start losing customers.
--
Like Music?
http://l-i-e.com/artists.htm
Move enough crucial things to PECL, and they'll start being smart
about their install, or they'll start losing customers.
Or PHP will become non viable as a language and people with start using ruby
on rails ;-)
Regards
Marco
Hello,
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
-0.
I would rather move more extensions from core to PECL, than from PECL to core.
I agree here, I am also not sure whether picking the extremely short
classname Zip is actually a good thing. Perhaps ZipArchive or ZipFile
would be more fitting in the first place, not even considering the issue
you can have with other libraries. Complaining against the name "Date"
and then just going in another ext with "Zip" just feels wrong.
Although the zip ext is a useful thing to have, I think it should stay
in PECL as Tony says we're trying to move things to PECL... so a -1 from
me on the current proposal to add ext/zip to core with the Zip
classname.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Although the zip ext is a useful thing to have, I think it should stay
in PECL as Tony says we're trying to move things to PECL... so a -1 from
me on the current proposal to add ext/zip to core with the Zip
classname.
Seems silly to have a place like PECL where extensions can live their
own life with their own release-cycles when people want to bundle
every useless extension with PHP like it was before extentions began
moving to PECL.
regards,
Robin
Although the zip ext is a useful thing to have, I think it should stay
in PECL as Tony says we're trying to move things to PECL... so a -1 from
me on the current proposal to add ext/zip to core with the Zip
classname.
Seems silly to have a place like PECL where extensions can live their
own life with their own release-cycles
That's another problem for another offtopic discussion:
"own release cycle" is just a myth, because of the "symlinks" used to link PECL extensions to core.
You can't have, for example, development version in PECL and stable version in the core,
you HAVE to stabilize your code before any PHP release, because it's basically the same code.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
Seems silly to have a place like PECL where extensions can live their
own life with their own release-cyclesThat's another problem for another offtopic discussion:
"own release cycle" is just a myth, because of the "symlinks" used to
link PECL extensions to core.
You can't have, for example, development version in PECL and stable
version in the core, you HAVE to stabilize your code before any PHP
release, because it's basically the same code.
Well, an extension author could choose to import the extension to
/php-src instead of creating a link, no?
Regards,
Michael
Antony Dovgal wrote:
-0.
I would rather move more extensions from core to PECL, than from PECL
to core.
I second that emotion.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.
I don't remember seeing a discussion on including Zip in core (perhaps I
just missed it, but a quick search didn't turn it up). I think Zip is
better suited as a PECL module.
Tony mentioned another issue: the headache of maintaining PECL code
between PHP versions. This is a valid point (and he can elaborate if he
likes), but is a separate issue.
IMO, core shouldn't grow for modules like this (and JSON -- but the JSON
discussion certainly DID take place and the module seems tiny enough to
be benign); the idea is to move non-essential modules OUT of the main
distribution and into PECL, not the other way.
-1 on Zip in 5.2.0
-1 on Zip in 5.2.1
S
Hello,
Tony mentioned another issue: the headache of maintaining PECL code
between PHP versions. This is a valid point (and he can elaborate if he
likes), but is a separate issue.
I'm very aware of the PECL issues and that's irrelevant in this current poll.
IMO, core shouldn't grow for modules like this (and JSON -- but the JSON
discussion certainly DID take place and the module seems tiny enough to
be benign); the idea is to move non-essential modules OUT of the main
distribution and into PECL, not the other way.
The discussions to move it out never took place either, that's also a
problem. Also consider this version as a complete new package, it
fits in your definition.
--Pierre
Hello,
Tony mentioned another issue: the headache of maintaining PECL code
between PHP versions. This is a valid point (and he can elaborate if he
likes), but is a separate issue.I'm very aware of the PECL issues and that's irrelevant in this current poll.
IMO, core shouldn't grow for modules like this (and JSON -- but the JSON
discussion certainly DID take place and the module seems tiny enough to
be benign); the idea is to move non-essential modules OUT of the main
distribution and into PECL, not the other way.The discussions to move it out never took place either, that's also a
problem.
You can't move it out when it is not in yet...
Derick
On Thu, 20 Jul 2006 09:44:38 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
Hello,
Tony mentioned another issue: the headache of maintaining PECL
code between PHP versions. This is a valid point (and he can
elaborate if he likes), but is a separate issue.I'm very aware of the PECL issues and that's irrelevant in this
current poll.IMO, core shouldn't grow for modules like this (and JSON -- but
the JSON discussion certainly DID take place and the module seems
tiny enough to be benign); the idea is to move non-essential
modules OUT of the main distribution and into PECL, not the other
way.The discussions to move it out never took place either, that's also
a problem.You can't move it out when it is not in yet...
It was in and moved out without much discussions. What I mean is that
we have to discuss which extensions can or should be moved out, and on
the lists. So we can do it the right way.
-- Pierre
+1
I wish to see Zip in PHP, it's a popular archive and plus used in .jar
implementation and .jar in its turn is used in other file formats, for
example OpenDocument one..
Hello,
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
Cheers,
-- Pierre--
--
sincerely yours,
Alexander Pak
+1/-1/0?
+1 from me, I still to this day get people pestering me about my article
on creating .zip files from pure PHP -- a real extension is clearly
useful.
John
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
-1 in core, PECL is the place for this.
-100 for class called Zip for the same reasons why we can not have
Date and TimeZone classes.
--Jani
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
-1 in core, PECL is the place for this. -100 for class called Zip for the same reasons why we can not have Date and TimeZone classes.
With the difference that I'm honest and do inform everyone. But your
point is, in this case, wrong:
- it is experimental and not enabled by default. Date is enabled by default
- if it is enabled by default, it will not be before php6 at best,
meaning it is a major version - I never saw any kind of code using Zip
This extension was wrongly moved to PECL. It is time to fix this
mistake. OpenDocument support and other zip based system justify this
addition even more.
--Pierre
--Pierre
Hello Pierre,
well Jan has a has a very good point here. Just as it was unlikely that
a class called PDO had been implemented a hundred times, it didn't cause
any namespace clashes. However it is fairly likely that some frameworks
bring Zip support and have a class named Zip. If not then there probably
is no mainstream use for a Zip class and inclusion to core makes little
sense. So for me this falls clearly under the terms of our naming scheme
(see [7] below) and shows we should extend this rule a bit to prevent
obvious and very short names. Obvious here imo means terms that are
likely to be used in a frameworks/applications. To me Zip definitively
is. Apart from renaming i have nothing against moving it to core.
Just a short note, you accused Derick of sneaking in stuff that was more
or less decided, well obviously he could have done it early - hadn't he
done much other work and haven't he been on vacation either. So thinking
he did is fairly understandable, though i personally doubt that. But be
it that. Why now do the same bad trick again, and that without even
having dicussed the technical part of inclusion beforehand (like we did
for date)?
best regards
marcus
[7] Classes should be given descriptive names. Avoid using abbreviations where
possible. Each word in the class name should start with a capital letter,
without underscore delimiters (CampelCaps starting with a capital letter).
The class name should be prefixed with the name of the 'parent set' (e.g.
the name of the extension).
Good:
'Curl'
'FooBar'
Bad:
'foobar'
'foo_bar'
Warning: this is no acusation...if you feel like you probably better not
answer at all.
Thursday, July 20, 2006, 1:11:24 AM, you wrote:
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
-1 in core, PECL is the place for this. -100 for class called Zip for the same reasons why we can not have Date and TimeZone classes.
With the difference that I'm honest and do inform everyone. But your
point is, in this case, wrong:
- it is experimental and not enabled by default. Date is enabled by default
- if it is enabled by default, it will not be before php6 at best,
meaning it is a major version- I never saw any kind of code using Zip
This extension was wrongly moved to PECL. It is time to fix this
mistake. OpenDocument support and other zip based system justify this
addition even more.
--Pierre
--Pierre
Best regards,
Marcus
On Thu, 20 Jul 2006 09:51:37 +0200
helly@php.net (Marcus Boerger) wrote:
Hello Pierre,
well Jan has a has a very good point here. Just as it was unlikely
Jan?
that a class called PDO had been implemented a hundred times, it
didn't cause any namespace clashes. However it is fairly likely that
some frameworks bring Zip support and have a class named Zip. If not
then there probably is no mainstream use for a Zip class and
inclusion to core makes little sense.
No mainstream use? Which other examples do you need? There is hundred
of usages of the zip archives.
So for me this falls clearly
under the terms of our naming scheme (see [7] below) and shows we
should extend this rule a bit to prevent obvious and very short
names.
Again, I have nothing against short names. We have to inform our users
and prepare them.
Obvious here imo means terms that are likely to be used in a
frameworks/applications. To me Zip definitively is. Apart from
renaming i have nothing against moving it to core.Just a short note, you accused Derick of sneaking in stuff that was
more or less decided, well obviously he could have done it early -
hadn't he done much other work and haven't he been on vacation
either. So thinking he did is fairly understandable, though i
personally doubt that. But be it that. Why now do the same bad trick
again, and that without even having dicussed the technical part of
inclusion beforehand (like we did for date)?
I still accuse him to sneak things in. He did it twice for the same
thing.
Don't compare apples and oranges. This thread is exactly what has
missed for Date.
Cheers,
--Pierre
Hello,
[7] Classes should be given descriptive names. Avoid using abbreviations where
possible. Each word in the class name should start with a capital letter,
without underscore delimiters (CampelCaps starting with a capital letter).
The class name should be prefixed with the name of the 'parent set' (e.g.
the name of the extension).Good: 'Curl'
Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous.
-- Pierre
Why not delay Zip until 5.3 and make an E_STRICT or E_NOTICE in 5.2 for the
Zip classname being a reserved word?
In fact if we could come up with a list of class names php wants to reserve
for itself then we could make them all raise notices so that people have
time to fix their code.
Regards
Marco
Hello,
Why not delay Zip until 5.3 and make an
E_STRICTorE_NOTICEin 5.2 for the
Zip classname being a reserved word?
It makes little sense as it is not enable by default. A visible entry
in the NEWS and Changelog should be enough.
Note that it is exactly what I proposed to solve the date class
problem, but it is hopeless.
In fact if we could come up with a list of class names php wants to reserve
for itself then we could make them all raise notices so that people have
time to fix their code.
Yes, I'm still wating a discussion about that, but it seems that I
lost my last illusions about PHP being able to prevent troubles
instead of acting in the hurry like we just did.
--Pierre
Hello Marco,
if we plan to include new classes and have E_STRICT (imo not notice) to
inform about the inclusion with the next minor version update would be a
good thing. To stay with the example at hand, inclusion then would go
like accepting Zip during 5.2 phase. Adding the E_STRICT at the point the
decision was done and then in 5.3 do the actaul inclusion.
best regards
marcus
Thursday, July 20, 2006, 1:41:48 PM, you wrote:
Why not delay Zip until 5.3 and make an
E_STRICTorE_NOTICEin 5.2 for the
Zip classname being a reserved word?
In fact if we could come up with a list of class names php wants to reserve
for itself then we could make them all raise notices so that people have
time to fix their code.
Regards
Marco
Best regards,
Marcus
if we plan to include new classes and have
E_STRICT(imo not notice) to
inform about the inclusion with the next minor version update would be a
good thing. To stay with the example at hand, inclusion then would go
like accepting Zip during 5.2 phase. Adding theE_STRICTat the point the
decision was done and then in 5.3 do the actaul inclusion.
I agree this is a good idea. Although after 5.2 we could think about some
core class names and mark them all as E_STRICT even if they wouldnt be
included in the 5.x series.
I think Pierre mentioned starting a new thread to look at what names PHP
would like to reserve, I think it could be a good idea to start this sooner
rather than later.
Regards
Marco
Hello Pierre,
Thursday, July 20, 2006, 12:08:10 PM, you wrote:
Hello,
[7] Classes should be given descriptive names. Avoid using abbreviations where
possible. Each word in the class name should start with a capital letter,
without underscore delimiters (CampelCaps starting with a capital letter).
The class name should be prefixed with the name of the 'parent set' (e.g.
the name of the extension).Good: 'Curl'
Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous.
When Derick began with Date naming it different was rediculous, too.
Why not ZipFile, ZipArchieve, ZipClass or PhpZip. At least the latter
probably noone has used so far. And i can only repeat myself, it seems
highly likely that there are classes named Zip out there.
Best regards,
Marcus
where
possible. Each word in the class name should start with a capital
letter,
without underscore delimiters (CampelCaps starting with a capital
letter).
The class name should be prefixed with the name of the 'parent set'
(e.g.
the name of the extension).Good: 'Curl'Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous.
It is, but alternatives such as ZipFile, ZipArchive can work just as
well. IMO the classnames should be nouns... and what does "Zip" itself
really say?
Derick
where
possible. Each word in the class name should start with a capital
letter,
without underscore delimiters (CampelCaps starting with a capital
letter).
The class name should be prefixed with the name of the 'parent set'
(e.g.
the name of the extension).Good: 'Curl'Curl is good but not Zip? Should I use ZipZip? Come one, it is ridiculuous.
It is, but alternatives such as ZipFile, ZipArchive can work just as
well. IMO the classnames should be nouns... and what does "Zip" itself
really say?
Do you really ask me what Zip say?
For 99.999% of PHP users, I think it is pretty obvious, in a
programming context with an extension called "zip", and even more when
they have enabled it themselves. There is maybe a couple of people who
will expect a kind a php based zipper, but really, do we care?
It makes no sense to rename it (for all reasons I listed above). I can
wait php 6.0 or until I eclipsed Methuselah's age.
Users will suffer from your choices, not me, too bad.
Cheers,
--Pierre
Pierre wrote:
where
possible. Each word in the class name should start with a capital
letter,
without underscore delimiters (CampelCaps starting with a capital
letter).
The class name should be prefixed with the name of the 'parent
set'
(e.g.
the name of the extension).Good: 'Curl'Curl is good but not Zip? Should I use ZipZip? Come one, it is
ridiculuous.It is, but alternatives such as ZipFile, ZipArchive can work just as
well. IMO the classnames should be nouns... and what does "Zip" itself
really say?Do you really ask me what Zip say?
Well, in the US at least, Zip says Zip Code to me. Zip compression
would be my second guess so it isn't completely obvious.
-Rasmus
Hello,
Well, in the US at least, Zip says Zip Code to me. Zip compression
would be my second guess so it isn't completely obvious.
It is a ZipCode, exactly.
--Pierre
Pierre wrote:
Hello,
Well, in the US at least, Zip says Zip Code to me. Zip compression
would be my second guess so it isn't completely obvious.It is a ZipCode, exactly.
And by the same logic, a Zip archive is a ZipArchive. Do a web search
for "zip" and you will find that half of the first set of results are
about zip archives and the other half are about zip codes. Why are you
assuming zip automatically means zip archive to people? It certainly
doesn't to me, but perhaps I am too much of a Unix guy so zip archives
have never been of much use.
-Rasmus
Hello,
Pierre wrote:
Hello,
Well, in the US at least, Zip says Zip Code to me. Zip compression
would be my second guess so it isn't completely obvious.It is a ZipCode, exactly.
And by the same logic, a Zip archive is a ZipArchive. Do a web search
for "zip" and you will find that half of the first set of results are
about zip archives and the other half are about zip codes. Why are you
assuming zip automatically means zip archive to people?
Because they wil have to enable it manually, after having read:
"Include Zip read/write support"
I doubt anyone sane is going to active this option and think it can
then read and write Zip in php.
It certainly doesn't to me, but perhaps I am too much of a Unix guy so zip archives
have never been of much use.
I'm an unix guy too, let see what my current lovely unix knows about zip:
man zip
" zip, zipcloak, zipnote, zipsplit - package and compress (archive) files..."
My other box has unzip too, I'm not sure what how I can unmake a zip
code though ;-)
I'm starting to wonder who are our targets, the mid americans or the
programmers?
--Pierre
Pierre,
Let's stop with hypocrisy. You wanted Derick to change 'Date' class
names, so he did it. Now you are arguing that the same rules shouldn't
apply to you? Enough.
-Andrei
Hello,
Pierre wrote:
Hello,
Well, in the US at least, Zip says Zip Code to me. Zip compression
would be my second guess so it isn't completely obvious.It is a ZipCode, exactly.
And by the same logic, a Zip archive is a ZipArchive. Do a web search
for "zip" and you will find that half of the first set of results are
about zip archives and the other half are about zip codes. Why are
you
assuming zip automatically means zip archive to people?Because they wil have to enable it manually, after having read:
"Include Zip read/write support"I doubt anyone sane is going to active this option and think it can
then read and write Zip in php.It certainly doesn't to me, but perhaps I am too much of a Unix guy
so zip archives
have never been of much use.I'm an unix guy too, let see what my current lovely unix knows about
zip:man zip
" zip, zipcloak, zipnote, zipsplit - package and compress (archive)
files..."My other box has unzip too, I'm not sure what how I can unmake a zip
code though ;-)I'm starting to wonder who are our targets, the mid americans or the
programmers?--Pierre
Pierre,
Let's stop with hypocrisy. You wanted Derick to change 'Date' class
names, so he did it. Now you are arguing that the same rules shouldn't
apply to you? Enough.
I never wanted him to change it. I wanted him to respect our decisions
and to do it in time (warning first and then 2 releases). But don't
put words in my word, I was always in favour of using common names in
PHP, but not in such chaotic ways.
About hypocrisy, thank you for the compliment.
--Pierre
Regardless of whether you wanted him to rename it or not release it
at all, you were concerned about the impact a class named 'Date'
would have on PEAR and other userland apps, were you not? How is this
different from pecl/zip?
-Andrei
I never wanted him to change it. I wanted him to respect our decisions
and to do it in time (warning first and then 2 releases). But don't
put words in my word, I was always in favour of using common names in
PHP, but not in such chaotic ways.About hypocrisy, thank you for the compliment.
--Pierre
Hello,
Regardless of whether you wanted him to rename it or not release it
at all, you were concerned about the impact a class named 'Date'
would have on PEAR and other userland apps, were you not?
Actually no.
As Lukas and I pointed out many times, PEAR itself was not my
concerns in 5.2.0. But the noises generated by the "It's PEAR, Shoot!"
effect silenced any of my real worries. And I think anyone does not
even remember what I actually said, but only that pear is gulty,
right?
How is this different from pecl/zip?
Excuse me, but have I really to repeat the same thing over and over?
Ok, parce que c'est toi:
- Not enable by default, you have to manually active it. Date is
enabled by default - I will not propose to enabled it by default as long as this naming
problem is not solved once and for all (that will bring us to php6
imho) - I actually ask the lists before commiting it. Next time maybe not,
it is way easier to get things in without asking
Cheers,
--Pierre
Hello Pierre,
Friday, July 21, 2006, 2:56:00 AM, you wrote:
Hello,
Regardless of whether you wanted him to rename it or not release it
at all, you were concerned about the impact a class named 'Date'
would have on PEAR and other userland apps, were you not?
Actually no.
As Lukas and I pointed out many times, PEAR itself was not my
concerns in 5.2.0. But the noises generated by the "It's PEAR, Shoot!"
effect silenced any of my real worries. And I think anyone does not
even remember what I actually said, but only that pear is gulty,
right?
How is this different from pecl/zip?
Excuse me, but have I really to repeat the same thing over and over?
Ok, parce que c'est toi:
- Not enable by default, you have to manually active it. Date is
enabled by default
There is absolutley no difference here. Core extensions will be enabled
by most hosters/users. So what?
- I will not propose to enabled it by default as long as this naming
problem is not solved once and for all (that will bring us to php6
imho)- I actually ask the lists before commiting it. Next time maybe not,
it is way easier to get things in without asking
We all normally ask before we commit. And we have a lot of discussions
going on in the back when it comes to specific parts where only a few
are involved - all after discussing and a general agreement on something.
That put aside, Derick asked before 5.1 and it was denied because of PEAR
and nothing else. And it was also agreed that it would be enabed for 5.2.
So i'd like to kindly ask you to stick to discuss first semantics.
marcus
Hello Pierre,
Friday, July 21, 2006, 12:10:02 AM, you wrote:
Hello,
Pierre wrote:
Hello,
Well, in the US at least, Zip says Zip Code to me. Zip compression
would be my second guess so it isn't completely obvious.It is a ZipCode, exactly.
And by the same logic, a Zip archive is a ZipArchive. Do a web search
for "zip" and you will find that half of the first set of results are
about zip archives and the other half are about zip codes. Why are you
assuming zip automatically means zip archive to people?
Because they wil have to enable it manually, after having read:
"Include Zip read/write support"
I doubt anyone sane is going to active this option and think it can
then read and write Zip in php.
It certainly doesn't to me, but perhaps I am too much of a Unix guy so zip archives
have never been of much use.
I'm an unix guy too, let see what my current lovely unix knows about zip:
man zip
" zip, zipcloak, zipnote, zipsplit - package and compress (archive) files..."
So you're class does only allow to compress, is that what you are trying
to explain?
My other box has unzip too, I'm not sure what how I can unmake a zip
code though ;-)
I'm starting to wonder who are our targets, the mid americans or the
programmers?
As a programmer i saw a huge amount of 'zip' columns in databases as
well as tables that match zip codes to names, which were named 'zip'.
And a lot of people actually use table names for class names.
Best regards,
Marcus
Hello,
So you're class does only allow to compress, is that what you are trying
to explain?
Only than being a unix does make you clueless about zip. And please
stop your pointless comments as you perfectly know what provides the
class.
Now we can either continue this endless FUD about renaming Zip or just
accept that we don't agree and wait the next names clashes to finally
take the right decisions.
Or we finally have this discussion, act and see what will fit best for
ZipCompressedFile and DateTimeZone and friends.
--Pierre
Pierre wrote:
Hello,
So you're class does only allow to compress, is that what you are trying
to explain?Only than being a unix does make you clueless about zip. And please
stop your pointless comments as you perfectly know what provides the
class.Now we can either continue this endless FUD about renaming Zip or just
accept that we don't agree and wait the next names clashes to finally
take the right decisions.Or we finally have this discussion, act and see what will fit best for
ZipCompressedFile and DateTimeZone and friends.
We did actually come to a consensus Pierre. And that is that PHP owns
the top-level namespace, but we should use decent descriptive names and
avoid any obvious clashes.
ext/date does date, time and timezone stuff, so its classes become
DateTime and DateTimeZone. pecl/zip deals with Zip archives,
compressing, decompressing, listing, etc. so it makes plenty of sense to
call it ZipArchive. And yes, if we some day do a Zip code extension, it
would likely be called ZipCode and not Zip as well.
If anybody doesn't think this is the consensus we reached, please speak
up, but I am pretty sure we have majority agreement here, so let's just
please move on.
-Rasmus
Pierre wrote:
Hello,
So you're class does only allow to compress, is that what you are trying
to explain?Only than being a unix does make you clueless about zip. And please
stop your pointless comments as you perfectly know what provides the
class.Now we can either continue this endless FUD about renaming Zip or just
accept that we don't agree and wait the next names clashes to finally
take the right decisions.Or we finally have this discussion, act and see what will fit best for
ZipCompressedFile and DateTimeZone and friends.We did actually come to a consensus Pierre. And that is that PHP owns
the top-level namespace, but we should use decent descriptive names and
avoid any obvious clashes.
I don't trust anymore our concensus, I'm (really) sorry.
ext/date does date, time and timezone stuff, so its classes become
DateTime and DateTimeZone. pecl/zip deals with Zip archives,
compressing, decompressing, listing, etc. so it makes plenty of sense to
call it ZipArchive. And yes, if we some day do a Zip code extension, it
would likely be called ZipCode and not Zip as well.
Well, I'm playing the evil, but I really hate to be forced/insulted in
such ways when I politely ask if you would like to have it.
If anybody doesn't think this is the consensus we reached, please speak
up, but I am pretty sure we have majority agreement here, so let's just
please move on.
I spoke up already, many times. We have to discuss this problem once
and for all. Block the largest possible common names. Then clearly and
very loudly announce that we will use them as we like whenever we like
from PHP X.Y.Z. Anything else is a bad choice, why?
We don't solve any problem, we keep acting in the hurry like we did
for Date. Our users will have no idea about this "new" rule and we
will have to discuss it again and again for each release, but without
me, I will stand another release like 5.1.0 or 5.2.0, sorry.
I reitere my proposal a last time, let fix this issue once and for all
and then I will consider to rename Zip if it is required (no, don't
answer now about that). But without this discussion, I will stay in
the kingdom of freedom, named PECL, et vive le Roi.
Cheers,
--Pierre
Pierre wrote:
I reitere my proposal a last time, let fix this issue once and for all
and then I will consider to rename Zip if it is required (no, don't
answer now about that). But without this discussion, I will stay in
the kingdom of freedom, named PECL, et vive le Roi.
I'll hold you to the "last time" quote there.
The issue has been fixed and I outlined it as clearly as I could. We
are not going to go through and reserve names just for the sake of
reserving names and thus potentially break existing code. We will
choose the best names as we go that best describes the functionality
whatever the code does. If users want to make completely certain we
won't step on their symbol names, they can use an underscore somewhere
in the symbol name or simply use quite explicit names. It's not rocket
science.
Decision made, please stop bickering.
-Rasmus
Totally agreed.
-Andrei
We did actually come to a consensus Pierre. And that is that PHP
owns the top-level namespace, but we should use decent descriptive
names and avoid any obvious clashes.ext/date does date, time and timezone stuff, so its classes become
DateTime and DateTimeZone. pecl/zip deals with Zip archives,
compressing, decompressing, listing, etc. so it makes plenty of
sense to call it ZipArchive. And yes, if we some day do a Zip code
extension, it would likely be called ZipCode and not Zip as well.If anybody doesn't think this is the consensus we reached, please
speak up, but I am pretty sure we have majority agreement here, so
let's just please move on.-Rasmus
Rasmus Lerdorf wrote:
And by the same logic, a Zip archive is a ZipArchive. Do a web search
for "zip" and you will find that half of the first set of results are
about zip archives and the other half are about zip codes. Why are you
assuming zip automatically means zip archive to people? It certainly
doesn't to me, but perhaps I am too much of a Unix guy so zip archives
have never been of much use.
I initially agreed with Pierre, but Rasmus has a point. Zip = zip code
in the US. When people talk about a .zip file, they say zip file.
--
Brian Moon
http://dealnews.com/
Its good to be cheap =)
Do you really ask me what Zip say?
You miss the point. If you do "new Zip" ... then I've no idea what the
object you get represents. However, doing "new ZipArchive" makes sense
as then you know the object represents a ZipArchive for example. Just
"Zip" doesn't say anything about the object so I consider it a bad
classname.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Do you really ask me what Zip say?
You miss the point. If you do "new Zip" ... then I've no idea what the
object you get represents. However, doing "new ZipArchive" makes sense
as then you know the object represents a ZipArchive for example. Just
"Zip" doesn't say anything about the object so I consider it a bad
classname.
I have a good hundred (verbose) users (which mails me about it) out
there, for example one of them is Alexander Pak, Summer Of Code Open
Document project. They asked me many many things. One thing was to
bring consistency to the API, move to a stable state and... bundled
it as soon as possible. But they never had any kind of comments or
questions about what is "new Zip".
There will be more objects in the future, but not related directly to
the zip itself or its properties (no ZipFile object for example). I'm
thinking about iterators or helpers for complex operations. For these
classes, yes, it makes sense to name them ZipIteratorXxx or ZipFooBar.
--Pierre
Derick Rethans wrote:
Do you really ask me what Zip say?
You miss the point. If you do "new Zip" ... then I've no idea what the
object you get represents. However, doing "new ZipArchive" makes sense
as then you know the object represents a ZipArchive for example. Just
"Zip" doesn't say anything about the object so I consider it a bad
classname.
I am definately in the camp that wants zip handling in core, but I also
think Derick's naming argument makes sense.
regards,
Lukas
If not then there probably
is no mainstream use for a Zip class and inclusion to core makes little
sense.
Hi,
I took this from wikipedia(
http://en.wikipedia.org/wiki/ZIP_%28file_format%29):
Microsoft has also included minimal built-in ZIP support (under the name
"compressed folders") in later versions of its
Windowshttp://en.wikipedia.org/wiki/Microsoft_Windows operating
system http://en.wikipedia.org/wiki/Operating_system. Apple also included
built-in ZIP support in Mac OS X http://en.wikipedia.org/wiki/Mac_OS_X
v10.3 and later.
Some software uses the ZIP file format as a wrapper for a large number of
small items. Generally when this is done a different file extension is used.
Examples of this usage are
Javahttp://en.wikipedia.org/wiki/Java_programming_language
JAR http://en.wikipedia.org/wiki/JAR_%28file_format%29 files, id
Softwarehttp://en.wikipedia.org/wiki/Id_Software.pk3/.pk4 files,
package files for
StepMania http://en.wikipedia.org/wiki/StepMania and
Winamphttp://en.wikipedia.org/wiki/Winamp,
XPInstall http://en.wikipedia.org/wiki/XPInstall, and some
OpenOffice.orghttp://en.wikipedia.org/wiki/OpenOffice.orgdocument
formats. The
OpenDocument http://en.wikipedia.org/wiki/OpenDocument format usually uses
the JAR file format
http://en.wikipedia.org/wiki/JAR_%28file_format%29internally, so it
can be easily uncompressed and compressed using tools for
ZIP files.
sincerely yours,
Alexander Pak
Jani Taskinen wrote:
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.+1/-1/0?
-1 in core, PECL is the place for this. -100 for class called Zip for the same reasons why we can not have Date and TimeZone classes.
Comparing apples and organges here, eh? Tried to disable ext/date recently?
FYU, ext/date is not only enabled by default, but it cannot be disabled.
Even pcre can still be disabled.
Edin
Even pcre can still be disabled.
That's on the todo for php 6 though.
Derick
Pierre wrote:
Hello,
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.
+1 for inclusion of zip to 5.2.0.
Zip is optional extension that is not enabled by default. Its a low-risk
and very useful addition.
Edin
Pierre wrote:
Please note that it intoduces a new class called Zip, but I never saw a
php zip implementation named Zip.
Uh, well this already was on thedailywtf...
See here, http://thedailywtf.com/forums/thread/80949.aspx
Rainer
On Thu, 20 Jul 2006 04:27:19 +0200
mueller_rainer@gmx.de (Rainer Müller) wrote:
Pierre wrote:
Please note that it intoduces a new class called Zip, but I never
saw a php zip implementation named Zip.Uh, well this already was on thedailywtf...
See here, http://thedailywtf.com/forums/thread/80949.aspx
If you read the thread it is obviously his mistake. Secondly, what does
that have to do with our problems?
The extension is not enabled by default and is experimental. If some
people enables it in production (on windows or not) is not our problem.
-- Pierre
Hello Pierre,
actually i think we should no longer accept EXPERIMENTAL extensions in
core, though from my view at pecl/zip it should have reached a stable
state just right now, am i correct?
best regards
marcus
Thursday, July 20, 2006, 12:05:08 PM, you wrote:
On Thu, 20 Jul 2006 04:27:19 +0200
mueller_rainer@gmx.de (Rainer Müller) wrote:
Pierre wrote:
Please note that it intoduces a new class called Zip, but I never
saw a php zip implementation named Zip.Uh, well this already was on thedailywtf...
See here, http://thedailywtf.com/forums/thread/80949.aspx
If you read the thread it is obviously his mistake. Secondly, what does
that have to do with our problems?
The extension is not enabled by default and is experimental. If some
people enables it in production (on windows or not) is not our problem.
-- Pierre
Best regards,
Marcus
Hello Pierre,
actually i think we should no longer accept EXPERIMENTAL extensions in
core, though from my view at pecl/zip it should have reached a stable
state just right now, am i correct?
Ok, it is getting really ridiculuous. Where have you found this idea?
What does mean EXPERIMENTAL? It means that's the API can change, or
that you should try it and help us to make it stable as soon as
possible.
Time to be serious now?
--Pierre
Hello Pierre,
Thursday, July 20, 2006, 11:15:05 PM, you wrote:
Hello Pierre,
actually i think we should no longer accept EXPERIMENTAL extensions in
core, though from my view at pecl/zip it should have reached a stable
state just right now, am i correct?
Ok, it is getting really ridiculuous. Where have you found this idea?
What does mean EXPERIMENTAL? It means that's the API can change, or
that you should try it and help us to make it stable as soon as
possible.
Time to be serious now?
I am but you obviously prefer to bring instable suff into core or what
now? Until now my idea of Zip was a stable idea so you could easily have
removed the tag file. The above said makes me thing that it is far away
from stable otherwise you wouldn't again have insulted the one who did
not share your opinion and that even without reason....calm down relax
and play nicely
Best regards,
Marcus
Hello,
On Thu, 20 Jul 2006 23:26:58 +0200
helly@php.net (Marcus Boerger) wrote:
I am but you obviously prefer to bring instable suff into core or what
now? Until now my idea of Zip was a stable idea so you could easily
have removed the tag file. The above said makes me thing that it is
far away from stable otherwise you wouldn't again have insulted the
one who did not share your opinion and that even without
reason....calm down relax and play nicely
I play nicely and I'm not calm. You are clearly turning this simple
question into a personal FUD. Like you did about the zip stream in
pecl list (yes, I give you another reason to shoot it down).
I will move to beta when we (the users and I) consider that the API
will not change. That means that one can use in production without the
risk to break everything on update.
About the stability of the code, I think this extension is way more
stable than its predecessor (which was in core) and as stable as many
recent additions (from pecl or not).
About adding experimental extension in ""core"", then please make a
proposal. It will make other people start to release beta/stable
package of untested code and without any users feedback about the API
(which always ends to BC breaks). I'm not sure I'm going to like that.
Cheers,
-- Pierre
Hello,
So I let Ilia decides whether it should be in or not.
So far the relevant arguments are only about "moving ext to pecl and
not the other way around", which is my opinion plain wrong (pdo, json,
filter, etc..). The class name argument is none the less a sweet
vengeance as its class name fits in our naming standards.
Cheers,
-- Pierre
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I
never saw a
php zip implementation named Zip.+1/-1/0?
I would've preferred an unified package for handling multiple archives
(zip/rar/tgz etc).
Similar to what PDO does for databases, if it is going into core.
Jared
I was thinking the same thing. We can of course clutter the namespace with a
class for every possible file extension we want to develop an API for, but
maybe we can do the smart thing and do what PDO does for databases: present
a unified API.
I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when they
all do the same. In the end people will start realizing the PDO-road
should've been taken from day one. I wish I had any experience with PECL to
work something out right now, but I don't. If anyone's interested, I'd be
willing to invest some time in constructing an API though (as a sort of
first step in a proof of concept).
- Ron
""Jared Williams"" jared.williams1@ntlworld.com schreef in bericht
news:20060721112422.JLUB11710.aamtaout03-winn.ispmail.ntl.com@win2ks...
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.I like to have it in, as experimental.
Please note that it intoduces a new class called Zip, but I
never saw a
php zip implementation named Zip.+1/-1/0?
I would've preferred an unified package for handling multiple archives
(zip/rar/tgz etc).
Similar to what PDO does for databases, if it is going into core.Jared
Hello,
I was thinking the same thing. We can of course clutter the namespace with a
class for every possible file extension we want to develop an API for, but
maybe we can do the smart thing and do what PDO does for databases: present
a unified API.
I was thinking the same as well. But I don't think it is a good idea.
For the simple operations, you can do it easily in php. I don't think
there is a need for an internal implementation of such wrappers.
I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when they
all do the same.
They don't always do the same, that's the problem. Also I'm a fan of
one need/one tool. PDO was needed because it is really a mess in the
DB APIs. I would prefer to define some common API and have independent
extensions. It will let us implement all format specific features or
needs (which can be speed, compression level, etc.).
Cheers,
--Pierre
A compression wrapper like PDO would be great. And they do all do the
same things more or less. Take data and compress it. Take compressed
data and uncompress it. Not that different.
Hello,
I was thinking the same thing. We can of course clutter the namespace with a
class for every possible file extension we want to develop an API for, but
maybe we can do the smart thing and do what PDO does for databases: present
a unified API.I was thinking the same as well. But I don't think it is a good idea.
For the simple operations, you can do it easily in php. I don't think
there is a need for an internal implementation of such wrappers.I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when they
all do the same.They don't always do the same, that's the problem. Also I'm a fan of
one need/one tool. PDO was needed because it is really a mess in the
DB APIs. I would prefer to define some common API and have independent
extensions. It will let us implement all format specific features or
needs (which can be speed, compression level, etc.).Cheers,
--Pierre--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
A compression wrapper like PDO would be great. And they do all do the
same things more or less. Take data and compress it. Take compressed
data and uncompress it. Not that different.
Then do it in PHP, it is very easy to create one for the simple
operations (which seems to be what you are looking for). And you can
start now or help the PEAR File_Archive maintainers to port their
packages to php5 (and use the native functions). I'm ready to help or
to modify the API as long as zip is not in the beta phase.
No other language has such wrappers implemented nativelly and for
those I use, I do not know any wrapper at all.
Cheers,
--Pierre
So where does this leave adding pecl/zip to 5.2? PDO is not core for
Windows so should zip?
A compression wrapper like PDO would be great. And they do all do the
same things more or less. Take data and compress it. Take compressed
data and uncompress it. Not that different.Then do it in PHP, it is very easy to create one for the simple
operations (which seems to be what you are looking for). And you can
start now or help the PEAR File_Archive maintainers to port their
packages to php5 (and use the native functions). I'm ready to help or
to modify the API as long as zip is not in the beta phase.No other language has such wrappers implemented nativelly and for
those I use, I do not know any wrapper at all.Cheers,
--Pierre
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Richard Quadling wrote:
So where does this leave adding pecl/zip to 5.2? PDO is not core for
Windows so should zip?
PDO is bundled in the core PHP distribution. Pierre was not asking for
Zip to be enabled by default, just to be a part of the distro.
Edin
Edin Kadribasic wrote:
Richard Quadling wrote:
So where does this leave adding pecl/zip to 5.2? PDO is not core for
Windows so should zip?PDO is bundled in the core PHP distribution. Pierre was not asking for
Zip to be enabled by default, just to be a part of the distro.
Yes, exactly.
As for the PDO for archive format argument:
The main reason for a base PDO extension was the idea of providing a
framework for database extensions. The question now is if such a thing
is necessary for archive formats? I think it would be sufficient to
ensure that there is a common API for all common aspects. Since we are
talking about OO here, all you need to do then is to use the constructor
of the given format and you are done. So note for example that while PDO
has a common constructor for all RDBMS it does not provide a common DSN
format either.
regards,
Lukas
So where does this leave adding pecl/zip to 5.2? PDO is not core for
Windows so should zip?
PDO is not core on windows? I do not understand what you say here.
--Pierre
I'm corrected by Edin. Misunderstood.
So, why are some extensions bundled and not others? Surely all
successfully built, non experimental extensions should be part of the
distro?
So where does this leave adding pecl/zip to 5.2? PDO is not core for
Windows so should zip?PDO is not core on windows? I do not understand what you say here.
--Pierre
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Well, if they all implement some common interface, that would really be an
improvement too. And I guess in that case there'd be GZipArchive,
ZipArchive, RarArchive, ... classes.
People have a choice then; use the specific format of their choice and have
all the extras it comes with, or go for a universal approach and use the
common API as defined in the interface.
Still, I think options like speed/compression factor is applicable to all or
most archive formats. I don't see much feature difference among formats,
only in the libraries they offer perhaps (honestly, I wouldn't really know).
The only difference I can think of is that gzip doesn't seem to provide a
means for compression multiple files (without resorting to tar, but TGZ
support could of course be developed).
- Ron
"Pierre" pierre.php@gmail.com schreef in bericht
news:fe05d1540607210500g734d1343rb881ba11ea93bba9@mail.gmail.com...
Hello,
I was thinking the same thing. We can of course clutter the namespace
with a
class for every possible file extension we want to develop an API for,
but
maybe we can do the smart thing and do what PDO does for databases:
present
a unified API.I was thinking the same as well. But I don't think it is a good idea.
For the simple operations, you can do it easily in php. I don't think
there is a need for an internal implementation of such wrappers.I don't like the idea of having GZip, Zip, Rar, Arj, Etc classes when
they
all do the same.They don't always do the same, that's the problem. Also I'm a fan of
one need/one tool. PDO was needed because it is really a mess in the
DB APIs. I would prefer to define some common API and have independent
extensions. It will let us implement all format specific features or
needs (which can be speed, compression level, etc.).Cheers,
--Pierre
Well, if they all implement some common interface, that would really be an
improvement too. And I guess in that case there'd be GZipArchive,
ZipArchive, RarArchive, ... classes.People have a choice then; use the specific format of their choice and have
all the extras it comes with, or go for a universal approach and use the
common API as defined in the interface.
Yes, that's why I like to stay in alpha until we are sure about the basic API.
Still, I think options like speed/compression factor is applicable to all or
most archive formats. I don't see much feature difference among formats,
only in the libraries they offer perhaps (honestly, I wouldn't really know).
The only difference I can think of is that gzip doesn't seem to provide a
means for compression multiple files (without resorting to tar, but TGZ
support could of course be developed).
I have read and checked many archives format. That's why I prefer
specific extensions with a common API naming for all simple
operations. More than that, like a general archive wrapper should be
done in userland, it is much more flexible and easier to change.
--Pierre