Programming project

[Matthew Tuck]

Guide for the perplexed:

OOPL/OOD/OOA = Object Oriented Programming language/Design/Analysis
SPL/SD/SA = Structured etc.

Tanton Gibbs wrote:

> Just for the record, I like closed form construction.  I think it is 
> neater and more readable than open form.

Well, you dislike the Perl forms below for the sake of redundancy, but
do you think they're more readable than using the full closed form
construction?

>> My real qualm with the way this is done in Ada (and in Perl?), is that
>> the "exit if" form is only for the exit statement.  WHY?  

> I don't know about Ada, but I know Perl allows if, unless, while, and 
> one other modifier after any simple statment.  so, you could say:
> X if( Y );
> Z while( A );
> B unless( C );
>
> I'm not really fond of this, because there are already structures that 
> do this same thing, but it is more like the english language and I can 
> see some( if little ) advantage in allowing it.

Well certainly suggested shorthands will have to be catalogued and
decided upon individually.

> I meant the design and analysis of systems based on the object 
> oriented approach was still under development, not the language concepts 
> themselves.  The waterfall method, etc... of structured programming, 
> however, has been around long enough to be practical and easy to follow 
> where as many of the prototyping/rapid prototyping systems of OOP are 
> relatively new and many programmers are scared/unaccustomed to them.

I think "complete" is still misleading here.  Anything can be done in
OOD just as it can in SD.  It may not map quite as easily, but it can be
done.

Now, it could be harder to do, so the question is what about OOPLs that
makes them more difficult to write programs design with SD in.  The
class is an adequate module (given language support for singular
objects), and free methods allow you to go around them.  As far as I can
see, the only problem is you still have to deal with OO libraries, but
I've never found that a problem.  When I was making the transition from
SD to OOD thinking, I found they intermixed rather easily.

> I don't mind importing submodules, but I think that at the end, the
> functions that are used, along with the data they use should be
> extracted to a common obj file that will greatly reduce compiled size.
> In other words, if the function is not used, its compiled code is not
> included.  I realize this may be a pipe dream, but it is worth a shot.

Of course.  I was complaining about the lack of inter-class
optimisations at an earlier stage I believe.  That is necessary to
enable this sort of stuff.  The major problem is this makes fragile
program elements (that have to be recompiled when the context changes)
but this could be a compiler option.

>> I've talked about free methods, but are there any other way you think
>> OOP restrictions you?

> Well, the design considerations of the OOP paridigm are completely 
> different, and one does not easily go from one to the other.  Although 
> it may not sound like it, I'm a big fan of the OOP paradigm and I write 
> most of my programs in an OO fashion, but when someone hands me an 
> iterative document sheet, then I usually can write the program 
> structurally faster than I can redisign the project in an OO fashion and 
> then code it.  Sometimes, speed outweighs quality.

You've merely said you code in a structural fashion here.  You haven't
given a reason you can't code structurally in an OOPL.

>> Thirdly, that value (1 in the previous case), might not be 
>> statically

> ...etc...I'll address this issue in another letter.  C++ does it by 
> using binders...I'll research that solution more.

I haven't heard of this before.  Is this a language feature?

>> "I think a true class is overkill in this situation" reflects you are
>> worried about one of two things.
>>
>> (a) The syntactic inefficiency of class definition.  You can use the
>> free method shorthand.
>> (b) The inefficiency of class implementation.  All of this can be
>> optimised out if unnecessary, and should already be happening in modern
>> OOP compilers!  Not just in this situation, but all situations where
>> classes are being used.  Pity it's not to my knowledge.

> I am worried about a, but I don't necessarily want a shorthand, if I 
> want a free method, then all I want to think about is defining a free 
> method, not a shorthand notation.

That's not the point.  A free method shorthand works exactly the same as
the free methods you're used to.  If you don't want to inherit from it
you don't have to.

> A namespace is just a collection of objects in a newly declared scope, 
> thereby not cluttering the global namespace.  They are very similar if 
> not exactly like singular objects.

Certainly sounds like one to me.

>> Actually, no.
>>
>> The string interface doesn't have an implementation.  The interface is
>> implemented as an abstract class and the implementations as concrete
>> classes, but they are not shown that way to the programmer.  There are
>> two ways of viewing this sort of scheme - what I think you're referring
>> to here, having a class B where implementation conversions go A->B->C,
>> or going directly A->C.  This is done with the "Builder" design 
>> pattern.

> I'm just wondering how the string class is finally implemented, using an 
> array of characters, or what?  Whatever the final implementation is, 
> then we should support it as a kind of string too.

There is no standard implementation, but as to how we implement this in
the language library, I believe several compiler supplied
implementations are appropriate.

>> The alternative is to place this information in the class itself.  Now
>> I'll admit that placing a preferred implementation in a class (which,
>> remember is abstract), before the implementation is even declared is 
>> not perfect, but it seems to me to be the best idea.

> I agree, the idea of placing a preferred implementation in the interface 
> is a good idea.  It is almost like a default template in C++.
> for example
> template< class T = int >
> class Stack{ ... };

> Thereby making a stack class that will normally use ints, but can be 
> changed to use anything.  The interface could be used much the same way
> class String( Abstract, default = StaticString )
> { ... };

I hadn't noticed the analogy between these before but it certainly seems
to have a little similarity.  My system, however is using a program
element which has not been declared yet, while when you declare a class
like that the classes which are your parameters are usually already
declared.

>> This of course means that profiling could be potentially misleading -
>> it must always be done with the final build options on.

> In fact, this is what is spawning a new generation of compilers/profilers
> that do runtime optimizations based on program runs.

Indeed, I have always found this an attractive proposition.  The
question of course is how you obtain the data.  It would probably have
to be obtained in extensive real use (as a short period could be
misleading) over a lot of users (or the type you want to optimise for) I
guess.

>> I'm not too familiar with the triple/quad representations.  I know what
>> they are, but how do they compare to ASTs in terms of ease of use in
>> discovering and performing optimisations?

> They differ in there applicability.  They are more interested in finding 
> memory savings and eliminating temporary variables as well as when to 
> schedule nearby operations( for example, certain operations on the 
> pentium can be paired and should be placed next to each other ).  They 
> are important, yet different from ASTs.

I assume you're referred to pipeline scheduling above.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/