Re: [PHP-DEV] phar API

[Benjamin Schulz]

Hi Marcus,

First thing: yes i fully understand what the code is doing but i  
still
think that it doesn't need to be so "hackish".

I wouldn't call it hackish. I'd eventually call it new to people that
haven't used the new PHP 5.0 features yet.

I used PHP 5 when it had namespaces the first time ;) So i am not new  
to PHP5
features, that's not the point.


One thing is that i think there is no point in using ArrayAccess  
here,
in my oppinion ArrayAccess is great to hack stuff but it doesn't
belong in such (maybe soon?) core functionality.

So you are basically saying we should remove ArrayAccess, right?

In my personal oppinion: yes. There is no need for array syntax if you  
provide
a OO api, why not setContent() or something else? There is no real  
difference
in the implementation, right?


The second thing that looks weird to me is that the setter  
(offsetSet)
sets the file content but the getter (offsetGet) retrieves a file
object.

Right now the setter takes a resource or a string. Maybe we can  
allow an
SplFileInfo instance too. But note that this is even more wierd as  
we then
would need to convert this instance into another instance and still  
only
transfer the contents.

The point is that the getter does something completely different from  
the
setter. The getter returns a file object but the setter sets the content
of the file, this is just not consistent.



What about changing this into something more OO like this (just a
proposal):

$p = new Phar('coollibrary.phar');

/* What about creating a non-static pendant to canWrite()?
   Maybe there is an archive file that has only read permissions on
the filesystem or
   phar will be able to generate readonly-archives later? (Might be
interesting for
   companies that want to provide readonly and signed archives for
the customers)

We can already create readonly archives.

And how do i check if the archive is readonly? canWrite() just tells me
if the php.ini setting is enabled, right?

And obviously you cannot create
signed archives where only selected entries are readonly.

I don't see where this has to do with the point of my mail but i think
it could easily achieved with
$p->getFile('data/hugefile.dat')->canWrite()



if ($p->canWrite()) {
    // Create a file instance
    $hugeFile = $p->createFile();

    $fp = fopen('hugefile.dat', 'rb');

    // Set the content
    $hugeFile->setContent($fp); (or maybe even
setContentResourceHandle(...))
    if (Phar::canCompress()) {
        /* how is the compression implemented? through streamfilters?
           than how about a ->setCompression('bzip')
          that internally resolves to the bzip.(de)compress:// stuff?
        $p['data/hugefile.dat']->setCompressedGZ();
    }

Hi? This makes no sense whatsover. Because:
Ther is no connection between your stuff.
- $hugeFile would be an anonymous entry in your file

correct, it would be just some "random" file object related to the phar
archive until i use addFile() like below, if you need this relation one
could provide something like
$p->createFile('data/hugefile.dat');
$p->setContent('...');

- and then wher is $p['data/hugefile.dat'] coming from?
- and did you not just write ArrayAccess is wrong?

sorry, my fault - it should be $hugeFile

    // add the file to the archive
    $p->addFile($hugeFile, 'data/hugefile.dat');

Well I prefer the other order. Oh and then that is just what
$p->offsetSet('data/hugefile.dat', $fp); does already.

Do you think that is well named? It's what the ArrayAccess interface
prescribes but wouldn't a $p->setFile(), ->addFile() describe better
what's happening? I mean we're talking about OO here.


    // another option would be to pass the file path to the
createFile() method and
    // implicitely create it in the archive
    $indexPhp = $p->createFile('index.php');
    $indexPhp->setContent(...);

Well right now, you'd do $indexPhp = $p['index.php']; $indexPhp->...

Yep, array syntax? but it's an object right? That is what i mean with  
"hackish" - no
need for array syntax if i work with objects. I still believe that  
ArrayAccess has
it's advantages but IMHO not in this case.

regards,
Benjamin

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php