James G Smith wrote:
[snip]
>>My first thought is to break the API up so that there is a module per
>>API call (there are some 70 calls in the API). My reasoning is that I
>>can modify existing calls and add new ones without affecting everything
>>else. Does this make sense or is it better to have the API as one large
>>program as I have it now?
>>
>
>If it's an API, I'd not make one module per function, if by function you mean
>a call (e.g., fork() is a function in the Unix kernel API). Instead, I'd
>group them by functionality (as in OS/2 - VIO, KBD, DOS, ...). So one module
>might handle customer accounts, another handle news items, etc.
>
What advantages do I gain by grouping the functions based on
functionality? As per my response to Mr. Worrall, one of my concerns
with placing each function call into its own module is the amount of
memory used by the various .pm files that will be loaded numerous times.
I can see that grouping functions based on functionality would reduce
the number of .pm files in memory. However, if I go that route, then
would I not be better just to leave the API as one file?
Thanks,
Shawn
--
This communication is intended to be received by the individual or
entity to whom or to which it is addressed and it contains information
that is privileged, confidential and subject to copyright of
Recognia Inc. Any unauthorized use, copying, review or
disclosure is prohibited. If received in error, please contact me by
phone at 613-623-6159 or by email at mailto:[EMAIL PROTECTED].
