Larry,
I suggested the docblock tag because it seemed you didn't want to mandate
that plugins that extend other plugins be forced to include the interface in
an actual PHP implements clause. Duplicating the implements clause doesn't
cause any problems for PHP as you said, so that's one route.
Adv
> -Original Message-
> From: Steve Staples [mailto:sstap...@mnsi.net]
> Sent: Thursday, January 20, 2011 5:16 AM
> To: Larry Garfield
> Cc: php-general@lists.php.net
> Subject: Re: [PHP] Class and interface location
>
> On Wed, 2011-01-19 at 21:46 -0600, Larr
On Wed, 2011-01-19 at 21:46 -0600, Larry Garfield wrote:
> 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
On 20 January 2011 03:46, Larry Garfield wrote:
> Does that make it clearer what I'm trying to do?
Some ideas. I've no idea if any of them are any good.
1 - All plugins implement a self-registration mechanism.
A analogy to this in the Windows world would be an ActiveX component.
All ActiveX com
> -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:
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 requ
> -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:
> > W
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 alo
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 gr
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
analy
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 a
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 essentia
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,
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:
>
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 deter
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
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 clas
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
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
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,
20 matches
Mail list logo
