Re: [PHP] Class and interface location
On 19 January 2011 07:46, Adam Richardson wrote: > On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield wrote: > >> 3) Static analysis. Instead of reflection, either tokenize or string parse >> all files to determine what classes implement what interfaces and then >> cache >> that information. We are actually using this method now to locate classes, >> and it works surprisingly well. Because we never parse code into memory it >> does not ever spike the memory usage. However, it is impossible to >> determine >> if a class implements a given interface by static analysis unless it >> declare >> so itself with the implements keyword. If it does so indirectly via >> inheritance, either via the class or via the interface, it would not find >> it. >> That necessitates that any "detectable" classes must explicitly themselves >> declare their interfaces, even if it is redundant to do so. I don't like >> that >> approach, but it's the first one that strikes me as even viable. >> > > 4) Explicit declaration. In this approach we detect nothing and rely on the >> plugin developer to do everything. That is, they must provide somewhere >> (either in code or a configuration file) an index of all classes they >> offer, >> the interfaces they implement, and the file in which they live. While this >> makes the implementation easy, it is a huge burden on the plugin developer >> and >> I'm quite sure they'll forget to do so or get it wrong on a regular basis. >> > > I'd suggest combining 3 and 4. Build a tool that performs a static analysis > of a group of files and make it easy for developers to use. This tool would > generate the explicit declarations your codebase would utilize when > answering such questions as "which classes implement interface foo". The > file the static analysis tool generates could be easily hand editable, so > developers could tweak it if they see issues (just in case the static > analysis tool has bugs early on), or for small plugins, just quick crank out > a couple lines by hand. > > As long as the static analysis tool builds a composite of class hierarchy > established in all the files (project wide, at least in terms of the > plugin), you wouldn't have to double declare interfaces so they could be > detected. > > Adam > > -- > Nephtali: A simple, flexible, fast, and security-focused PHP framework > http://nephtaliproject.com > There is a pecl extension called inclued [1] & [2] which could be used I think. It can be used to produce a list of all the relationships between included files, so a one off pass of all the class files (simply include them) and then retrieve the analysis from inclued. You can now build a class dependency tree from that data and cache it. Pretty much exactly what you need. Richard. [1] http://pecl.php.net/package/inclued [2] http://docs.php.net/manual/en/book.inclued.php -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On Wed, 2011-01-19 at 01:07 -0600, Larry Garfield wrote: > Hi all. I'm trying to come up with a solution to an architectural problem I > could use some extra eyes on. > > I have (or will have) a large code base with lots of classes, spread out over > many optional plugin components. These classes, of course, will have > interfaces on them. These classes will, of course, lazy-load using PHP's > autoload capability. > > What I need to know is which classes implement which interfaces, so that I > can > load and use "all classes that implement interface Foo". > > There are a couple of approaches that I've considered, all of which I dislike > for one reason or another. > > 1) Magic file naming. That is, any class that implements interface Foo lives > in a $something.Foo.inc file, or some similar pattern. This has a number of > problems. First, it means a huge number of file_exists() calls to determine > if a given potential class exists, and then disk hits to load those files. > While that information is possible to cache, it also means that we cannot > have > a class that implements two of the interfaces I'm interested in (a feature I > will need) because then it would have to live in two files, which is clearly > impossible. > > 2) Reflection. PHP makes it quite easy to get a list of all loaded classes, > and to get a list of all interfaces that a loaded class implements. The > catch > there is "loaded". Reflection only works once you've loaded the code file > into memory. Once you've done so, you cannot unload it. That means the code > is sitting there in memory wasting space. Given the size of the code base in > question, that could easily blow out the process memory limit. Even if we > cache that information we derive from reflection we still have to load it the > first time (or periodically when rebuilding the cache), which will blow the > memory limit. The only alternative would be to have some sort of incremental > rebuild across a multi-request batch process, the complexity of which makes > my > skin crawl. > > 3) Static analysis. Instead of reflection, either tokenize or string parse > all files to determine what classes implement what interfaces and then cache > that information. We are actually using this method now to locate classes, > and it works surprisingly well. Because we never parse code into memory it > does not ever spike the memory usage. However, it is impossible to determine > if a class implements a given interface by static analysis unless it declare > so itself with the implements keyword. If it does so indirectly via > inheritance, either via the class or via the interface, it would not find it. > > That necessitates that any "detectable" classes must explicitly themselves > declare their interfaces, even if it is redundant to do so. I don't like > that > approach, but it's the first one that strikes me as even viable. > > 4) Explicit declaration. In this approach we detect nothing and rely on the > plugin developer to do everything. That is, they must provide somewhere > (either in code or a configuration file) an index of all classes they offer, > the interfaces they implement, and the file in which they live. While this > makes the implementation easy, it is a huge burden on the plugin developer > and > I'm quite sure they'll forget to do so or get it wrong on a regular basis. > > 5) Wave a wand and let the magic ponies figure it out. I wish. :-) > > Can anyone suggest a better alternative? At the moment option 3 seems like > the most viable approach, but I'm not wild about the implied performance > impact nor the potentially redundant interface definitions it would require. > > --Larry Garfield > My suggestion, would be for #5. The magic ponies do wonderful work. :) Steve (TheStapler) Staples. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Autorename extracted files from zip-archive
Hello,
I am using shell_exec to uncompress zip files which works fine, but has
one big problem. Whenever the zip-archive containes an already existing
file name, it will overwrite the current one. I need the file to be
extracted and autorenamed.
This is the code line:
$output = shell_exec('unzip -jo '.$filename.' -d '.$path);
Does anybody know a way on how to autorename existing files?
I thought about a workaround on extracting to a tmp folder and then
moving to the proper directory while renaming the files if they already
exists. Unfortunatelly I could not find a way to do this.
Thank you for any help on this.
Merlin
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case madness
On Jan 18, 2011, at 11:53 PM, Donovan Brooke wrote: > The idea of using existing resources for efficiency is very valid indeed.. > especially with a job at hand. But, there are good reasons to > roll-your-own... education and knowing your own code are 2 that are important > to me right now. Besides, a cookie based log-in system is really not that > complex. ;-) > > Now.. payment gateway API? AJAX requests? I'll take the snippets please. > > Cheers, > Donovan (moving on to database administration) Payment gateways suck. AJAX requests are easy if you roll JavaScript well and have a decent inspector (Firebug). I agree, a simple login is not that complex. I thought it was a bit more involved then that. Regards, -Josh Joshua Kehn | josh.k...@gmail.com http://joshuakehn.com
RE: [PHP] switch case madness
[snip] ... [/snip] Imagine when there'll be the day when you do not have to code at all...just copy 'n paste snippets together in the order that you wish them to work in and Voila'! - instant web app. Th!! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case madness
On Jan 19, 2011, at 9:43 AM, Jay Blanchard wrote: > [snip] > ... > [/snip] > > Imagine when there'll be the day when you do not have to code at > all...just copy 'n paste snippets together in the order that you wish > them to work in and Voila'! - instant web app. > > > Th!! > They have that. It's called Ruby on Rails. Regards, -Josh Joshua Kehn | josh.k...@gmail.com http://joshuakehn.com
Re: [PHP] switch case madness
> Imagine when there'll be the day when you do not have to code at > all...just copy 'n paste snippets together in the order that you wish > them to work in and Voila'! - instant web app. I have a Wordpress plugin that will do all of that for you. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Autorename extracted files from zip-archive
On Wed, Jan 19, 2011 at 09:06, Merlin Morgenstern wrote:
> Hello,
>
> I am using shell_exec to uncompress zip files which works fine, but has one
> big problem. Whenever the zip-archive containes an already existing file
> name, it will overwrite the current one. I need the file to be extracted and
> autorenamed.
>
> This is the code line:
>
> $output = shell_exec('unzip -jo '.$filename.' -d '.$path);
>
> Does anybody know a way on how to autorename existing files?
Just because you're using PHP as a frontend doesn't mean this is a
PHP question. This is a Linux administration question, and one that
Google can handle.
> I thought about a workaround on extracting to a tmp folder and then moving
> to the proper directory while renaming the files if they already exists.
> Unfortunatelly I could not find a way to do this.
Probably because you haven't written it yet. When you think about
how to achieve this, it's really simple:
1.) Create a temporary directory (e.g. -
mkdir(dirname(__FILE__).'/tmp'.time()) for a unique name).
2.) Extract the files to that directory.
3.) Check the target directory for existing files.
4.) Handle things as appropriate.
There are even simpler ways, again available by searching Google,
you may just need to adjust your search terms and try again.
--
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Autorename extracted files from zip-archive
> -Original Message-
> From: Merlin Morgenstern [mailto:merli...@fastmail.fm]
> Sent: Wednesday, January 19, 2011 6:06 AM
> To: php-general@lists.php.net
> Subject: [PHP] Autorename extracted files from zip-archive
>
> Hello,
>
> I am using shell_exec to uncompress zip files which works fine, but has
one
> big problem. Whenever the zip-archive containes an already existing file
> name, it will overwrite the current one. I need the file to be extracted
and
> autorenamed.
>
> This is the code line:
>
> $output = shell_exec('unzip -jo '.$filename.' -d '.$path);
>
> Does anybody know a way on how to autorename existing files?
>
> I thought about a workaround on extracting to a tmp folder and then moving
> to the proper directory while renaming the files if they already exists.
> Unfortunatelly I could not find a way to do this.
>
> Thank you for any help on this.
>
> Merlin
>
Merlin,
It's a shame that unzip doesn't have that feature like unrar. However, I
suggest you extract the contents of the zip files into a temp working
directory. Scan the files within that directory for any compressed archives
and extract each into their own subdirectory matching the filename. And
just recurse until no more compressed archives. Then process whatever files
you need. When done, just rm -fd (my unix/linux is limited.
Don't recall the parameters). That way, clean up is a synch and you still
have the original file when there's something wrong during processing stages
like mismatch columns, duplicate entries, etc.
Regards,
Tommy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case madness
On Tue, Jan 18, 2011 at 23:39, Joshua Kehn wrote: > > Why not use one of the countless, not to mention secure and stable cookie > management systems available? If it's an exercise cool, I misunderstood. > > I'm not one to normally shun people rolling their own code, lord knows I've > done it more then once or twice, but there are some things I wouldn't touch > with a ten foot pool, and cookie management is one of them. The other would > be things like CSV parsers or text manipulations. The use of existing packages is so increasingly prevalent that I have the unfortunate displeasure of knowing many "developers" who do nothing but this, yet who can't even answer simple questions about general coding, and who cry and complain that a "previous developer" must have borked something. I think Donovan is right on track here --- he's just getting started, and challenging himself to learn the language at a deeper level. That will make him a developer, not just a copy-and-paster. I do see from where it is you're coming, though, Josh --- once you've gotten the fundamentals, a lot of times it's easier - sometimes even a better idea - to use an existing, mature solution. What helps you to determine its value from a code standpoint? Your existing experience. -- Network Infrastructure Manager Documentation, Webmaster Teams http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case madness
> On Tue, Jan 18, 2011 at 23:39, Joshua Kehn wrote: >The use of existing packages is so increasingly prevalent that I > have the unfortunate displeasure of knowing many "developers" who do > nothing but this, yet who can't even answer simple questions about > general coding, and who cry and complain that a "previous developer" > must have borked something. I think Donovan is right on track here > --- he's just getting started, and challenging himself to learn the > language at a deeper level. That will make him a developer, not just > a copy-and-paster. > >I do see from where it is you're coming, though, Josh --- once > you've gotten the fundamentals, a lot of times it's easier - sometimes > even a better idea - to use an existing, mature solution. What helps > you to determine its value from a code standpoint? Your existing > experience. > > -- > > Network Infrastructure Manager > Documentation, Webmaster Teams > http://www.php.net/ You are correct, and it is a shame to see many developers fall into the copy / paste realm, especially with a language like PHP where such snippets are often found easily but of dubious quality. Rolling your own is a great way to understand how things work (or should work) internally, as well as giving you valuable practice. I don't mean to discredit is. As I mentioned, more often then not I'm a fan of it. Regards, -Josh Joshua Kehn | josh.k...@gmail.com http://joshuakehn.com
Re: [PHP] switch case madness
. >> >> I do see from where it is you're coming, though, Josh --- once >> you've gotten the fundamentals, a lot of times it's easier - sometimes >> even a better idea - to use an existing, mature solution. What helps >> you to determine its value from a code standpoint? Your existing >> experience. >> >> -- >> >> Network Infrastructure Manager >> Documentation, Webmaster Teams >> http://www.php.net/ > > You are correct, and it is a shame to see many developers fall into the copy > / paste realm, especially with a language like PHP where such snippets are > often found easily but of dubious quality. Rolling your own is a great way to > understand how things work (or should work) internally, as well as giving you > valuable practice. I don't mean to discredit is. As I mentioned, more often > then not I'm a fan of it. > > Regards, > > -Josh > > Joshua Kehn | josh.k...@gmail.com > http://joshuakehn.com > > I find that at first, in any language, playing with the snippets through a form of stimuli and response(I move this, this happens, or doesn;t), helps to reinforce what I'm learning. But after understanding the snippet, I don't find that reapplying it later subverts the concept of being a 'real coder', because in the end you want to move to a more efficient means of coding, which is, if I'm not mistaken, where these larger frameworks come from-snippets that are reusable(all the way down to a login system snippet). -- It sure does get lonely up under this bridge. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Autorename extracted files from zip-archive
On 19 January 2011 14:06, Merlin Morgenstern wrote:
> Hello,
>
> I am using shell_exec to uncompress zip files which works fine, but has one
> big problem. Whenever the zip-archive containes an already existing file
> name, it will overwrite the current one. I need the file to be extracted and
> autorenamed.
>
> This is the code line:
>
> $output = shell_exec('unzip -jo '.$filename.' -d '.$path);
>
> Does anybody know a way on how to autorename existing files?
>
> I thought about a workaround on extracting to a tmp folder and then moving
> to the proper directory while renaming the files if they already exists.
> Unfortunatelly I could not find a way to do this.
>
> Thank you for any help on this.
>
> Merlin
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
As you are using an external app (unzip), does it support any sort of
renaming? PHP isn't actually involved in the extraction process in
this instance.
You may be better off using the ZIP extension in PHP to extract the
data and write it to your own files.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On Wed, Jan 19, 2011 at 8:21 AM, Richard Quadling wrote: > On 19 January 2011 07:46, Adam Richardson wrote: > > On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield >wrote: > > > >> 3) Static analysis. Instead of reflection, either tokenize or string > parse > >> all files to determine what classes implement what interfaces and then > >> cache > >> that information. We are actually using this method now to locate > classes, > >> and it works surprisingly well. Because we never parse code into memory > it > >> does not ever spike the memory usage. However, it is impossible to > >> determine > >> if a class implements a given interface by static analysis unless it > >> declare > >> so itself with the implements keyword. If it does so indirectly via > >> inheritance, either via the class or via the interface, it would not > find > >> it. > >> That necessitates that any "detectable" classes must explicitly > themselves > >> declare their interfaces, even if it is redundant to do so. I don't > like > >> that > >> approach, but it's the first one that strikes me as even viable. > >> > > > > 4) Explicit declaration. In this approach we detect nothing and rely on > the > >> plugin developer to do everything. That is, they must provide somewhere > >> (either in code or a configuration file) an index of all classes they > >> offer, > >> the interfaces they implement, and the file in which they live. While > this > >> makes the implementation easy, it is a huge burden on the plugin > developer > >> and > >> I'm quite sure they'll forget to do so or get it wrong on a regular > basis. > >> > > > > I'd suggest combining 3 and 4. Build a tool that performs a static > analysis > > of a group of files and make it easy for developers to use. This tool > would > > generate the explicit declarations your codebase would utilize when > > answering such questions as "which classes implement interface foo". The > > file the static analysis tool generates could be easily hand editable, so > > developers could tweak it if they see issues (just in case the static > > analysis tool has bugs early on), or for small plugins, just quick crank > out > > a couple lines by hand. > > > > As long as the static analysis tool builds a composite of class hierarchy > > established in all the files (project wide, at least in terms of the > > plugin), you wouldn't have to double declare interfaces so they could be > > detected. > > > > Adam > > > > -- > > Nephtali: A simple, flexible, fast, and security-focused PHP framework > > http://nephtaliproject.com > > > > There is a pecl extension called inclued [1] & [2] which could be used I > think. > > It can be used to produce a list of all the relationships between > included files, so a one off pass of all the class files (simply > include them) and then retrieve the analysis from inclued. > > You can now build a class dependency tree from that data and cache it. > > Pretty much exactly what you need. > Richard, While inclued performs a nice analysis of the files included at a given stage of a script, I don't see that it performs a static analysis of the PHP contained within the files so Larry could use it to detect the interfaces implemented in a given set of PHP files. I looked at the pages: http://docs.php.net/manual/en/inclued.examples-implementation.php http://docs.php.net/manual/en/function.inclued-get-data.php I'm curious about this feature myself, so if I missed something, please let me know. Thanks, Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
[PHP] News Server Time Outs
The newsgroup server seems to have a repeated-visit throttle, or whatever. For the last two weeks at least, I can only open 2 or 3 messages and them I get repeated time-outs. It acts like the DoS or flood prevention is kidding in to aggressively. Al.. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On 1/19/11 10:09 AM, Adam Richardson wrote: On Wed, Jan 19, 2011 at 8:21 AM, Richard Quadlingwrote: On 19 January 2011 07:46, Adam Richardson wrote: On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield 3) Static analysis. Instead of reflection, either tokenize or string parse all files to determine what classes implement what interfaces and then cache that information. We are actually using this method now to locate classes, and it works surprisingly well. Because we never parse code into memory it does not ever spike the memory usage. However, it is impossible to determine if a class implements a given interface by static analysis unless it declare so itself with the implements keyword. If it does so indirectly via inheritance, either via the class or via the interface, it would not find it. That necessitates that any "detectable" classes must explicitly themselves declare their interfaces, even if it is redundant to do so. I don't like that approach, but it's the first one that strikes me as even viable. 4) Explicit declaration. In this approach we detect nothing and rely on the plugin developer to do everything. That is, they must provide somewhere (either in code or a configuration file) an index of all classes they offer, the interfaces they implement, and the file in which they live. While this makes the implementation easy, it is a huge burden on the plugin developer and I'm quite sure they'll forget to do so or get it wrong on a regular basis. I'd suggest combining 3 and 4. Build a tool that performs a static analysis of a group of files and make it easy for developers to use. This tool would generate the explicit declarations your codebase would utilize when answering such questions as "which classes implement interface foo". The file the static analysis tool generates could be easily hand editable, so developers could tweak it if they see issues (just in case the static analysis tool has bugs early on), or for small plugins, just quick crank out a couple lines by hand. As long as the static analysis tool builds a composite of class hierarchy established in all the files (project wide, at least in terms of the plugin), you wouldn't have to double declare interfaces so they could be detected. Adam That is essentially #3. The static analysis results could easily be cached in a human-editable form, but in practice I don't think that will be viable. The humans who will be running this system will largely be non-PHP-gurus so asking them to validate the accuracy of a giant PHP array dumped to a file is going to be a losing battle. If we're actually building a full graph to determine indirect implementation that would then preclude pre-deriving information per-plugin and just shipping a manifest file with each plugin. (I could be convinced of that as an approach, but that still doesn't solve the indirect implementation problem.) There is a pecl extension called inclued [1]& [2] which could be used I think. It can be used to produce a list of all the relationships between included files, so a one off pass of all the class files (simply include them) and then retrieve the analysis from inclued. You can now build a class dependency tree from that data and cache it. Pretty much exactly what you need. Richard, While inclued performs a nice analysis of the files included at a given stage of a script, I don't see that it performs a static analysis of the PHP contained within the files so Larry could use it to detect the interfaces implemented in a given set of PHP files. I looked at the pages: http://docs.php.net/manual/en/inclued.examples-implementation.php http://docs.php.net/manual/en/function.inclued-get-data.php I'm curious about this feature myself, so if I missed something, please let me know. Thanks, Adam Yeah, inclued looks cool but it looks like a runtime analysis tool, not a static analysis tool. That runs into the same problem as reflection where I'd have to include the whole code base in order to build up the indexes I need. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On 19 January 2011 16:23, la...@garfieldtech.com wrote: > On 1/19/11 10:09 AM, Adam Richardson wrote: >> >> On Wed, Jan 19, 2011 at 8:21 AM, Richard >> Quadlingwrote: >> >>> On 19 January 2011 07:46, Adam Richardson wrote: On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield>>> wrote: > 3) Static analysis. Instead of reflection, either tokenize or string >>> >>> parse > > all files to determine what classes implement what interfaces and then > cache > that information. We are actually using this method now to locate >>> >>> classes, > > and it works surprisingly well. Because we never parse code into > memory >>> >>> it > > does not ever spike the memory usage. However, it is impossible to > determine > if a class implements a given interface by static analysis unless it > declare > so itself with the implements keyword. If it does so indirectly via > inheritance, either via the class or via the interface, it would not >>> >>> find > > it. > That necessitates that any "detectable" classes must explicitly >>> >>> themselves > > declare their interfaces, even if it is redundant to do so. I don't >>> >>> like > > that > approach, but it's the first one that strikes me as even viable. > 4) Explicit declaration. In this approach we detect nothing and rely on >>> >>> the > > plugin developer to do everything. That is, they must provide > somewhere > (either in code or a configuration file) an index of all classes they > offer, > the interfaces they implement, and the file in which they live. While >>> >>> this > > makes the implementation easy, it is a huge burden on the plugin >>> >>> developer > > and > I'm quite sure they'll forget to do so or get it wrong on a regular >>> >>> basis. > I'd suggest combining 3 and 4. Build a tool that performs a static >>> >>> analysis of a group of files and make it easy for developers to use. This tool >>> >>> would generate the explicit declarations your codebase would utilize when answering such questions as "which classes implement interface foo". The file the static analysis tool generates could be easily hand editable, so developers could tweak it if they see issues (just in case the static analysis tool has bugs early on), or for small plugins, just quick crank >>> >>> out a couple lines by hand. As long as the static analysis tool builds a composite of class hierarchy established in all the files (project wide, at least in terms of the plugin), you wouldn't have to double declare interfaces so they could be detected. Adam > > That is essentially #3. The static analysis results could easily be cached > in a human-editable form, but in practice I don't think that will be viable. > The humans who will be running this system will largely be non-PHP-gurus so > asking them to validate the accuracy of a giant PHP array dumped to a file > is going to be a losing battle. If we're actually building a full graph to > determine indirect implementation that would then preclude pre-deriving > information per-plugin and just shipping a manifest file with each plugin. > (I could be convinced of that as an approach, but that still doesn't solve > the indirect implementation problem.) > > >>> There is a pecl extension called inclued [1]& [2] which could be used I >>> think. >>> >>> It can be used to produce a list of all the relationships between >>> included files, so a one off pass of all the class files (simply >>> include them) and then retrieve the analysis from inclued. >>> >>> You can now build a class dependency tree from that data and cache it. >>> >>> Pretty much exactly what you need. >>> >> >> Richard, >> >> While inclued performs a nice analysis of the files included at a given >> stage of a script, I don't see that it performs a static analysis of the >> PHP >> contained within the files so Larry could use it to detect the interfaces >> implemented in a given set of PHP files. >> >> I looked at the pages: >> http://docs.php.net/manual/en/inclued.examples-implementation.php >> http://docs.php.net/manual/en/function.inclued-get-data.php >> >> I'm curious about this feature myself, so if I missed something, please >> let >> me know. >> >> Thanks, >> >> Adam > > Yeah, inclued looks cool but it looks like a runtime analysis tool, not a > static analysis tool. That runs into the same problem as reflection where > I'd have to include the whole code base in order to build up the indexes I > need. > > --Larry Garfield > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > You would only need to do analysis by reflection once per release though? Just like you would do to build your documentation (using something like phpdoc for exampl
Re: [PHP] Class and interface location
On Wed, Jan 19, 2011 at 11:23 AM, la...@garfieldtech.com < la...@garfieldtech.com> wrote: > On 1/19/11 10:09 AM, Adam Richardson wrote: > >> On Wed, Jan 19, 2011 at 8:21 AM, Richard Quadling> >wrote: >> >> On 19 January 2011 07:46, Adam Richardson wrote: >>> On Wed, Jan 19, 2011 at 2:07 AM, Larry Garfield>>> wrote: 3) Static analysis. Instead of reflection, either tokenize or string > parse >>> all files to determine what classes implement what interfaces and then > cache > that information. We are actually using this method now to locate > classes, >>> and it works surprisingly well. Because we never parse code into memory > it >>> does not ever spike the memory usage. However, it is impossible to > determine > if a class implements a given interface by static analysis unless it > declare > so itself with the implements keyword. If it does so indirectly via > inheritance, either via the class or via the interface, it would not > find >>> it. > That necessitates that any "detectable" classes must explicitly > themselves >>> declare their interfaces, even if it is redundant to do so. I don't > like >>> that > approach, but it's the first one that strikes me as even viable. > > 4) Explicit declaration. In this approach we detect nothing and rely on >>> the >>> plugin developer to do everything. That is, they must provide somewhere > (either in code or a configuration file) an index of all classes they > offer, > the interfaces they implement, and the file in which they live. While > this >>> makes the implementation easy, it is a huge burden on the plugin > developer >>> and > I'm quite sure they'll forget to do so or get it wrong on a regular > basis. >>> > I'd suggest combining 3 and 4. Build a tool that performs a static >>> analysis >>> of a group of files and make it easy for developers to use. This tool >>> would >>> generate the explicit declarations your codebase would utilize when answering such questions as "which classes implement interface foo". The file the static analysis tool generates could be easily hand editable, so developers could tweak it if they see issues (just in case the static analysis tool has bugs early on), or for small plugins, just quick crank >>> out >>> a couple lines by hand. As long as the static analysis tool builds a composite of class hierarchy established in all the files (project wide, at least in terms of the plugin), you wouldn't have to double declare interfaces so they could be detected. Adam >>> > That is essentially #3. Well, actually the method I was describing (all so poorly) was a hybrid, as I was suggesting that each plugin have a manifest, it's just that you'd build a tool to help them generate it the manifest. > The static analysis results could easily be cached in a human-editable > form, but in practice I don't think that will be viable. The humans who > will be running this system will largely be non-PHP-gurus so asking them to > validate the accuracy of a giant PHP array dumped to a file is going to be a > losing battle. My suggestion to make it human-readable/editable was for the sake of plugin developers, not general users who might install the system. > If we're actually building a full graph to determine indirect > implementation that would then preclude pre-deriving information per-plugin > and just shipping a manifest file with each plugin. (I could be convinced > of that as an approach, but that still doesn't solve the indirect > implementation problem.) Given the current information, I think building a tool that performs the static analysis of interfaces per plugin and then providing that tool to developers so they can build a manifest required per plugin is the best alternative. It minimizes the performance issues by working plugin by plugin, provides flexibility for future information to be included in the manifest if it's ever needed, and could be a user friendly option for developers. Anyways, thanks for sharing your problem, Larry. It's nice to ponder such things. You've shown yourself to be a very capable developer through your comments to the list, and I'm sure whatever approach you take will work well. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP] Class and interface location
On 1/19/11 11:16 AM, Adam Richardson wrote: As long as the static analysis tool builds a composite of class hierarchy established in all the files (project wide, at least in terms of the plugin), you wouldn't have to double declare interfaces so they could be detected. Adam That is essentially #3. Well, actually the method I was describing (all so poorly) was a hybrid, as I was suggesting that each plugin have a manifest, it's just that you'd build a tool to help them generate it the manifest. Well, I don't know if it's feasible to do a deep tree at module dev time individually. To clarify, the code base in question has some 2000+ plugins, of which about 100 may be enabled at any given time on a particular installation. That means building the manifest for an individual plugin would require a very extensive build of the entire development installation for that plugin. A particular class could implement an interface provided by another plugin, which in turn inherits from another, which inherits from a core system interface. I'm just worried that the build process would become very onerous and/or expensive. If we kept the "explicit if redundant declaration" requirement, that makes the rebuild much simpler. I guess that would have to be examined experimentally. If we're actually building a full graph to determine indirect implementation that would then preclude pre-deriving information per-plugin and just shipping a manifest file with each plugin. (I could be convinced of that as an approach, but that still doesn't solve the indirect implementation problem.) Given the current information, I think building a tool that performs the static analysis of interfaces per plugin and then providing that tool to developers so they can build a manifest required per plugin is the best alternative. It minimizes the performance issues by working plugin by plugin, provides flexibility for future information to be included in the manifest if it's ever needed, and could be a user friendly option for developers. Anyways, thanks for sharing your problem, Larry. It's nice to ponder such things. You've shown yourself to be a very capable developer through your comments to the list, and I'm sure whatever approach you take will work well. Eh? I barely comment on this list these days. :-) But thanks. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On 1/19/11 10:52 AM, Richard Quadling wrote: There is a pecl extension called inclued [1]&[2] which could be used I think. It can be used to produce a list of all the relationships between included files, so a one off pass of all the class files (simply include them) and then retrieve the analysis from inclued. You can now build a class dependency tree from that data and cache it. Pretty much exactly what you need. Richard, While inclued performs a nice analysis of the files included at a given stage of a script, I don't see that it performs a static analysis of the PHP contained within the files so Larry could use it to detect the interfaces implemented in a given set of PHP files. I looked at the pages: http://docs.php.net/manual/en/inclued.examples-implementation.php http://docs.php.net/manual/en/function.inclued-get-data.php I'm curious about this feature myself, so if I missed something, please let me know. Thanks, Adam Yeah, inclued looks cool but it looks like a runtime analysis tool, not a static analysis tool. That runs into the same problem as reflection where I'd have to include the whole code base in order to build up the indexes I need. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php You would only need to do analysis by reflection once per release though? Just like you would do to build your documentation (using something like phpdoc for example). You _do_ document your code don't you??? Yes, the project is very heavily documented, and I can be rather OCD about my Docblocks. :-) The release cycle for the core system and plugins is not the same, though. Plugins are written on their own schedule and updated whenever. That means we'd need to, at minimum, do a rebuild of an individual plugin at release time and build its manifest, which is still a potentially expensive operation. Actually, thinking about it, since we cannot guarantee a file location we cannot guarantee a working autoload for reflection until after the index is built that autoload can use. That would rule out any sort of reflection approach that doesn't involve loading every PHP file we can find. Doing that individually for every plugin when it's released could get extremely expensive. Also, a PECL module is not an option unless it's possible to make a runtime version of it that can be swapped in, since we cannot guarantee the server environment we're running on beyond stock PHP. :-( (Such is life in the open source platform world.) --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case madness
On Wed, Jan 19, 2011 at 6:45 AM, Joshua Kehn wrote: > On Jan 19, 2011, at 9:43 AM, Jay Blanchard wrote: >> [snip] >> ... >> [/snip] >> Imagine when there'll be the day when you do not have to code at >> all...just copy 'n paste snippets together in the order that you wish >> them to work in and Voila'! - instant web app. >> Th!! > They have that. It's called Ruby on Rails. CodeIgniter and/or Django (Python) are fun. What about a middle of the road solution? Google for "php micro framework" and/or "python micro framework". I have yet to use a micro framework myself, but I am looking forward to playing around with one for one of my next PHP projects... I would love to find one that has a decent "micro" templating system. :D M -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] switch case madness
On Jan 19, 2011, at 12:44 PM, Micky Hulse wrote: > On Wed, Jan 19, 2011 at 6:45 AM, Joshua Kehn wrote: >> They have that. It's called Ruby on Rails. > > CodeIgniter and/or Django (Python) are fun. > > What about a middle of the road solution? > > Google for "php micro framework" and/or "python micro framework". > > I have yet to use a micro framework myself, but I am looking forward > to playing around with one for one of my next PHP projects... I would > love to find one that has a decent "micro" templating system. :D > > M I love using CodeIgniter. I think it's the best minimalist PHP framework out there, and thankfully it doesn't pretend to be Rails. I've been told to look at Lithium but haven't gotten around to it yet. Regards, -Josh Joshua Kehn | josh.k...@gmail.com http://joshuakehn.com
Re: [PHP] switch case madness
On Wed, Jan 19, 2011 at 12:44 PM, Micky Hulse wrote: > On Wed, Jan 19, 2011 at 6:45 AM, Joshua Kehn wrote: > > On Jan 19, 2011, at 9:43 AM, Jay Blanchard wrote: > >> [snip] > >> ... > >> [/snip] > >> Imagine when there'll be the day when you do not have to code at > >> all...just copy 'n paste snippets together in the order that you wish > >> them to work in and Voila'! - instant web app. > >> Th!! > > They have that. It's called Ruby on Rails. > > CodeIgniter and/or Django (Python) are fun. > > What about a middle of the road solution? > > Google for "php micro framework" and/or "python micro framework". > > I have yet to use a micro framework myself, but I am looking forward > to playing around with one for one of my next PHP projects... I would > love to find one that has a decent "micro" templating system. :D > > M > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Here are some interesting frameworks you might want to check out: Lithium Fat-free Limonade Nephtali (my framework) fits within one file (except the config file). I'll send you a note off-list highlighting Nephtali's features. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
RE: [PHP] switch case madness
LOL, so true -Original Message- From: Adam Richardson [mailto:simples...@gmail.com] Sent: Wednesday, January 19, 2011 12:28 PM To: PHP-General Subject: Re: [PHP] switch case madness On Wed, Jan 19, 2011 at 12:44 PM, Micky Hulse wrote: > On Wed, Jan 19, 2011 at 6:45 AM, Joshua Kehn wrote: > > On Jan 19, 2011, at 9:43 AM, Jay Blanchard wrote: > >> [snip] > >> ... > >> [/snip] > >> Imagine when there'll be the day when you do not have to code at > >> all...just copy 'n paste snippets together in the order that you wish > >> them to work in and Voila'! - instant web app. > >> Th!! > > They have that. It's called Ruby on Rails. > > CodeIgniter and/or Django (Python) are fun. > > What about a middle of the road solution? > > Google for "php micro framework" and/or "python micro framework". > > I have yet to use a micro framework myself, but I am looking forward > to playing around with one for one of my next PHP projects... I would > love to find one that has a decent "micro" templating system. :D > > M > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Here are some interesting frameworks you might want to check out: Lithium Fat-free Limonade Nephtali (my framework) fits within one file (except the config file). I'll send you a note off-list highlighting Nephtali's features. Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
What about creating your own docblock tag such as @plugin-interface? While it still requires each plugin to explicitly define the interface(s) it implements, it won't be in the class declaration. This would be very easy to nab for a tree of files using grep, removing the need to do any static analysis or parse PHP code. David
Re: [PHP] Class and interface location
On 1/19/11 3:44 PM, David Harkness wrote:
What about creating your own docblock tag such as @plugin-interface? While
it still requires each plugin to explicitly define the interface(s) it
implements, it won't be in the class declaration. This would be very easy to
nab for a tree of files using grep, removing the need to do any static
analysis or parse PHP code.
David
I'm not sure I see the advantage of that over specifying the interface
in the code:
/**
* Bob does stuff.
*
* @implements Foo
*/
class Bob implements Foo {
}
Either way developers need to explicitly define which interfaces (of
those we care about) the class implements, and we'll have to string
parse the file to find the string "Foo". As far as I know the extra
implements in the class declaration doesn't hurt PHP, it's just redundant.
And actually, thinking about it, I wonder if requiring the explicit
declaration is a good thing anyway because then it's immediately obvious
and greppable what the class does. :-)
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
How often would this profiling have to happen? Seems to me that if it's a "once per build" or "once per someone pressing the button", then go for the more expensive analysis checking through the files. Just build up a tree that shows which classes implement what or inherit from where, save that along with file modification times, and if you have to redo the analysis (on a running system, for instance) then just check files that have changed since last check. It'll likely be expensive once, but probably not very much (after all, you only care about class, you don't need to parse docblocks or anything like it). regards Peter -- WWW: plphp.dk / plind.dk LinkedIn: plind BeWelcome/Couchsurfing: Fake51 Twitter: kafe15 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Class and interface location
> -Original Message-
> From: la...@garfieldtech.com [mailto:la...@garfieldtech.com]
> Sent: Wednesday, January 19, 2011 2:21 PM
> To: php-general@lists.php.net
> Subject: Re: [PHP] Class and interface location
>
> On 1/19/11 3:44 PM, David Harkness wrote:
> > What about creating your own docblock tag such as @plugin-interface?
> > While it still requires each plugin to explicitly define the
> > interface(s) it implements, it won't be in the class declaration. This
> > would be very easy to nab for a tree of files using grep, removing the
> > need to do any static analysis or parse PHP code.
> >
> > David
>
> I'm not sure I see the advantage of that over specifying the interface in
the
> code:
>
> /**
> * Bob does stuff.
> *
> * @implements Foo
> */
> class Bob implements Foo {
>
> }
>
> Either way developers need to explicitly define which interfaces (of those
> we care about) the class implements, and we'll have to string parse the
file
> to find the string "Foo". As far as I know the extra implements in the
class
> declaration doesn't hurt PHP, it's just redundant.
>
> And actually, thinking about it, I wonder if requiring the explicit
declaration
> is a good thing anyway because then it's immediately obvious and
> greppable what the class does. :-)
>
> --Larry Garfield
>
You mean requiring explicit declaration of
> class Bob implements Foo {
>
> }
It's so you can guarantee your app from future breakage because the
interface guarantees minimum functionality and still maintain great
flexibility such that:
interface IDatabase
{
function connect();
function close();
function query();
// etc
}
class MySQLDatabase implements IDatabase
{
function connect() { }
function close() { }
function query() { }
// other interface methods
function nonInterfaceMethod() { }
}
class PostgresDatabase implements IDatabase
{
function connect() { }
function close() { }
function query() { }
// other interface methods
function nonInterfaceMethod() { }
}
class MyObjectMapper extends MySQLDatabase
{
function getAll() { }
function edit() {}
// etc...
}
class Process
{
function _init(IDatabase $db)
{
$db->connect();
$db->query();
$db->close();
}
function exec() { }
// etc...
}
class PhonyObject
{
// miscellaneous methods even if the methods match exactly as the
IDatabase
}
$mdb = new MySQLDatabase();
$pdb = new PostgresDatabase();
$mom = new MyObjectMapper();
$phony = new PhonyObject();
$p = new Process();
$p->_init($mdb); // works
$p->_init($pdb); // works
$p->_init($mom); // works
$p->_init($phony); // fatal error
Hence the `I` in the API. The interface prevents from app breakage because
all classes must have matching method name(s) and the respective function
call parameters. Though, because PHP isn't a strong typed language like
C/C++/C#, Java, etc... the return value type, if any, _may_ break the app
;)
Regards,
Tommy
PS: outlook may wrap the lines... it happened once/twice before.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Class and interface location
On Wednesday, January 19, 2011 8:56:50 pm Tommy Pham wrote:
> > And actually, thinking about it, I wonder if requiring the explicit
> declaration
> > is a good thing anyway because then it's immediately obvious and
> > greppable what the class does. :-)
> >
> > --Larry Garfield
>
> You mean requiring explicit declaration of
>
> > class Bob implements Foo {
> >
> > }
>
> It's so you can guarantee your app from future breakage because the
> interface guarantees minimum functionality and still maintain great
> flexibility such that:
Well, let me offer a more precise example of what I want to do:
interface Stuff {
function doStuff($a);
}
interface Things extends Stuff {
function doThings($a);
}
class Bob implements Stuff {...}
class Alice implements Stuff {...}
class George {}
class Matt implements Things {...}
function make_stuff_happen($o) {
foreach (class_that_implements_stuff() as $class) {
$c = new $class();
$c->doStuff($o);
}
}
The above code should iterate over Bob, Alice, and Matt, but not George. The
trick is how to implement class_that_implements_stuff() (or rather,
class_that_implements_something('Stuff')) in a sane and performant fashion
that supports auto-loading.
If all of the above is together in a single file, it's dead simple with
get_declared_classes() and class_implements(). However, in practice there
could be some 200 interfaces -- with each installation having a different set
of them -- and as many as 500 classes implementing some combination of those
interfaces, possibly multiple on the same class -- also with each installation
having a different set of them. I do not want to be forced to include all of
those classes and interfaces on every page load when in practice only perhaps
two dozen will be needed on a particular request. That makes
class_that_implements_stuff() considerably tricker.
That let naturally to having a cached index (in a database, in a file with a
big lookup array, whatever) that pre-computed which class implements what
interface and what file it lives in, so that we can easily lookup what classes
we need and then let the autoloader find them. (Previous benchmarks have
shown that an index-based autoloader is actually pretty darned fast.) That
just makes building that index the challenge, hence this email thread.
Thinking it through, however, I am now wondering if, in practice, indirect
implementation (class Matt above) will even be that common. It may not be
common enough to be an issue in practice, so requiring Matt to be declared as:
class Matt implements Stuff, Things {...}
isn't really that big of a deal and makes the indexer considerably simpler.
We actually have one already that indexes class locations; it just doesn't
track interfaces.
I also, on further review, don't think that class-based inheritance will ever
be an issue. The following:
class Mary extends Alice {...}
Would not make much sense at all because then both Mary and Alice would run,
so Alice's code would run twice. So I may be over-complicating the situation.
(For those following along at home, yes, this is essentially observer pattern.
However, it's on a very large scale and the thing being observed may not
always be an object, so the usual active registration process of instantiating
both objects and telling them about each other on the off chance that they
*may* be needed is excessively wasteful.)
Does that make it clearer what I'm trying to do?
--Larry Garfield
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] email address syntax checker
Hi Guys, I'm waddling my way through database interaction and thought someone on the list may already have a simple email checker that they'd like to share... you know, looking for the @ char and dots etc.. I did a quick search of the archives and found a couple elaborate things.. but I'm looking for something simple. This job will have trusted users and the checker is more to help them catch mistakes when registering. Thanks!, Donovan -- D Brooke -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] email address syntax checker
On Wed, Jan 19, 2011 at 11:14 PM, Donovan Brooke wrote: > Hi Guys, > > I'm waddling my way through database interaction and thought someone on the > list may already have a simple email checker that they'd like to share... > > you know, looking for the @ char and dots etc.. > > I did a quick search of the archives and found a couple elaborate things.. > but > I'm looking for something simple. Simple is an irrelevant term, you'd have to elaborate on your current experience. This job will have trusted users and > the checker is more to help them catch mistakes when registering. > > Thanks!, > Donovan > > > -- > D Brooke > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- The lawyer in me says argue...even if you're wrong. The scientist in me... says shut up, listen, and then argue. But the lawyer won on appeal, so now I have to argue due to a court order. Furthermore, if you could be a scientific celebrity, would you want einstein sitting around with you on saturday morning, while you're sitting in your undies, watching Underdog?...Or better yet, would Einstein want you to violate his Underdog time? Can you imagine Einstein sitting around in his underware? Thinking about the relativity between his cotton nardsac, and his Fruit of the Looms? But then again, J. Edgar Hoover would want his pantyhose intertwined within the equation. However, I digress, momentarily. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Class and interface location
> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Wednesday, January 19, 2011 7:47 PM
> To: php-general@lists.php.net
> Subject: Re: [PHP] Class and interface location
>
> On Wednesday, January 19, 2011 8:56:50 pm Tommy Pham wrote:
>
> > > And actually, thinking about it, I wonder if requiring the explicit
> > declaration
> > > is a good thing anyway because then it's immediately obvious and
> > > greppable what the class does. :-)
> > >
> > > --Larry Garfield
> >
> > You mean requiring explicit declaration of
> >
> > > class Bob implements Foo {
> > >
> > > }
> >
> > It's so you can guarantee your app from future breakage because the
> > interface guarantees minimum functionality and still maintain great
> > flexibility such that:
>
> Well, let me offer a more precise example of what I want to do:
>
> interface Stuff {
> function doStuff($a);
> }
>
> interface Things extends Stuff {
> function doThings($a);
> }
>
> class Bob implements Stuff {...}
>
> class Alice implements Stuff {...}
>
> class George {}
>
> class Matt implements Things {...}
>
>
> function make_stuff_happen($o) {
> foreach (class_that_implements_stuff() as $class) {
> $c = new $class();
> $c->doStuff($o);
> }
> }
>
> The above code should iterate over Bob, Alice, and Matt, but not George.
> The trick is how to implement class_that_implements_stuff() (or rather,
> class_that_implements_something('Stuff')) in a sane and performant
> fashion that supports auto-loading.
>
> If all of the above is together in a single file, it's dead simple with
> get_declared_classes() and class_implements(). However, in practice there
> could be some 200 interfaces -- with each installation having a different
set
> of them -- and as many as 500 classes implementing some combination of
> those interfaces, possibly multiple on the same class -- also with each
> installation having a different set of them. I do not want to be forced
to
> include all of those classes and interfaces on every page load when in
> practice only perhaps two dozen will be needed on a particular request.
> That makes
> class_that_implements_stuff() considerably tricker.
>
> That let naturally to having a cached index (in a database, in a file with
a big
> lookup array, whatever) that pre-computed which class implements what
> interface and what file it lives in, so that we can easily lookup what
classes
> we need and then let the autoloader find them. (Previous benchmarks
> have shown that an index-based autoloader is actually pretty darned fast.)
> That just makes building that index the challenge, hence this email
thread.
>
> Thinking it through, however, I am now wondering if, in practice, indirect
> implementation (class Matt above) will even be that common. It may not
> be common enough to be an issue in practice, so requiring Matt to be
> declared as:
>
> class Matt implements Stuff, Things {...}
>
> isn't really that big of a deal and makes the indexer considerably
simpler.
> We actually have one already that indexes class locations; it just doesn't
> track interfaces.
>
> I also, on further review, don't think that class-based inheritance will
ever
> be an issue. The following:
>
> class Mary extends Alice {...}
>
> Would not make much sense at all because then both Mary and Alice would
> run, so Alice's code would run twice. So I may be over-complicating the
> situation.
>
> (For those following along at home, yes, this is essentially observer
pattern.
> However, it's on a very large scale and the thing being observed may not
> always be an object, so the usual active registration process of
instantiating
> both objects and telling them about each other on the off chance that they
> *may* be needed is excessively wasteful.)
>
> Does that make it clearer what I'm trying to do?
>
> --Larry Garfield
>
Ah... My current project is a bit similar to your intention but invoking a
class depending on functionality needed and not by looking up the interface.
Just about everything within the project is either interface or abstract
except the 'brain' of the app. It's a MVC design intending to be 100%
modular. A module may have several urls mapped to it. Any adequate third
party plugins can be dropped within any module. So the problem you'll run
into is this:
interface IBase
{
function baseFunc();
}
class BaseClass implements IBase { }
class SubClass extends BaseClass { }
class SubSubClass extends SubClass { }
How would you know which class (BaseClass, SubClass, SubSubClass, or however
many subs down the tree branch you may have eventually) to invoke if you're
basing on just the interface ? IMHO, I think you're overcomplicating your
project. I think you should design it base on the interface (ie, passing it
within the parameter(s) ) but invoke the 'right' class for the functionality
intended. That's why I gave the example earlier. As the project may start
out with just Database. Event
Re: [PHP] email address syntax checker
On 20 January 2011 05:14, Donovan Brooke wrote:
> Hi Guys,
>
> I'm waddling my way through database interaction and thought someone on the
> list may already have a simple email checker that they'd like to share...
>
> you know, looking for the @ char and dots etc..
>
> I did a quick search of the archives and found a couple elaborate things..
> but
> I'm looking for something simple. This job will have trusted users and
> the checker is more to help them catch mistakes when registering.
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
echo "Bad user! Bad user!";
}
Regards
Peter
--
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
