NYCPHP Meetup

[Kenneth Downs]

Phil Duffy wrote:
>
> I am sorry if this question appears to be off-topic, but perhaps 
> someone can refer me to the correct forum.
>
I hope you can come by and see the Andromeda presentation on Tuesday, 
because Andromeda is my answer to the questions you raise. 

Some of the answers I have come to lead me to call Andromeda the 
"un-framework", because the aim is very different from the MVC 
frameworks out there, in that I'm trying to preserve assets across 
architecture changes, and OO does not seem to be the way to do it, IMHO.

> Now that PHP 5 is truly object-oriented, I find it to be the most 
> powerful of the languages with which I am familiar.  n?
>
But be careful here.  PHP 5 is subject to the Iron Law of Programming 
Languages: This Too Shall Pass.  Therefore, the answer to a changing 
world architecture cannot be found in a language, because languages have 
a tendency to become powerful when there platform is growing, and to 
become weak as their platform wanes (Cobol for timeshare, visual foxpro 
for LAN, VB for C/S...)

To preserve assets in a form that can be usable by any language on any 
platform requires that they be stored in a form that is easily 
transmutable, and this so happens to be data.  If your crucial business 
rules are stored in data, so that code can be generated, you have made a 
huge practical leap not just towards platform-independence, but towards 
architecture-independence.

> Applications that depend heavily upon related records require that 
> users perform all kinds of browses.  Under those circumstances, 
> managing communication among objects becomes a nightmare because it 
> requires the application programmer to predict communication paths to 
> objects and manually handle session variables that are not task-scoped 
> (they are by definition, session-scoped).  It appears to me that there 
> is a role for session variables, but it is not the task.
>
This results when the application is designed around coding principles 
and the database is expected to conform.  Databases and programs have 
very different purposes and follow very different rules for virtuous design.

Experience with customers leads to the conclusion that the guys who sign 
the checks pay for valid data, not UIs (the UI is important and is 
expected to work, but the database is what gets the attention).  This 
becomes more true the larger the company.  Therefore it seems only 
practical to design a framework based on the need to maintain valid 
data.   I'll skip the detail on this point because that will be the main 
substance of the presentation on Tuesday.

If you follow this line of reasoning, you end up concentrating first on 
getting the database specification to be complete and correct.  Once 
this is done, the browser layer tends to come next in importance because 
of its role in user acceptance and productivity.  This leaves to last, 
surprisingly, the PHP layer, serving as "mere" glue between the browser 
and the database.   Because most frameworks begin with trying to 
establish coding practices for the PHP layer, which we can see here as 
being the least important, it is no surprise that they end up looking 
like a "force-fit" in the big picture.

> While many programmers have reservations about the need for these 
> disciplines, it has been my experience that they become increasingly 
> important as the size and complexity of an application system increases.
>
My experience is that *some* sort of method is required, but that 
programming discipline is not the silver bullet, which is why I looked 
elsewhere and developed Andromeda, which is more about getting a 
complete database specification and implementing it with as little 
effort as possible.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061018/83d17ef7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ken.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20061018/83d17ef7/attachment.vcf>