[PHP] ServInt feedback

[la...@garfieldtech.com]

Hi folks.  A while back I inquired about "managed VPS" hosting services. 
   I have since gotten a recommendation for ServInt.net, which seems to 
offer an actual managed VPS or something very close to it.  Does anyone 
else have experience with them, good or bad?  Are they decently 
responsible about maintaining the server image, and responsive about 
requests to change things?  Decent uptime?  All that usual stuff. :-)


Thanks in advance.

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Class Problems

[la...@garfieldtech.com]

The "private" keyword was added in PHP 5.  PHP 4 doesn't have visibility 
identifiers.  In PHP 4 you have to use "var", which is then always public.


Or you could just use PHP 5 instead of a dead language. :-)

Ashley Sheridan wrote:

Hey all,

Is there any reason why this shouldn't work correctly on a server
running PHP 4.4.7:



I would at the very least expect to see the 'wtf' printed out. I've got
a whole class I've written that works fine in PHP 5, but on PHP 4
server, it does nothing with even this simple example.

Any ideas?

Thanks,
Ash
http://www.ashleysheridan.co.uk




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Class Problems

[la...@garfieldtech.com]

Ashley Sheridan wrote:

On Tue, 2009-08-11 at 17:57 +0200, Aschwin Wesselius wrote:

Ashley Sheridan wrote:

And I really would use a PHP 5 server given the choice. I've tried
speaking to the hosting company a few times, but they brush me off!
  

Hi Ashley,

And how is their SLA then? Do you take full responsibility in case of a 
security breach? PHP 4 is way long ago and there are plenty hosting 
companies that do have PHP 5 and have a clear security/update policy.


You, yes YOU, are their client paying their sandwich. If you are not 
serviced properly, they have to eat one less. Now, go on and brush them 
off..


Kind regards,

Aschwin Wesselius


My last email to them said that if they don't do something soon, then
I'm going elsewhere, so I'll see if that spurs them on. I'm not into
naming and shaming, but if they don't get back to me on this at all,
then I feel a blog rant coming on!

Thanks,
Ash
http://www.ashleysheridan.co.uk


http://gophp5.org/hosts

Over 200 web hosts that have been committed to PHP 5.2 for at least 1.5 
years, in most cases over two years.  I am not affiliated with any of 
them directly.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Memory investigation

[la...@garfieldtech.com]

Yep, I'm familiar with XDebug and KCacheGrind.  As you say, though, it 
doens't (as far as I am aware) offer the particular data that I'm after. 
 We've already got cachegrind gurus working on the code who know how to 
use it better than I do. :-)  What I'm looking for is "see this big 
cache object we've been building up in memory for this whole page 
request?  Now that we're done with the page, how big is it, really?"


--Larry Garfield

u...@domain.invalid wrote:
ON Linux I have kcacheGrind setup with Xdebug and I find it is a nice 
little thing to have. It won't tell you the memory consumed but it will 
find cycles and display object maps. if you have Kcachegrind it is 
likely you have valgrind installed.

http://www2.mandriva.com/
http://valgrind.org/
http://kcachegrind.sourceforge.net/html/Home.html
http://xdebug.org/
Larry Garfield wrote:
Hi folks.  I have a complicated PHP app that is eating up more memory 
than I think it should.  I have a couple of theories as to where it 
could be going, but I need some way to verify it.


There are a number of large data structures (mostly arrays) that get 
built up throughout the course of the request.  What I'd like to be 
able to do is at certain points check to see how much memory those 
data structures are using.  Because they're not all built at once, the 
usual "check memory before, build, check after" routine won't work.  
Plus, that gets screwed up by PHP's use of copy-on-write at times.


I know that it would result in essentially over-reporting, but I would 
ideally like to be able to ignore the copy-on-write issue and say "if 
this variable were the only thing in memory (and its dependents, of 
course, for a nested array), what would its memory usage be?  I just 
have no idea how to do that.


Anyone have a suggestion for how to accomplish that?

--Larry Garfield




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Memory investigation

[la...@garfieldtech.com]

That's not really what I'm after.  Let me try an example:

function foo($id) {
  static $foos = array();

  if (empty($foos[$id]) {
$foos[$id] = load_foo($id);
  }
  return $foos[$id];
}

When load_foo() is slow (e.g., lots of DB traffic or remote-server calls 
or whatever), such caching can have a significant performance boost. 
Sometime after foo() has been called 15 times from 30 places in code, 
when I get to the end of the request (or just every time I call foo() 
would be fine) I want to be able to do something like:


$cost = get_memory_used_by($foos);

So that I can determine how much memory that caching is costing me over 
the lifetime of the page, and determine if it's a worthwhile trade-off.


--Larry Garfield

dsiemba...@gmail.com wrote:

function check_memory_usage(&$memory)
{
$memory[] = memory_get_usage();
return $memory;
}

something like this?
you can put it wherever you like and returns an array for further 
processing. You could optionally add a second argument to set the index 
to a name and check if the name exists to add 1 to the end of the name 
so your indexes stay maintained.




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Memory investigation

[la...@garfieldtech.com]

Currently it's mostly procedural with some components that are OO.  I 
suspect most of the memory sinks are large arrays (we have a lot of 
them), but I am not certain of that.  Hence my interest in more accurate 
investigation tools.


--Larry Garfield

dsiemba...@gmail.com wrote:
couple questions Larry is this application composed of classes or 
straight up no holes barred procedural code?


la...@garfieldtech.com wrote:

That's not really what I'm after.  Let me try an example:

function foo($id) {
  static $foos = array();

  if (empty($foos[$id]) {
$foos[$id] = load_foo($id);
  }
  return $foos[$id];
}

When load_foo() is slow (e.g., lots of DB traffic or remote-server 
calls or whatever), such caching can have a significant performance 
boost. Sometime after foo() has been called 15 times from 30 places in 
code, when I get to the end of the request (or just every time I call 
foo() would be fine) I want to be able to do something like:


$cost = get_memory_used_by($foos);

So that I can determine how much memory that caching is costing me 
over the lifetime of the page, and determine if it's a worthwhile 
trade-off.


--Larry Garfield

dsiemba...@gmail.com wrote:

function check_memory_usage(&$memory)
{
$memory[] = memory_get_usage();
return $memory;
}

something like this?
you can put it wherever you like and returns an array for further 
processing. You could optionally add a second argument to set the 
index to a name and check if the name exists to add 1 to the end of 
the name so your indexes stay maintained.






--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] CodeBubbles -- the coolest IDE innovation since since syntax highlighting and intellisense

[la...@garfieldtech.com]

I'd settle for Intellisense/code completion working consistently and 
reliably in Eclipse PDT in the first place.  I don't remember the last 
time it did.


--Larry Garfield

On 3/12/10 2:43 PM, Daevid Vincent wrote:

Wow.  Maybe the coolest IDE innovation I've seen since syntax highlighting
and intellisense.

  
http://www.cs.brown.edu/people/acb/codebubbles_site.htm

http://www.cs.brown.edu/people/acb/codebubbles_beta_signup.htm
  Code Bubbles is built on top of Eclipse so it can open/work with any
existing Eclipse project.

...are you listening Zend? Someone needs to port this over for a PHP IDE
(It's JAVA only AFAIK)



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] any reason *not* to use PEAR DB module when accessing mysql?

[la...@garfieldtech.com]

Add me to the list of people recommending PDO.  It's much nicer to work 
with than the ext/mysql API, and frankly more secure since you get 
prepared statements.  It won't get you complete database independence 
for a number of reasons (mostly due to databases being too 
unstandardized because they all suck in different ways; I say this as 
someone who has written an abstraction layer atop PDO and it wasn't 
easy), but it will get you part way there and even if you only ever use 
MySQL is a nicer API to work with.


--Larry Garfield

On 3/19/10 9:17 AM, Robert P. J. Day wrote:


   (just a warning -- as a relative newbie to PHP, i'll probably have
the occasional dumb question.  just humour me.)

   i'm looking at some existing PHP code that accesses a mysql 5.0 db,
and it's coded using the mysql-specific calls:  mysql_connect,
mysql_select_db, etc, etc.

   is there any reason i *wouldn't* want to rewrite that code using the
more general PEAR DB module, and use mysqli?  certainly, as i read it,
using the PEAR DB module would make it easier down the road if i
suddenly decide to change the DB backend.

   anyway, any compelling arguments for or against?

rday
--



Robert P. J. Day   Waterloo, Ontario, CANADA

 Linux Consulting, Training and Kernel Pedantry.

Web page:  http://crashcourse.ca
Twitter:   http://twitter.com/rpjday




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] another question on setting include paths for a project

[la...@garfieldtech.com]

On 3/22/10 10:25 AM, Paul M Foster wrote:


That's the key. You can do anything you want inside __autoload(). If you
must consult something in the environment, there are a couple of ways to
do it. First, set a variable in the $_SESSION array, and consult it in
__autoload(). Second, use a configuration file for your application.
Have it in a stable place, and read the values out of it as needed.
Consult these in your __autoload() if you like.

Paul


I'd suggest skipping __autoload() and going straight for 
spl_autoload_register(), as it does the same thing but is more flexible 
since you can then have multiple autoload callbacks if necessary.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever "grow up" and have threading?

[la...@garfieldtech.com]

On 3/23/10 6:04 PM, Tommy Pham wrote:


If throwing hardware at it won't work because of the above mentioned,
then you would change the design right?  How long would that take?
What if PHP has threads, how long would it take you implement threads
with minor changes versus and overhaul of application design, coding,
QA, etc... In summary, you're saying that PHP can not grow/evolve with
business right?  If the company started small and want to use
available open source solutions, then grow quickly because of their
unique and quality products and services, and become enterprise level
with-in a few years, what then?  Slow down business growth just so
that IT can migrate everything to another language? Of all the
enterprise applications I've seen, they used threads.

Regards,
Tommy


The word "enterprise" is meaningless in this context because it provides 
no context for the distinction.  What does "enterprise" mean?  Gets 
Captain Kirk to his next date?  Is OpenOffice.org's plugin download site 
enterprise?  Is Sony BMG enterprise?  The sites for the cities of London 
and Athens?  Whitehouse.gov?


That's just a couple of sites now running on Drupal, a particular 
single-threaded PHP application.  That's not counting the thousands of 
similar organizations running PHP (not even PHP-wrapping-custom-C like 
Yahoo) applications of various and sundry kinds.  (Wikipedia anyone?) 
PHP *is* in the enterprise and quite happy there.


"Not ready for the enterprise" is a totally meaningless statement. 
Similarly, if you cannot think of any way to scale an application that 
doesn't involve threads then I question your competence as a programmer. 
 Sure, threads can be one way to speed things up.  There are lots and 
lots of others that may be more or less appropriate depending on the 
circumstances.  Threads have their own scaling issues, namely they have 
to live within the same process on the same box.  That means when you 
hit the maximum size of your server, you're done.  That doesn't mean 
threads are bad, but they have their trade-offs just like everything 
else does.


But let's consider what adding threads to PHP would take.  That would 
mean making PHP a shared-memory architecture, so that different requests 
now operated in the same memory space.  That means RAM-based 
persistence.  That means needing to write thread-safe PHP libraries. 
(Not the ones in C; I mean the millions of lines of code of PHP already 
out there.)


In short, adding threading support to PHP means PHP is no longer PHP. 
It's Java with dollarsigns.  It's a complete and total rewrite of the 
entire language runtime and environment, and all of the code build atop it.


The idea that you could "just add threads" to PHP and make it 
"enterprise-ready" is so naive it's mind boggling.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Properly handling multiple constructors.

[la...@garfieldtech.com]

On 3/24/10 11:06 AM, Richard Quadling wrote:

On 24 March 2010 15:51, Robert Cummings  wrote:

Yes you can do that also, you seemed to want constructors though :) As for
misused... variable parameters with mixed types is common enough that I
wouldn't call it misuse. It's succinct and solves a problem. Look at the
printf() family of functions.


As multiple constructors were a no-go, I wanted an alternative. As I'm
working on this, I'm getting feedback from other people. The connector
needs to be a singleton - this is currently missing from the original
app. Something I wasn't told! (Well, maybe someone may have mentioned
it once). The static "constructors" (for that is what they end up
doing) along with the appropriate singleton logic would seem to
suffice and be a perfect match.

Thanks for all your help.

I'm trying to learn ZF as well as port this unfinished app.

Regards,

Richard.


This actually sounds like a factory to me.  You want to move some of 
that logic out of the pizza object entirely.


class PizzaHut {

  public function getByKey($key) {
$properties = $this->lookupFavorite($key);
return new Pizza($properties);
  }

  public function getByProperties($properties) {
return new Pizza($properties);
  }

  public function getByDefinition($base, $toppings, $cheese) {
$properties = array(
  'base' => $base,
  'toppings' => $toppings,
  'cheese' => $cheese,
)
return new Pizza($properties);
  }
}

$factory = new PizzaHut();
$pizza = $factory->getByKey("MyFavorite");
$pizza = $factory->getByProperties(...);

And so on.  The Pizza class is now responsible for one thing: Being 
pizza.  MAKING a pizza is not the pizza's job, it's PizzaHut's job.  All 
of the methods of PizzaHut can be cleanly documented, and you can add 
more ways of making Pizza without having to modify the Pizza class, and 
all of them return a pizza that looks identical.  You could even create 
a Domino's class, too, to build pizza in an entirely different way but 
still get a pizza when you're done.


You may want to go as far as making each of those properties a set 
method rather than a big array of properties, but I leave that as an 
exercise to the reader.  (I grow less enamored with big, hard to 
document arrays every time I use them.)


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Will PHP ever "grow up" and have threading?

[la...@garfieldtech.com]

On 3/24/10 2:33 PM, Rene Veerman wrote:


It's a debate. The dev team consider proposals and weigh in on the merits. I
was a proponent for goto support during the development of PHP 5. We now
have it. If you arguments are valid and there's no technical issue
preventing it, and there's someone with time and skill to created the
functionality, then it will happen. If not then it won't. I've seen many
things added to PHP and I've watched and participated in the threads on
internals that have lead to many new features. This is open source, opinions
matter, but personal attacks and poor argument do not really make the cut.



hahaha... you dismiss what i believe to be valid explanations without
any counter-argument besides "more sql hardware!", not just by me but
by all advocates of threading&shared memory in php.

for some reason, which is still not clear to me, you nay-sayers refuse
to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat")
evolve to stay useful, relevant even, in a changing market.

and you're blatantly telling me to use a different kind of "hammer",
one that would force me to rewrite large sections of my existing
code-base, and one that i have told you i would find for many other
_valid_ reasons not optimal.


And what you seem to be missing is that making PHP userspace threaded is 
such a major change to the underlying code base and architecture that it 
would essentially be a total and complete rewrite, and would require 
people to rewrite large portions of their existing PHP userspace code.


So it's either you adjust your code to fit the paradigm that PHP is 
built for from the ground up, or the entire rest of the world adjusts 
its code to fit the paradigm that you think you want to have.



basically, you're determining my choice of options without me ever
having forced you to do something a certain way..

so you'll have to excuse my strong language.
it's just letting you know that you shouldn't butt into other peoples
business when it doesn't really affect you.


Except having to rewrite all of my code to be thread safe would affect me.

If you didn't want to have a discussion, which by nature has differing 
view points, you shouldn't be on a discussion list.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Standard built-in functions source code

[la...@garfieldtech.com]

http://www.php.net/svn.php

Everything is in SVN, although anything built-in is written in C code, 
not in PHP.


--Larry Garfield

On 5/19/10 3:41 PM, Leandro de Oliveira wrote:

Hi,

I'd like to know where is the source code of built-in functions if it's freely 
available. I'm interested in math and cryptography functions specifically.

Thank you


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] iCal parsing and processing

[la...@garfieldtech.com]

Hi folks.  I am looking for a good iCal processing library (open source 
/ GPL compatible).  Unfortunately, everything I've been able to find so 
far is half-assed, incomplete, buggy, or so horribly designed that I'd 
be embarrassed to use it (or several of the above).  I was hoping 
someone could recommend one that actually works.  I'd prefer an OO 
interface as it seems a natural fit, but at this point I'll settle for 
whatever works.


I am not looking for an application with UI and form integration and 
stuff.  I just want a working stand-alone parser.  (If it can be ripped 
out of something more complete, that's fine.)


My needs:
1) Given raw data (provided by a user form that I can already handle), 
construct iCal VEVENT information including RRULEs and EXRULEs.
2) Given a VCALENDAR / VEVENT object, generate the appropriate iCal text 
string that I can write to a file or return to the browser with the 
appropriate mime header.
3) Given a VCALENDAR / VEVENT object with RRULEs and EXRULEs in it, be 
able to say "give me the start/end dates of the next X occurrences from 
some date" or "give me all the start/end dates of occurrences until date Y".


What I've found so far:

http://www.kigkonsult.se/iCalcreator/ - This is the best I've found so 
far, and it's what I'm using now.  It's missing requirement #3, though, 
as near as I can tell.  Actually if I could add that functionality to it 
without too much trouble I'd probably stick with it, but it's 
non-trivial functionality.  It's also PHP 4 OO, but I can deal.


http://phpicalendar.net/ - This claims to do #3, I think, but it's 
integrated into a web app.  The code for it is also horrific, as the 
entire parser is build on include files that rely on global variables 
without using any functions.  The security implications of that alone 
scare me to death to say nothing of side effects and stability.


http://code.google.com/p/qcal/ - Documentation is sorely lacking, as it 
is listed as "pre-alpha, real alpha to be released in January".  That 
post was made in December, and there's still no "real alpha". :-)  So I 
can't really tell if it does what I need or not.


A quick search turned up nothing in PEAR, and Zend Framework has only a 
proposal from 2 years ago, not an actual library.


Any others I don't know about?  This seems like an area that cries out 
for a good standard library, but as of yet I haven't found one that 
works.  Help or pointers would be much appreciated.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Method documentation

[la...@garfieldtech.com]

Hi folks.

OK, so here's the deal.  I am trying to figure out the "right" way to 
document methods in OO code that includes method overriding in child 
classes.  Simple, right?  Unfortunately, it seems the tools out there 
are making this much more complicated than it should be.  Example:


class Foo {

  /**
   * Says hello.
   *
   * Lengthier description of this method.
   *
   * @param int $a
   *   The first variable.
   * @param int $b
   *   The second variable.
   * @return string
   *   A message.
   *
   */
  public function hello($a, $b) { /* ... */ }
}

class Bar extends Foo {
  public function hello($a, $b) { /* ... */ }
}

Seems simple, right?  Here's the problem(s):

- If I put no docblock on Bar::hello(), every IDE I've tried shows no 
documentation whatsoever when I do $b = new Bar; $b->he...  It will 
auto-complete, but does not provide any documentation.  Documentation 
parsers (PHPDoc, Doxygen, etc.) will detect that and show the parent 
method's docblock, however, and it's easy to maintain.


- If I put no docblock on Bar::hello(), someone just reading the code 
visually has no idea what the method does, or what parent class or 
interface it comes from that might contain documentation.


- If I put a subset of the documentation on Bar::hello, an IDE shows 
only that subset, which is frequently inadequate.  Documentation parsers 
also, as far as I know, will then only show the abridged version.


- If I duplicate the documentation on Bar::hello(), it shows up in an 
IDE and is there for people reading it, but it still doesn't say what 
interface or parent class it comes from.


- If I duplicate the documentation on Bar::hello(), that's a ton of 
duplicate content that I will then have to always keep in sync as the 
system evolves.  (Rather, that everyone will have to as this is a large 
multi-person project.)


- If I make a docblock that is just a "Overrides Foo::hello()", then 
it's easy to maintain and there's no duplication, but the IDE assistance 
is useless and the documentation parsers I know of will all show that as 
the only description, which is not all that useful.



So it seems like no matter what I do, someone gets totally screwed with 
useless documentation (either IDE users, plain text editor users, 
code/documentation maintainers, or people looking at the documentation 
online in Doxygen or PHPDoc).  Is there an alternative I'm missing that 
doesn't suck?  What do most people do to deal with this trainwreck?


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Method documentation

[la...@garfieldtech.com]

On 5/27/10 10:43 AM, Peter Lind wrote:


You're overriding the function. IDEs should *not* show the parent
documentation, because the parent function does *not* get called. It
only gets called if you do a specific parent::hello($a, $b);


*snip*


So it seems like no matter what I do, someone gets totally screwed with
useless documentation (either IDE users, plain text editor users,
code/documentation maintainers, or people looking at the documentation
online in Doxygen or PHPDoc).  Is there an alternative I'm missing that
doesn't suck?  What do most people do to deal with this trainwreck?



Personally, I think this issue stems from a wrong way of thinking
about methods and overriding them. You're either not documenting the
overriding methods properly or overriding methods for no real reason.
At least, that's how it looks from here (and my apologies if I got it
completely wrong :) ).

Regards
Peter


I'm overriding the method because I want to change the *implementation*. 
 The *interface* of it, which is documented in the docblock, should not 
change and it's a bug (and possibly compile error) if it does change. 
You cannot, for instance, change what parameters the method takes in a 
subclass.  If you change the meaning of those parameters then you're 
setting yourself up for crazy and hard to debug bugs.  So the @param 
documentation absolutely should be the same for both.


To wit:

interface Talk {
  /**
   * Prints a message in the appropriate language.
   *
   * @param $message
   *   A key indicating the message to pull from the DB
   *   and print.
   * @return boolean
   *   TRUE if it worked, FALSE otherwise.
   */
  public function hello($message) {}
}

class TalkInSpanish implements Talk {
  public function hello($message) {}
}

class TalkInKlingon implments Talk {
  public function hello($message) {}
}

The documentation for both concrete implementations is identical.  If 
$message means something different for the Klingon implementation, or if 
the return changes, then that's a critical bug.  You're breaking the 
interface.


But if I do:

$talk = resolve_language();
$talk->hello(...

Then I should get code assistance, and my doc parser should show useful 
information for TalkInKlingon::hello(), and someone just reading 
TalkInKlingon (which may be in a different file than Talk) should be 
able to easily figure out what $message means.


As of yet, I've not figured out a way to get all three that doesn't 
involve tons of repeated copying and pasting and wasting time and lines.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Method documentation

[la...@garfieldtech.com]

On 5/27/10 11:13 AM, Peter Lind wrote:


I'm overriding the method because I want to change the *implementation*.
  The *interface* of it, which is documented in the docblock, should not
change and it's a bug (and possibly compile error) if it does change. You
cannot, for instance, change what parameters the method takes in a subclass.
  If you change the meaning of those parameters then you're setting yourself
up for crazy and hard to debug bugs.  So the @param documentation absolutely
should be the same for both.



Sure, but @param, @access and possibly @return are but a part. I stand
by my words: document the parent as a stub and provide actual
documentation for the real implementations. Otherwise you're trying to
be *clever* and will see the age-old result: you'll end up shooting
yourself in the foot or worse places.

Regards
Peter


... What's "clever" about using OO inheritance the way it's designed to 
be used?  Are you actually suggesting that the solution is to insist on 
duplicating the docblock in every child class, which is a huge 
maintenance headache?


I could go through a dozen other examples where this problem exists 
where there's nothing "clever" (when that became an epithet I don't 
know) going on, just rudimentary OO, but I won't clog the list with it. 
 What I'm doing in the previous examples is in no way esoteric.  This 
is OO 101 code.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Method documentation

[la...@garfieldtech.com]

On 5/27/10 11:30 AM, Peter Lind wrote:


Sure, but @param, @access and possibly @return are but a part. I stand
by my words: document the parent as a stub and provide actual
documentation for the real implementations. Otherwise you're trying to
be *clever* and will see the age-old result: you'll end up shooting
yourself in the foot or worse places.

Regards
Peter


... What's "clever" about using OO inheritance the way it's designed to be
used?  Are you actually suggesting that the solution is to insist on
duplicating the docblock in every child class, which is a huge maintenance
headache?


If the implementations are the same in all child classes, then you're
doing OO horribly wrong.


Of course the implementations aren't the same.  That would be silly. 
But the API is the same, by design.



If they're *not* the same, then you'll merely
be duplicating a part of the documentation (docblocks do *not* just
consist of @param and @access) while writing the rest of the
documentation to show what you're actually doing different in each
method.


I generally do not put a description of the entire internal algorithm 
into the docblock, as that is not part of the API.  That's also by 
design.  Even if there is implementation-specific stuff to add, the 
"short description line", @params, @return, and lots of other things 
don't change, nor should they.  So at best you're duplicating half the 
docblock each time.  Still a high maintenance burden.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Method documentation

[la...@garfieldtech.com]

On 5/27/10 12:10 PM, Adam Richardson wrote:


Larry,

I've thought about this very issue before (java developers sometimes lament
this issue, too), and I error on the side of duplication if I'm using
inheritance.

However, I'd say I rarely use inheritance for anything in my development,
and I'm much more likely to use composition.

When a project evolves that's built almost entirely using design patterns
focused on composition, I find that I very rarely have to duplicate any
documentation, or rework documentation later on because a completely new
component is being used.

Outside of PHP (Scala, Objective C, F#, etc.), it seems like inheritance is
advocated much less frequently, due to the power and simplicity of
composition (e.g., change behavior at runtime, requires less knowledge of
the parent classes.)

Quoting the Head First book on design patterns:
"Favor composition over inheritance"


I agree entirely there. :-)  However, the same question applies when 
using interfaces (which are common if you're doing composition).  See 
the language example I had earlier.  Where should the documentation of 
the hello() method go?  the Talk interface, the TalkInKlingon class, the 
TalkInSpanish class, all three...?


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Method documentation

[la...@garfieldtech.com]

On 5/27/10 3:15 PM, Adam Richardson wrote:

On Thu, May 27, 2010 at 3:59 PM, Waynn Lue  wrote:


I've seen @inheritDoc used in Java before, though I'm not sure about
the php support.

Waynn




You're absolutely right, Waynn,

Phpdocumentor has this, too:
http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.inlineinheritdoc.pkg.html

However, Netbeans (and I'm assuming other PHP IDE's, but I'm only using
Netbeans) doesn't parse the inheritdoc element so its info is available with
code-completion.  I think Larry was trying to find something that would work
for both generated documentation AND IDE auto-complete capabilities.

Adam


Correct.  @inheritDoc sounds promising.  However, of the three possible 
consumers (humans reading the code, IDEs reading the code, and 
documentation generators reading the code) the documentation generator 
is lowest priority; I figure whatever we end up doing we can write the 
script to handle it.


I'm getting the impression that we either say FU to people reading the 
code or FU to people using IDEs. :-(  Either that or duplicate at least 
large swaths of the documentation (the shortdesc, @params, and @return 
at least).


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] CakePHP, alternatives?

[la...@garfieldtech.com]

First spend time working with straight up PHP, writing your own stuff, 
throwing it away, and writing it again.  What you'll learn that way is 
immeasurable.


Then pick a framework (Cake, Drupal, Symfony, Zend, PEAR, whatever) and 
learn it, maybe two.  Try working with it and extending it.


Then do the bulk of your serious work with that framework, having had 
enough experience to understand what it's doing and why.


The timeframe for that process will vary widely from a few months to a 
few years depending on how quickly you pick stuff up and how much time 
you have, but that's going to get you the best education and productivity.


--Larry Garfield

On 6/3/10 12:51 PM, Shreyas wrote:

Folks,

Just quite could not stop taking your inputs before I start my learning
curve to shape up.

Should I use one of these frameworks or just *K*eep *I*t *S*imple and *S*tupid
and learn it the traditional way? Thoughts?



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] fetching DB entries

[la...@garfieldtech.com]

Performance-wise, SELECT * is slower than specifying fields 
(marginally).  If you just want a single field then mysql_result() will 
be faster, but if you want multiple fields mysql_fetch_* is your best bet.


As far as the PHP goes, if you know there will be only a single record 
I'd suggest using:


if ($row = mysql_fetch_array($result)) {
  // Do stuff
}

As then you get an automatic "not found" else condition you can use. 
That should be the same performance as the while, but get you the extra 
information.


That said, you really shouldn't be using ext/mysql anymore.  Use either 
ext/mysqli or PDO.  Better APIs, more secure, faster, and actually 
maintained.


--Larry Garfield

On 6/21/10 1:31 PM, Ashley Sheridan wrote:

Hi All,

This is just a bit of a 'throw it out to the masses' sort of question to
see what people might recommend.

At the moment, if I am retrieving a single record from the DB, my code
looks like this:

$query = "SELECT * FROM table WHERE id=1";
$result = mysql_query($query);
while($row = mysql_fetch_array($result))
{
 return $row;
}

Now, aside from the actual SQL involved, is this efficient? Would it
gain me anything if I used mysql_result() statements instead, or would
that only be efficient if there were a small number of fields I was
retrieving data for? Should I use something else entirely?

I've not got to the testing this myself, as I figured something like
this might be common knowledge for all of you who are better than me at
optimisation.

Is it even an issue if I'm only retrieving a single record in this
manner (I always make my id field in a table the primary key, so it
means I won't ever be retrieving more than one record)

Thanks in advance for any input you guys have!

Thanks,
Ash
http://www.ashleysheridan.co.uk





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] the state of the PHP community

[la...@garfieldtech.com]

On 7/29/10 2:32 AM, Nathan Rixham wrote:


What's your previous language/tech trail?


Started with QBasic and realized it was crap. Moved on to Java,
realized object rock but J2EE doesn't. Moved to PHP / Java.


QBasic was crap lol, that was my first language after playing with .bat
files!


Oh batch files.  You barely counted as programming, but I spent so much 
time with you.


In hind sight I should have known I'd end up as a full time computer 
geek when I spent so much time figuring out how to make a custom 
batch-based menu system I wrote faster by using a library file rather 
than inlining the output text.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] a quick question about array keys

[la...@garfieldtech.com]

The fastest way is going to be array_values():

http://www.php.net/array_values

--Larry Garfield

On 8/31/10 10:43 AM, Tontonq Tontonq wrote:

a quick question
lets say i have an array like that


Array
(
[300] =>  300
[301] =>  301
[302] =>  302
[303] =>  303
[304] =>  304
[305] =>  305
[306] =>  306
[307] =>  307
[308] =>  308
...
how can i change keys to 0,1,2,3,.. by faster way
(it should like that)>
Array
(
   [0] =>  300
   [1] =>  301
   [2] =>  302
   [3] =>  303




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Queuing servers

[la...@garfieldtech.com]

Hi folks.

I have a project coming up where I will need to process a bazillion (OK, 
a few million) records, possibly with multiple steps.  (In this case I'm 
reading data from one data archive into an Apache Solr server.)  This is 
a natural use case for a queue server, I believe, and while the 
requirements of the project do not dictate a language it makes sense to 
me to use PHP for the processing code since 1) Other parts of the 
project will be using it for web-facing logic and 2) It's the language I 
know best.


I'm trying to select a queue server to use.  The two I'm investigating 
in particular are Beanstalkd (http://kr.github.com/beanstalkd/) and 
Gearman (http://gearman.org/).  In this case I do need a reliable queue, 
even if that means a record gets processed multiple times by accident 
(which in this use case is fine).


Has anyone worked with either of these systems?  Any war stories to 
share, good or bad?  Any guidelines on the number of resources we need?


For Beanstalk, I've found two user-space PHP libraries, one of which is 
apparently dead.  The other is:


https://github.com/pda/pheanstalk/

For Gearman, there appears to be both a PECL module and a PEAR module.

http://pear.php.net/package/Net_Gearman/
http://pecl.php.net/package/gearman

(Naturally they do not appear to be mirrors of each other, just to make 
life difficult.)


I do have access to install PECL modules on the server(s) in question if 
appropriate.


Any experience/advise/horror stories that would help us settle on a 
queue and API library?


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] ORM doctrine

[la...@garfieldtech.com]

On 12/10/10 8:53 AM, Robert Cummings wrote:


Use PHP the way God intended it to be used.


Could you cite a reference for where God states his intentions on PHP?

Thanks,
Rob.


According to Rasmus, it's as a thin integration layer on top of PECL 
modules written in C, most of which are just wrappers around Unix C 
libraries that existed in the early 90s.


Everything else is an abomination.  That means all of your code (for any 
definition of "your").


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PDO: good, popular?

[la...@garfieldtech.com]

I'm the DB maintainer for Drupal 7, and we rebuilt our entire DB layer 
on top of PDO.  It's a rather nice API, although as others have noted it 
does not abstract away SQL entirely; it abstracts the API calls you need 
to use to get to SQL.


We then built a layer on top of that which does abstract away most 
database weirdness using fluent query builders.  It's much 
lighter-weight than an ORM.  I'm in the process of spinning it off as a 
stand-alone library because we think it's that cool, but it's not 
completely divorced from Drupal yet.  Stay tuned. :-)


But yes, PDO is nice.

--Larry Garfield

On 12/14/10 5:10 AM, Sam Smith wrote:

Searching for "PHP CRUD" in hopes of learning the best way to access
databases and to use PEAR or what I came across PDO.

I want to know the communities opinion of PDO: everyone uses it or no one
uses it or it's great or what?

Thanks



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Problems w/ goto

[la...@garfieldtech.com]

On 12/17/10 11:57 AM, Steve Staples wrote:


I had to show the people in my office, and we all got a chuckle from teh
XKCD comic in the PHP documentation for GOTO
http://ca2.php.net/goto

Steve


I was one of the people that argued in favour of GOTO on the Internals
list a few years ago. GOTO has a use, and a very good one at that. It is
by far the most efficient construct when creating parsers or other
similar types of logic flow. The demonized GOTO of the 80s was primarily
due to jumping to arbitrary points in the code, or in the case of basic
to arbitrary line numbers in the code which had little meaning for
future readers. When used properly within a well defined scope and with
well named labels, GOTO can be a superior choice. If you think GOTO
doesn't exist in many types of software, you need only grep for it in
the C source code for PHP, MySQL, and Apache.

Cheers,
Rob.


Oh, i can see where it would be useful, i just hadn't realized it was
still in existence...   and the cartoon, was blown up, and put in my
cubical :)

RAWR!!


It's really a labeling problem.  Goto usually refers to "jump to 
arbitrary line", at least when used in the vernacular.  That's horribly 
bad and evil.


What PHP has implemented is "named break statements", as I understand 
it.  Those are not inherently evil.  It doesn't break program flow any 
more than an exception does, but it's useful for non-error-handling 
cases.  However, it reuses the keyword "goto" which is easy to confuse 
with the abomination above.


It was a rather poor choice of name, frankly.

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Command line PHP

[la...@garfieldtech.com]

Hi folks.  I have a project coming up that will involve writing a 
non-trivial command line PHP application.  Most of it will be nice and 
abstracted and standalone and all of that jazz, but it will need to do 
command line interation.  I'm not sure yet if it will be interactive or 
if I just need to parse lots of command line switches.


Has anyone used a CLI-handling library they like?  I recall briefly 
using the PEAR CLI library many many years ago and disliking it because 
it was only barely a step above the raw PHP-CLI SAPI, and still required 
lots of if-else branching in my code.  I don't know if there's anything 
better since then, however.  I prefer clean OO to procedural, but can 
work with procedural if needs be.  The fewer dependencies it has the 
better as well.


Any recommendations?

(Open source, GPLv2-compatible required.)

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Command line PHP

[la...@garfieldtech.com]

On 1/7/11 11:08 AM, Nicholas Kell wrote:


On Jan 7, 2011, at 11:01 AM, Joshua Kehn wrote:


On Jan 7, 2011, at 11:55 AM, la...@garfieldtech.com wrote:


Hi folks.  I have a project coming up that will involve writing a non-trivial 
command line PHP application.  Most of it will be nice and abstracted and 
standalone and all of that jazz, but it will need to do command line 
interation.  I'm not sure yet if it will be interactive or if I just need to 
parse lots of command line switches.

Has anyone used a CLI-handling library they like?  I recall briefly using the 
PEAR CLI library many many years ago and disliking it because it was only 
barely a step above the raw PHP-CLI SAPI, and still required lots of if-else 
branching in my code.  I don't know if there's anything better since then, 
however.  I prefer clean OO to procedural, but can work with procedural if 
needs be.  The fewer dependencies it has the better as well.

Any recommendations?

(Open source, GPLv2-compatible required.)

--Larry Garfield


Larry-

Why are you writing a command line application in PHP? I would think that is 
starting off on a very wrong foot.

Can you explain the requirements / use cases a bit more?



I agree. Not saying that it isn't doable, because it certainly is, but there 
may be other languages that are available and easier to implement a CLI app, 
such as Python, or some other QnD scripting language.


"Application" is perhaps a misnomer.  I'm not looking at rewriting Emacs 
or anything.  Just some batch processing that would get run as:


php myscript.php --config=foo.xml --setting-1=stuff

And then it will run off and move a few million records around between 
different data stores, a process that will probably take an hour or so. 
 (The backend will be cycling through a queue server.)  I just need 
something to make handling of the args and environment easier, because I 
find the native SAPI calls to be ugly/cumbersome.


I'm sure it could be written in Perl or Python or Java.  But I know 
extremely little Perl, no Python, and my Java is quite rusty, plus there 
are mature PHP libraries that talk to the 3rd party systems I'm tying 
together.  My PHP-fu is much stronger than my Perl, Python, and Java 
combined.



Yeah, PHP was "intended" as a template language only; that fell by the 
wayside a decade ago or more when people started building real web apps 
in it, which are a lot more than templates.  That boat has long since 
sailed and is irrelevant to this discussion.



--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Bare Strings, are they deprecated?

[la...@garfieldtech.com]

Assuming that by "bare strings" you mean:

$foo[bar] = 'baz';

as opposed to:

$foo['bar'] = 'baz';

That is generally considered very bad form in PHP.  That throws an 
E_NOTICE error level, and therefore slows down your code (if only by a 
small amount) for the error handling.  Of course, if you have any 
respect for your code you're developing under E_ALL so bare strings for 
array keys would print ugly notices messages at you constantly.  If 
you're not developing under E_ALL, then you're going to miss error 
messages that will take a long time to track down and correct yourself 
when the PHP interpreter can simply tell you exactly where they are if 
you let it.


Bottom line: Bare strings are not officially deprecated, but no 
respectable programmer users them.


(I now expect to get flamed by someone who uses them but is insulted 
that I am calling them not respectable.  My position on the matter still 
stands.)


--Larry Garfield

On 1/14/11 9:44 AM, Evil Son wrote:

Hello group,

I am a new and just an occasional user of PHP and would like some direction.

I find the use of bare strings as array keys pleasant to work with,
easy on the eye and quick to type. I understand that this use of bare
strings is not encouraged because of possible conflicts with key words
and constants and to a lesser degree loss of some performance.

I tend to use all capitals for my constants and never for my array
keys (if bare). In addition, collisions with PHP keywords fails fast
when they happen. My application is for personal use, and any
performance degradation is insignificant.

However, I can imagine having collisions with constants defined by
libraries that I may use.

Have you found the use of bare strings a significant issue? Or do the
benefits outweigh the dangers? Perl and Tcl both have them. I like
them in PHP too.

Thanks.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Class and interface location

[la...@garfieldtech.com]

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

[la...@garfieldtech.com]

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

[la...@garfieldtech.com]

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] Class and interface location

[la...@garfieldtech.com]

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] How to write code: how wrong am I?

[la...@garfieldtech.com]

On 2/22/11 12:04 PM, Alexis wrote:


On 22/02/11 09:40, Dotan Cohen wrote:

On Tue, Feb 22, 2011 at 16:15, Robert Cummings
wrote:

If you switch to vertically aligned braces you will have an easier time
matching up open and close braces...

if (something)
{
// Code here
}

It's trivial to match using this style since you only need to scan
one axis.



That bracing style drives me nuts! But I have no problem scanning a
single axis for the close brace and any statement, be it an if, while,
switch, or something else.



Well the way you do it, drives me nuts :)

Morale of the story, do whatever *you* are most comfortable
with..personally I indent as well, has it's downsides I admit, but it's
what I've done for the last 20 years and I'm comfortable with it.

Alexis


The most important thing is that you are consistent within a project and 
within a team.  Your entire team should be consistently using one format 
standard, whatever it is.  Failure to do so results in unreadable code, 
because your brain has to shift gears depending on who wrote a given 
block of code.  That's bad news.


I'd rather see code written in brace-on-own-line style (which I despise) 
than code that freely switches between that and inline-brace style (my 
preference) every other for-loop.  That's simply unreadable.


--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Double method access (Hi everyone! :))

[la...@garfieldtech.com]

That's called method chaining.  ->getColumns() will get called on the 
object returned by ->getTable().  That is, getTable() returns an object 
(presumably representing an SQL table, I guess), and that object has a 
getColumns() method, which you call.


This is an extremely common style in Javascript code that has been 
gaining widespread use in PHP OO circles in recent years.  If leveraged 
properly it can create very compact, very readable, very powerful code. 
 (And if done stupidly can lead to a horrid mess, but that's true of 
any coding style.)


--Larry Garfield

On 3/4/11 1:25 PM, Paola Alvarez wrote:

Hi there!,
I have been reading this list before but this is my first post.
Reading some code from Symfony I got this: $this->getTable()->getColumns()
...when you can use this double method access?, I used before the
regular $this->getTable(), but two?. I mean I have been trying but I got an
error*

* Fatal error: Call to a member function ... on a non-object in ...

Thanks!

Paola

PS: BTW, sorry my english isnt really good



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Returning a recordset to a desktop app

[la...@garfieldtech.com]

Assuming you mean that the PHP script is on a web server somewhere and 
the desktop app is hitting it over HTTP, it's no different than any 
other response.  Anything you print will be sent back to the client, in 
this case your desktop a..  So if you want to send XML back, you'd build 
a string with your XML (either manually or using the DOM or SimpleXML 
APIs or a 3rd party like QueryPath or whatever floats your boat) and 
print it, just as you would HTML.


Note that you may need to explicitly set headers with header() to make 
sure the desktop app reads it properly.


--Larry Garfield

On 3/4/11 5:48 PM, Ken Watkins wrote:

Hi All.

I have a Windows desktop app that I created using Visual Foxpro (a database 
app).
I want to write a PHP script that I will call from my desktop app. The script 
will simply
query a MySQL database on my web server and return the recordset to the desktop 
app.

My question is simply this: What is the preferred method for passing this 
recordset back
to the desktop app? I'm assuming that there's no reasonable way to send a 
recordset back
without converting it to an array or XML or an object or something? How do I 
return the
data in the recordset to the desktop app?

Thanks for your advice.
Ken Watkins




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php