NYCPHP Meetup

[charles at softwareprototypes.com]

Hi people,

while I was talking with the grand-poobah of Community Connect at the
Job Fair last Thursday (never heard from 'em, [don't expect to,
{tough shit, I'm becoming a Dog Groomer, < B.S. & > $,}]) about
object orientation, he made a couple of comments which, with my usual
"esprit d'escalier" didn't get around to retorting until after we'd
all gone out the door.

First:

The problem with loading an object class is that people don't know
how to break up a class to save their gonads and keep trying to
define a class as a single file which results in a lot of unused code
being loaded and inter-piled uselessly.

Ever thought of breaking up the code into one __directory__ per class
containing one file for the static object definition (the Class and
instance variables that all the methods will depend on,) and one file
per method with an "IncludeOnce" pragma of the static definition?
(Sorry if I'm showing my "Ada" but I learned about Pragmas reading
the DND "Green Book.")

When I was working for the CGI Group on the Common Departmental
Financial System for Supply and Services Canada, I had to write a CM
system to track every friggin' component (ConfigurationItem,) all the
specs, APIs, window layouts, Netron CAP COBOL code fragments, test
scripts, environment pathes, migration strategies, piece of hardware,
software, chair & desk and human resource spread across 3,849,674
square miles (9,970,610 square km), of which 291,576 square miles
(755,180 square km) are inland water. Now there's a sparse Set for
you. :-)  

You can then create "load sets" which include "IncludeOnce" pragmas
for only the methods you will actually be using. That means that you
can keep the foot print "lean and mean" by including the "load set"
instead of loading the whole class.

This would take care of 99% of the objections to the ridiculously
broad foot print that Smalltalk and Java source code (mis-)management
have.

Next:

Paths are great and should be used to full advantage. You should also
use your NFS machines/servers to the fullest. You should use your DNS
to implement subdomains for development and test and have ONE box for
running test & QA and ONE box for development. These can even be
re-using the same box in addition to the induvudual developper's
boxes.

Production machines/servers ONLY know production paths. They execute
code, access data bases and serve pages from/in the production
environment. They are "www." boxen. 

Test machines/servers know about test paths AND production paths.
They execute code, access data bases and serve pages from/in the
production environment AND the test environment. They are "tst."
subdomain boxen.

Development machines/servers know about test paths AND production
paths. They execute code, access data bases and serve pages from/in
the production environment AND the test environment AND the
development environment. They are "dev." subdomain boxen.

Individual developer's boxes know about development paths AND test
paths AND production paths. They execute code, access data bases and
serve pages from/in the production environment AND the test
environment AND the development environment and their own box. They
are "<developper>." subdomain boxen.

Last:

Just because the code has to be attached to the object that's
actually involved doesn't mean that it doesn't require and can't
intermingle execution with code from other objects. Some objects are
ONLY there to provide services (like StateMachines, StateEngines,
DialogManagers, etc.)

The same principles of optimization still apply: 
1) Don't execute any instructions or allocate any storage you don't
absolutely need to. (Make it fast) (This is the WORST offender and a
measure of how lousy programmers are at designing efficient
algorithms. M$ Windows makes me weep. At least the Mac only let you
fill a TERec (TextEditing pane model object) with a maximum of 4K
Bytes. Windows would acept megabytes of data even though it could
only show one or two K of it. What a waste of time. Bill Gates owes
me HOURS!) 
2) Never execute any code twice when you can cache the result. (Make
it faster) 
3) Never cache a result you won't reuse. (Make it smaller.)

-Charles-A. 

Got a dog you need clipped? 

Let it get shaggier until I've finished my course in August.