[PHP] When to use namespaces
Hi everyone, I'm doing a small hobby project to better my understanding of php5, specifically php5.3 and I'm wondering when a namespaced project is better and when it is better to simply use a prefix to all class names. I've been trying to get a feeling for what is considered the best practice, but most of the pages dealing with namespaces start with the assumption that you are building a complex application with lots of modules and say things like: Namespaces should be all lowercase and must follow the following conention: \\ (thats from the php.standards mailing list btw) In my case the project is a single module, single php file, with about 6 classes. It is an OO wrapper for PHP's xmlrpc methods (client and server) and meant to be used in a number of different projects. Is it considered a good idea to use a namespace in such a case? And if so, what should that be? I've named the project 'ripcord', and used that as a namespace as well. I could probably name it 'muze.ripcord', but somehow that feels less 'open' to me. Thanks in advance for any thoughts, Auke van Slooten Muze (www.muze.nl) PS. The project is at http://code.google.com/p/ripcord/, the PHP5.3 version is at http://code.google.com/p/ripcord/source/browse/#svn/branches/php5.3 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] best way to determine (MIME) content type of a stream ofbytes?
Robert P. J. Day wrote: On Mon, 8 Mar 2010, Ashley Sheridan wrote: What about writing the first n bytes to a file and then passing that to the command line? I'm assuming a Linux server here, but it should do the trick. gah! i was hoping for something that wouldn't make me want to gouge out my eyes with a soup spoon. :-) Maybe slightly less painfull, you can always write your own 'mimemagic' detection method. The magic.mime file is relatively easy to parse. This is the route we took some years ago to make our mime detection OS independant. We've made a php script which parses the mime.types file and the magic.mime file and it generates a php module which uses that information to figure out the correct mimetype. The resulting php module has a large array, which looks like this: ... $mimemagic_data[0][4]["\0\0\1\273"]="video/mpeg"; $mimemagic_data[0][4]["\0\0\2\0"]="application/x-123"; $mimemagic_data[0][4]["\0\0\32\0"]="application/x-123"; $mimemagic_data[0][4]["\0\6\25\141"]="application/x-dbm"; $mimemagic_data[0][4]["\101\104\111\106"]="audio/X-HX-AAC-ADIF"; $mimemagic_data[0][4]["\103\120\103\262"]="image/x-cpi"; ... with the first key as the offset to start, the next key is the length of the snippet to check (I guess that could have been skipped...) and the final key is the exact string to match. The magic.mime file is no magic bullet though, there are occasions when it won't match with a file, but that's usually with more complex types like microsoft office documents, not with images. If you're interested, the mimemagic module can be found here: http://svn.muze.nl/trunk/lib/modules/mod_mimemagic.php?revision=4299&root=ariadne-php5 And the builder script (which you should run on a unix system with magic.mime and mime.types file) is here: http://svn.muze.nl/trunk/bin/utils/build_mimemagic_script.php?revision=4299&root=ariadne-php5 Hope this helps, Auke van Slooten Muze -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Execution order of PHP
Hi, In a hobby project I'm relying on the order in which the following piece of PHP code is executed: $client->system->multiCall( $client->methodOne(), $client->methodTwo() ); Currently PHP always resolves $client->system (and executes the __get on $client) before resolving the arguments to the multiCall() method call. Is this order something that is specified by PHP and so can be relied upon to stay the same in the future or is it just how it currently works. If it cannot be relied upon to stay this way, I will have to rewrite the multiCall method and API... regards, Auke van Slooten Muze -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Execution order of PHP
Bruno Fajardo wrote: 2010/3/10 Auke van Slooten Hi, In a hobby project I'm relying on the order in which the following piece of PHP code is executed: $client->system->multiCall( $client->methodOne(), $client->methodTwo() ); Can't you call the methods $client->methodOne() and $client->methodTwo() before the call to $client->system->multiCall()? That way, you could store they values in local variables, and then pass them to the $client->system->multiCall(), assuring that those methods are executed before the multiCall(). Something like: $methodOne = $client->methodOne(); $methodTwo = $client->methodTwo(); $client->system->multiCall($methodOne, $methodTwo); Hi, This is not what I meant. I should perhaps mention that it's an xml-rpc client and the method calls are remote method calls. The multiCall method gathers multiple method calls into a single request. The trick I'm using now is to set a private property in the $client->__get() method when the property you're accessing is 'system'. From then untill you call the method 'multiCall', instead of calling the methods (in this case methodOne and methodTwo) the client creates a new object with the call information (method name and arguments) and returns that. In multiCall all arguments are therefor call information objects and multicall creates a single request based on that information. So in your example the client would simply call methodOne and methodTwo and return the results. Then it would try to do a multiCall with whatever the previous methods have returned. regards, Auke van Slooten Muze -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Execution order of PHP
Bob McConnell wrote: From: Auke van Slooten In a hobby project I'm relying on the order in which the following piece of PHP code is executed: $client->system->multiCall( $client->methodOne(), $client->methodTwo() ); Think about it from the parser's point of view. It has to evaluate $client->system to determine the parameter list for multiCall(). Then it has to evaluate those parameters before it can stuff their values into the stack so it can call the function. But, whether it evaluates the parameter list left-to-right or vice versa is implementation dependent. I don't believe you can rely on it always being the same unless you always use the same interpreter. I don't mind about the order in which the parameters are evaluated. The only thing that must stay the same for my code to work as designed is that $client->system is evaluated before any of the arguments to the multiCall method. Your explanation seems reasonable to me, but I've been informed by people that know more about parsers and compilers than me, that theoretically there is no requirement for this to be true... After a further education just now, it is possible for a compiler to parse the entire multiCall right to left, so it will first evaluate $client->methodTwo(), then $client->methodOne() and only then resolves $client->system->multiCall. Before evaluating this call, the compiler can still check whether the number of arguments matches the parameter list of the function definition. Anyway, the point is that I'd like to be able to write multiCall statements like written above instead of doing something like this: $client->system->multiCall( array( 'method' => 'methodOne', 'params' => array() ), array( 'method' => 'methodTwo', 'params' => array() ) ); regards, Auke van Slooten Muze -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Execution order of PHP
Andrew Ballard wrote: I'm not sure you would want to assign null to $client->system. After all, __set() might not be defined. I agree with Rob here. If order is really crucial, then call the statements in the correct order: system; /** * You should add some handling here to make sure that * $system is really an object that implements your * multiCall() method, and not something else (like null). */ $system->multiCall( $client->methodOne(), $client->methodTwo() ); ?> I agree with both of you. If you want it ironclad and you cannot change the API, then this is how I would do it. The point is that I _can_ change the API, but I like how simple it looks. The backup plan is to do something like: $client->system->multiCall( $client->__defer()->methodOne(), $client->__defer()->methodTwo() ); The only problem with this is that I'm polluting the $client 'namespace' with a __defer method. And it looks less clean... :) Now if the consensus is that you absolutely cannot rely on the execution order in this case (not for the order in which function parameters are evaluated, I don't care about that) then I will just change my API and remember with fondness what I could not have... regards, Auke van Slooten Muze -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Execution order of PHP
Jochem Maas wrote:
Op 3/10/10 1:29 PM, Auke van Slooten schreef:
Hi,
In a hobby project I'm relying on the order in which the following piece
of PHP code is executed:
$client->system->multiCall(
$client->methodOne(),
$client->methodTwo()
);
but who cares. the code is full of magic, which makes it difficult to understand
and maintain ... fix it so that it's explicit about what it's doing so that
other developers who read it will grasp the concept without having to dig
into your magic methods. this solves the problem of undiscernable magic and
possible issues with resolution order in the future as well (which if they
happened would be a royal PITA to debug, given the magic methods involved)
I've decided to rewrite the API so it is more upfront about what it
does. Your argument about readability, when the API is unknown, is a
valid one. It now works like this:
$client->system->multiCall(
ripcord::encodeCall('methodOne'),
ripcord::encodeCall('methodTwo')
);
Thanks for all your input,
Auke van Slooten
Muze
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] web sniffer
Jochen Schultz wrote: Btw., when you use file_get_contets, is there a good way to tell the script to stop recieving the file after let's say 2 seconds - just in case the server is not reachable - to avoid using fsockopen? http://nl.php.net/manual/en/context.http.php specifically: timeout float Read timeout in seconds, specified by a float (e.g. 10.5). By default the default_socket_timeout php.ini setting is used. used with http://nl.php.net/manual/en/function.stream-context-create.php regards, Auke van Slooten Muze -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP SMTP Mailers
King Coffee wrote: Hi, I'm executing a third-parity standard PHP application on a Windows IIS 7 shared hosting server. I need to convert, or use, a SMTP mailer service. I found two SMTP PHP scripts - I think may work. The sourceforge.net PHPMailer project and the pear.php.net (Mail, Net_SMTP) project. Can any body please help me choose one and probably give a code snip of useage? Currently, I'm leaning forward the PHPMailer, with little to base the decision on. Hi, I'd take a look at http://www.phpguru.org/static/smtp.html It doesn't make the mistake of muddling the differnece between the message envelope and the message body, so you can set the recipients directly and different from the messages to/cc/bcc headers. It has a fairly sane design, based on the smtp protocol. And finally it uses exceptions in a sane way. Oh, and its a fairly small and straightforward piece of code, easy to include in any application. There's one problem in it when using it for bulk-mail. If you add many recipients and one of them is incorrect, it will fail the entire message. It's not free for commercial use, but the one-time license fee is more than worth it. regards, Auke van Slooten Muze (And no, I'm not affiliated with the author, just a happy customer). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
