> "Earnie Boyd" <earnie@...>; 2005-02-17@... GMT-5
> Let's see where you go with it. Start simple. Expand the simple.
There's some main points I am still working on. Most of it is probably
"intermediate" to "advanced" PHP programming concepts. I think I left
"simple" when I said "hey let's make this an object". ;-) Some things
are new to me and some were always difficult for me. Any pointers (or
resources) welcome, but I think given some time and Google I should be
able to figure it out.
1) Division of data and labor in objects.
For data, I start by putting the variable where I need it at the
moment, and move it around if other objects will need to use it.
For labor, I start of with some procedural stuff inside a function
or multiple functions. If I notice that I do something 2+ times, I make
a method out of it.
For methods and data, if I need them in more than one class, then I
either move to a parent class and let it be inherited, or move to a
separate class and create an instance.
This is perhaps always the most difficult for me to figure out and
takes the longest to get right.
2) PHP's limited object syntax quandries.
I'm not entirely sure of the implications of the syntax regarding
objects and performance. Will it even parse? Can I do X or Y? How?
3) I've taken a "Turing" approach to parsing the file.
File is one large string. Seek "marker" strings, set offsets,
denote "start" and "end" markers, and pluck the value in between, repeat
as needed. My main problem is where to put the string, in the object
that fetches the source, or the object that handles file seeking
operations, or available to both?
4) Parsing process is abstracted to list of strings.
The power of this "Turing" approach will be that parsing becomes
only a matter of specifying these markers, and can be stored externally
in a config file. If the parsing syntax changes, only the config file
needs changing. (At least I hope it's that simple.) So far I'm only at
the point of using hard-coded lists of marker strings, but have the
generic seek functions, so it's a small conceptual leap to a config
5) Juggling arround parameters: argument lists and return values.
With pre-markers, start marker, end marker, and post markers as
arguments and status, parsed value, and error messages being desired
return values, I need more power. So far I've used only scalar strings
or array of strings (or mixed) for marker arguments (variable length).
It's tedious and feels rickety, easily breakable, somehow sloppy, and
inflexible, and worst an inelegant offense to my sensibilities. :-D
I'll probably change to using arrays (sometimes arrays of mixed strings
and arrays) both ways for maximum effect. Hopefully facilitate error
messages for debugging.
6) Consistent, accurate and descriptive object, method and property
'My name is teh suck.' :D
API usage (objects, methods, properties), and _private methods and
variables, all need some explanation. It'd be nice if I knew how to
autogenerate docs from the code with PHP, as with perldoc or javadoc.
Anyways this step might help defining and refining what I'm trying to
do, so I should probably do that first, but I avoid it when I am
inspired with other ideas and energy to get them working. ;-)
8) Classes so far.
For lack of a better name, I'm calling this the "FileReleaseSystem"
or "FRS" for short. A more corrent name might be the
"SourceForgeFileReleaseSystem", but it's a mouth full, and SFFRS is
weird looking. Anyways.
FRS_Source - retrieve the html file from web server, or local backup
copy (cache), if remote retrieval methods (php fopen url, wget, curl,
etc.) are unavailable or the server fails (down, overloaded, SF's MySQL
breaks or overloaded). Store file contens in single string.
FRS_File - store file contents in a string and handle seek
FRS_Parse - handle specific combinations of pre-markers,
start-marker, end-marker, and post markers, plucking values from in
between start and end markers, looping until end of file, store data
FRS_Data - store the data: category name, release name, package
(file name, file size, file date, file type)
FRS_Download - (child of FRS_Source) with url, file and parsing
specific to the current SF download page.
FRS_Project - (child of FRS_Source) with url, file and parsing
specific the current SF project page.
FRS_Bedug - This is what happens a lot when you're somewhat
slydexic, so helps with beduggnig odce. ;-)
9) Breaking classes into separate files.
This beast is growing rapidly at over 500 lines and not even half
10) "Chunking" methods for otimal runtime loading.
A further refinement of breaking entire classes into separate files.
Put methods into separate files and include them only if the object
needs the method. Should yield cleaner class code and use less memory
in the long term. We'll see if it's effective or not. Should make it
possible to eliminate the FRS_Download and FRS_Project, and instead
implement as FRS_Source, merely specifying a type ("project" or
"download"), url, optional reteival method (fallbacks in order of
preference), optional local file names. It would be a much cleaner and
more easily expandable way of classifying sources, maybe even help it
become a config file option!
11) Free memory.
Manual variable or object unsetting as needed, to avoid leaks.
12) "Pure method" versus "functional" method invocation.
Sometimes I want to put junk into an array and pass as an argument
(the marker soup), rather than make multiple calls to set this or set
that. The same goes true for instantiation. I hate specifying
Class->setThis("value1") ... Class->setThis("value5") after a "new". I
prefer to do it all at once. I think PHP allows this with "new Class(
args )", but if not, at least with a custom "init()" method. Currently
I'm doing the pure method calls when using the API, but function
internally. It will fully support either way, for those who like
typing. The functional instantiation will merely call the methods
anyways based on what is passed.