Jenk

That's lots of back pedaling from what you said here:

er.. what? Having PHP generate valid, semantic (X)HTML for you would be the ideal framework. Not in my opinion. This would tie the bussiness logic to the output, not good. A better approuch is the tried and tested MVC. Where your output is seperate from your logic. I guess you don't fully understand MVC, or OOP. It is very easily possible to have an object for generating (X)HTML, completely separate from your model. Using flash instead would be of non-issue, if you have separated model from view. Separating does not incur use of different languages. How do you get values from PHP to HTML pages, without using PHP to at least parse template files? Instead of: <a href="<?php echo $link ?>"><?php echo $title ?></a> why not: $html->createAnchor($link, $title); when the create anchor method looks like: public function createAnchor ($link, $title) { $this->_output .= '<a href="' . $this->_escape($link) . '">' . $this->_escape($title) . '</a>'; } ?

er.. what? Having PHP generate valid, semantic (X)HTML for you would be the ideal framework.

That is misleading information. Semantically, you should free the result set when you have finished with it. It is not essential, however. P.S. if my site has over 1000 hits an hour, there will be a noticeable increase in performance when the memory is freed from every result set as soon as possible, compared to leaving the Zend engine to do it for me.

It's called cascading. Depending on circumstance, it can be much more beneficial than to create variables that will only be used once. $object->should()->be()->equal()->to(1); as an example. Another example I use frequently: $reflect = new ReflectionClass($this); $parent = $reflect->getParentClass->getConstructor()->getName(); $this->$parent();

Controller - controls the application, decides what runs. Model - does the "work" is what fetches data, performs calculations, etc. View - Displays the output.

You have a very blinkered view, if all you want is advice/opinions that agree with yours. If all everyone did is offer "positive" feedback to every idea; we'd get flooded with garbage (if there isn't enough already.) P.S. I'd be willing to bet you'd not need write a framework for Java; there will be one already in existance and will have better support than any PHP framework.

Best of luck, but personally I think this is case of letting your favourite language dictate your direction, rather than letting the needs of the business/technology dictate your direction. A good developer does not depend on a particular language. Yeah, ok we all have our favourites, but we can all apply our knowledge to other languages. PHP is not designed for running daemon's. It never has been, and is not looking likely in the future. It may have socket functionality, but even then they can/can't be argued that it was intended for daemon use. There are several other platforms/languages available which are much, much more suited to this type of scenario, and any experienced developer can pick up another language within a few days.

Java has no memory management, it is all automated. In any daemon type application, there will always be a level of scope that will permanently exist - it is within this scope you must null pointers to redundant objects Especially in PHP, where everything will be running in a while(true) loop. Also, PHP's garbage collection runs soley on reference pointer counting; i.e. it won't be collected until all reference pointers have been cleared (either out of scope as you say, or reassigned)

You asked for drawbacks.. and one of those drawbacks is that PHP is not designed for it. (Earlier mistake in mentioning that it is; wasn't meant to include it within the C/Java/Smalltalk/etc list.) The object model in PHP is not efficient at sustained activity. I'm not sure what benefits it would have, I would post that it allows use of the familiar PHP syntax to PHP developers, but the differences in syntax between Java/C and PHP are minimal, and even against a different paradigm such as Smalltalk or Lisp it would be negligible learning curve to experienced developers. However, for existing projects, this would pose a siginificant amount of refactoring - firstly, you'd need to ensure all objects are nulled to ensure garabage collecting (simply $object = null; when finished with it of course) and other trivial changes. If your applications use singletons, you're more than likely going to have to refactor those to use session identifiers; unless you decide to not use singletons, or haven't in the first place. And for the record, C was conjured to run persistent applications - it's what OS's are made of after all.

I wouldn't use PHP to do it, no point, it's not designed for that, and it certainly will not perform better than PHP/C/Smalltalk/etc. which have been doing it for years.

This is how Java is meant to be used - as a daemon. As for mem issues, just remember to nullify pointers to any redundant objects and Java's own garbage collection will clean up.

You're using php to stream to java? Why not just use jsp as that is it's purpose?

this is essentially th crux of application design. "Do you really, really need every object on overy request?" is thet question you are asking, alongside every other developer asking the same question about his or her application. Implement autoload to leviate the worry of "should I include?" for starters, then move on to actual design practice and examine your application logic. Are you instantiating objects "just in case" ? Do you really need multiple instances of ClassA object? etc. Often there are 100's of objects, dozens of classes, in use at anytime in applications.

include_once() ?

Something interesting that was brought to my attention recently. If you're using a constant salt, any two users with the same password will have the same password hash stored in the database. This means if anyone were to get access to your database, they could see if any users have the same password as an account with a known password. It's a small security concern, but valid. A solution to this was to assign a randomly generated salt to each user. This could be stored in a field in the user table in the clear. If someone were to gain access to the user table, they would have no way of matching up accounts with the same password, unless they were to know your particular salting scheme. Quite, which is the very reasons salt's were introduced.

Did you even know http://www.php.net exists?

Depends - if you have an accessor of $this->registry()/$this->registry in your model, it's better than Registry::instance();. Often this is not the case in PHP as objects which are multi-level extensions are slow, but it other languages this is a much better scenario to achieve.

Singletons are globals. Globals are bad. In my opinion, there isn't a single situation within PHP where a singleton is worthy.

You appear to be mistaken for the purpose of a salt. This would be a salted password: $pass = 'apple'; $salt = 'abc123'; $md5 = md5($salt . $pass . $salt); The salt would never be revealed to anyone, and is kept constant. This is so that: $pass = $_POST['password']; $salt = 'abc123'; $query = "SELECT * FROM `users` WHERE `password` = '" . md5($salt . $pass . $salt) . "'"; I do like your idea, but it would be either difficult for you to manage, or easy for someone else to crack. Especially when they realise it is of non-compliant length to any known algorithms.

Possibly with Reflection, but it won't be as "easy"

Time to play pedant again. That will throw exceptions; thus ensuring your code is actually broken; and only works for boolean instances, leaving you open to false passes. The Ternary operator is simply a shortcut "if (expression) {value if true} else {value if false}".. "expression ? value if true : value if false". Shorter? Yes. Readable? Debatable. Your other example is not unique to JavaScript, and JavaScript is just about the ugliest POS language ever to exist. Of course this is opinions, and no one can prove otherwise to the other so no point arguing over it, but - Have you never wondered why you must implement something as nasty as var xml = new XMLHttpRequest() || new ActiveXObject('Microsoft.XMLHTTP'); ? Answer: Because JavaScript is the least consistent language across browsers. Even CSS is more consistent than JS.

Static funcs ftl! What if you want a different connection, with different parameters?

That's fine, it's clarified what I was asking above. The design flaw I was hinting at would have been if you were using the object properties as default values, but never modifying them, just to maintain a "pretty" code layout. In that case, either what you have will be fine, but to be utterly semantic about it explicitly check for a null value: public function something ($var = null) { if (is_null($var)) $var = $this->foo; //do something with $var } P.S. completely off topic.. but I have to ask, what is that above your (someone elses?) shoulder in your avatar?

I can see what you are attempting, but do you actually update the class variables at any point, or only in the definition? This is aching of a potential design flaw; depending on the above.