Smoking toooooo much PHP

It's kind of fun watching the reactions to the GOTO proposal for PHP, most negative reactions appear to be comming from people who have not actually read the code, kind of like a knee jerk reaction to flamebait.

Sara's Patch introduces localized GOTO's, eg. only within the current function / method scope. (although theoretically you can jump around within the global scope, you cant jump to it from inside a function/method.)

So if you read and understand the historical reasoning against GOTO's you quickly realize that GOTO's only really cause spagetti code when used wildy in really large blocks of code.

The reality is that as most programmers know, large methods and functions often are either an indication that the codes not that good anyway (eg. it should have been broken up into smaller components), so the addition of GOTO's is not going to make a pile of shit smell much worse..

While I dont think the original joke about adding it and not documenting it will fly, I do hope that it is modified to prevent usage in the global scope.

Seeing mention of XML_XUL, the PEAR package on a few blogs and in PHPMag, I thought it might be worth mentioning that I did evaluate using it for a project a while back. At that point, the code was not mature. However, It was already clear that the concept behind it is pretty flawed.

XML_XUL, offers a couple ways of working
a) Read a XUL file, convert it into Big tree of XUL Elements, Manipulate it, then render it.
b) Start from scratch, building the whole tree manually PHP, and render


Both of these have huge memory issues, a) has performance issues of often needless requiring the parsing of XML. b) has a fatal flaw in that it totally obliterates the potential to wysiwyg edit the application.

In the end concluded that using the Flexy engine, was far more efficient, as we could prototype the look and feel (and easily make major changes late in the design process) without having to mess around with the code to much. (It's also mindblowingly faster).

It did not however go without having to make a few additions to Flexy.
a) allowing "<html:input" with Flexy's Element parser (so we could do file upload in XUL)
b) using id="this_is_a_tag" and being able to compiler and render parts of a file using the id tags: $flexy->compile("template.xul#this_is_a_tag);
c) Quite a few XML parsing additions to the Tokenizer (<?xml-stylesheet....)

While XML_XUL remains cute (and may even provide a reasonable way to add XUL elements to a Flexy Template) , I do ponder if just the ability to use the PHP DOM extension along with Flexy may be far more powerful, and doesnt involve learning a whole load of API's. - Time which is far better spent learning Javascript/W3C/PHP DOM (which are all pretty much identical).