headers
Adam Ashley | 16 Jul 2007 02:40

Re: PEAR2 standards: anything good at all?

On Mon, 16 Jul 2007 01:55:22 +0400, Alexey Borzov <borz_off <at> cs.msu.su> wrote:

> Hi,
>
> After re-reading the "PEAR2 standards", "PEAR2 require" wiki pages and
> (most of) discussion on pear-dev, I'm beginning to think that these
> so-called standards should be ditched in their entirety.

I have to disagree with you. I'll give you your point about  
unzip-and-go, never made sense to me either but thats it.

> Now another "problem" is that PEAR installation is not relocatable.
> Since we already covered unzip-and go, let's presume that we are
> talking a real installation here. The proposed solution is to have a
> data_dir.txt file in the installation root that'll contain the name of
> data directory. Nice.
>
> But if I relocate the installation, will the file automagically contain
> the name of the dir I relocated to? No? So, is there a huge difference
> between editing this file by hand and doing a mass search-and replace
> that's required now?

The huge difference is that if you don't understand the serialization  
format used by PHP when you do that search and replace you will stuff  
up your pear config.

> require_once controversy was already covered a lot here, my opinion is:
>  * slow require_once in APC is a problem of APC, not PEAR. APC
> developers are aware of it and are solving it, so sometime our
> optimizations may become counter-productive.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Elizabeth Smith | 16 Jul 2007 03:01
Gravatar

Re: PEAR2 standards: anything good at all?


> It is claimed that unzip-and-go is a good thing. But let's think aloud: 
> who is the target audience for unzip-and-go? I suppose these are the people
>  * unable to use PEAR installer (those who don't *want* to set up a PEAR 
> installer on the server may use its remote installation capabilities)
>  * unable to set up their include_path (which is a pretty standard task 
> among programming languages)

Actually it has a lot more to do with bundling PEAR packages inside 
larger applications than anything else.

Yes I could make my app install PEAR (remotely or not - which means 
sending all the files needed for that with the app - overkill for a 
small PEAR package) or upgrade/downgrade current packages to match the 
version(s) my app expects or install a local PEAR (which doesn't work 
right on windows yet, BTW) and pray the user never does anything with 
his own PEAR install or include_path or creates their own module using 
other PEAR stuff that mucks up the include path or otherwise messes with 
my or their own PEAR install.  Or I could move to using the pear 
installer to distribute my app when my users are use to unzip and run 
(not likely)...

But it's a heck of a lot easier to just grab the package I want in my 
app, unzip it and include it, pack it in my release, and go.

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Weiske | 16 Jul 2007 08:04
Picon
Favicon
Gravatar

Re: PEAR2 standards: anything good at all?

Alexey,

> Now another "problem" is that PEAR installation is not relocatable.
> Since we already covered unzip-and go, let's presume that we are
> talking a real installation here. The proposed solution is to have a
> data_dir.txt file in the installation root that'll contain the name
> of data directory. Nice.
> 
> But if I relocate the installation, will the file automagically
> contain the name of the dir I relocated to? No? So, is there a huge
> difference between editing this file by hand and doing a mass
> search-and replace that's required now?

You misunderstood the concept of the new data_dir:
There is not a single file containing its name. It is assumed by the
packages that you can reach it via dirname^x(__FILE__) calls directly
above the current root php files location.
Currently, you can set php files path to /usr/share/pear/php/ and
data_dir to /home/tmp/some/weird/setting/ and thus need PEAR_Config to
retrieve data_dir.
In PEAR2, it is proposed that php and data_dir are children of the same
directory, tied together, making it unneccessary to use PEAR_Config at
all.
If you care about not having another PEAR_Error, you probably want to
get rid of PEAR_Config for standard tasks, too.

--

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lukas Kahwe Smith | 16 Jul 2007 08:52

Re: PEAR2 standards: anything good at all?

Alexey Borzov wrote:

> require_once controversy was already covered a lot here, my opinion is:
>  * slow require_once in APC is a problem of APC, not PEAR. APC 
> developers are aware of it and are solving it, so sometime our 
> optimizations may become counter-productive.
>  * require_once is faster without APC. If we're targeting PHP6 which 
> will (supposedly) have APC built in, why aren't we using namespaces, 
> too, going instead for PEAR2_Obnoxiously_Long_Class_Names?

only if you do not load unnecessary code, which you are likely to do. or 
otherwise you end up combining a require_once with every new. take for 
example the various exception classes etc.

>  * Anyone else smelling a reincarnation of PEAR_Error here?

No, I smell added flexibility at the expense of "forcing" users to add 
an ultra simple __autoload() (or spl variant thereof) that simply does 
your beloved require_once.

regards,
Lukas

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 13 comments |
headers
Alexey Borzov | 16 Jul 2007 08:53
Picon
Favicon

Re: PEAR2 standards: anything good at all?

Hi,

Christian Weiske wrote:
>> Now another "problem" is that PEAR installation is not relocatable.
>> Since we already covered unzip-and go, let's presume that we are
>> talking a real installation here. The proposed solution is to have a
>> data_dir.txt file in the installation root that'll contain the name
>> of data directory. Nice.
>>
>> But if I relocate the installation, will the file automagically
>> contain the name of the dir I relocated to? No? So, is there a huge
>> difference between editing this file by hand and doing a mass
>> search-and replace that's required now?
> 
> You misunderstood the concept of the new data_dir:
> There is not a single file containing its name. 

Excuse me? Right in "PEAR2 standards" [1] page, under "Data files": "package.xml 
replacement tasks should not be used to retrieve path locations, instead use the 
<role>.txt file located in php_dir, so if you need a data file, you do this:" 
and then goes the example with data_dir.txt.

> It is assumed by the
> packages that you can reach it via dirname^x(__FILE__) calls directly
> above the current root php files location.
> Currently, you can set php files path to /usr/share/pear/php/ and
> data_dir to /home/tmp/some/weird/setting/ and thus need PEAR_Config to
> retrieve data_dir.

So you want to reduce the flexibility of PEAR to set such directories? What
(Continue reading)

Permalink | Reply | 1 comment |
headers
Lukas Kahwe Smith | 16 Jul 2007 08:55

Re: PEAR2 standards: anything good at all?

Alexey Borzov wrote:

> I don't have a problem with PEAR_Config (other than it can be made a wee 
> bit more lightweight), PEAR_Error, on the other hand, is a convoluted 
> and error-prone way of doing common task.

I think PEAR_Error was the best error handling mechanism in PHP4 and 
still has some clear advantages over Exceptions in PHP5. At any rate, 
you are trying to adapt Godwin's law here to PEAR_Error. The two topics 
have nothing in common.

regards,
Lukas

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Alexey Borzov | 16 Jul 2007 09:35
Picon
Favicon

Re: Re: PEAR2 standards: anything good at all?

Hi,

Elizabeth Smith wrote:
>> It is claimed that unzip-and-go is a good thing. But let's think 
>> aloud: who is the target audience for unzip-and-go? I suppose these 
>> are the people
>>  * unable to use PEAR installer (those who don't *want* to set up a 
>> PEAR installer on the server may use its remote installation 
>> capabilities)
>>  * unable to set up their include_path (which is a pretty standard 
>> task among programming languages)
> 
> Actually it has a lot more to do with bundling PEAR packages inside 
> larger applications than anything else.
> 
> Yes I could make my app install PEAR (remotely or not - which means 
> sending all the files needed for that with the app - overkill for a 
> small PEAR package) or upgrade/downgrade current packages to match the 
> version(s) my app expects or install a local PEAR (which doesn't work 
> right on windows yet, BTW) and pray the user never does anything with 
> his own PEAR install or include_path or creates their own module using 
> other PEAR stuff that mucks up the include path or otherwise messes with 
> my or their own PEAR install.  Or I could move to using the pear 
> installer to distribute my app when my users are use to unzip and run 
> (not likely)...
> 
> But it's a heck of a lot easier to just grab the package I want in my 
> app, unzip it and include it, pack it in my release, and go.

First of all, many applications right now are bundling PEAR packages, so that is
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pádraic Brady | 16 Jul 2007 09:40
Picon
Favicon
Gravatar

Re: can i rely on ctype?

Hi,

Deprecating ctype makes a lot of sense. I have a lot of code using PCRE with "/^\d*$/" to avoid the casting
errors. It's also of limited utility in a multi-lingual setting - even though it is Locale aware.

Having a unicode friendly char_is_* makes a huge amount of sense. Anyway, ctype doesn't like my name ;) on
most English sites if its used.

Paddy

Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com

----- Original Message ----
From: Stefan Walk <stefan.walk <at> gmail.com>
To: Alexey Borzov <borz_off <at> cs.msu.su>
Cc: Lukas Kahwe Smith <mls <at> pooteeweet.org>; Christian Weiske <cweiske <at> cweiske.de>; pear-dev <at> lists.php.net
Sent: Sunday, July 15, 2007 10:36:45 PM
Subject: Re: [PEAR-DEV] can i rely on ctype?

On 15/07/07, Alexey Borzov <borz_off <at> cs.msu.su> wrote:
> That's a bit strange, since deprecating the extension that is currently enabled
> by default is a pretty major change. I think getting the relevant info out of
> Marcus and / or Andrei is in order...

A pretty major change that makes perfect sense. When PHP6 is there,
there are char_is_*-functions using ICU (the unicode library). Those
functions do everything that ctype does in a more coherent way,
example:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lukas Kahwe Smith | 16 Jul 2007 09:41

Re: Re: PEAR2 standards: anything good at all?

Alexey Borzov wrote:
> Hi,
> 
> Elizabeth Smith wrote:
>>> It is claimed that unzip-and-go is a good thing. But let's think 
>>> aloud: who is the target audience for unzip-and-go? I suppose these 
>>> are the people
>>>  * unable to use PEAR installer (those who don't *want* to set up a 
>>> PEAR installer on the server may use its remote installation 
>>> capabilities)
>>>  * unable to set up their include_path (which is a pretty standard 
>>> task among programming languages)
>>
>> Actually it has a lot more to do with bundling PEAR packages inside 
>> larger applications than anything else.
>>
>> Yes I could make my app install PEAR (remotely or not - which means 
>> sending all the files needed for that with the app - overkill for a 
>> small PEAR package) or upgrade/downgrade current packages to match the 
>> version(s) my app expects or install a local PEAR (which doesn't work 
>> right on windows yet, BTW) and pray the user never does anything with 
>> his own PEAR install or include_path or creates their own module using 
>> other PEAR stuff that mucks up the include path or otherwise messes 
>> with my or their own PEAR install.  Or I could move to using the pear 
>> installer to distribute my app when my users are use to unzip and run 
>> (not likely)...
>>
>> But it's a heck of a lot easier to just grab the package I want in my 
>> app, unzip it and include it, pack it in my release, and go.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexey Borzov | 16 Jul 2007 10:25
Picon
Favicon

Re: PEAR2 standards: anything good at all?

Adam Ashley wrote:
>> Now another "problem" is that PEAR installation is not relocatable.
>> Since we already covered unzip-and go, let's presume that we are
>> talking a real installation here. The proposed solution is to have a
>> data_dir.txt file in the installation root that'll contain the name of
>> data directory. Nice.
>>
>> But if I relocate the installation, will the file automagically contain
>> the name of the dir I relocated to? No? So, is there a huge difference
>> between editing this file by hand and doing a mass search-and replace
>> that's required now?
> 
> The huge difference is that if you don't understand the serialization 
> format used by PHP when you do that search and replace you will stuff up 
> your pear config.

Good point.

Well, another question is whether installation relocation is such a common task. 
And why most package managers do not support it, then.

>> require_once controversy was already covered a lot here, my opinion is:
>>  * slow require_once in APC is a problem of APC, not PEAR. APC
>> developers are aware of it and are solving it, so sometime our
>> optimizations may become counter-productive.
>>  * require_once is faster without APC. If we're targeting PHP6 which
>> will (supposedly) have APC built in, why aren't we using namespaces,
>> too, going instead for PEAR2_Obnoxiously_Long_Class_Names?
>>  * Anyone else smelling a reincarnation of PEAR_Error here?
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane