Re: [Oorexx-devel] Ad making .StringTable a drop-in replacement for .Directory

[Gil B. <gba...@al...>]

On 11/18/2015 1:24 PM, Rony G. Flatscher wrote:
> Experimenting a bit further with 5.0alpha looking into the new 
> .StringTable which should supercede/replace the .Directory class as it 
> is faster than .Directory (by removing the feature to have methods 
> generate a return value upon lookup).
>
> Running the following experiment:
>
>     F:\download\Rexx\ooRexx\alpha500\work\bin_small>rexx rexxtry.rex
>     REXX-ooRexx_5.0.0(MT)_32-bit 6.05 4 Nov 2015
>        rexxtry.rex lets you interactively try REXX statements.
>          Each string is executed when you hit Enter.
>          Enter 'call tell' for a description of the features.
>        Go on - try a few...            Enter 'exit' to end.
>     say .stringtable
>     The StringTable class
>        ........................................... rexxtry.rex on WindowsNT
>     say .stringtable~isa(.directory)
>     0
>        ........................................... rexxtry.rex on WindowsNT
>     do i over .stringtable~superclasses;say i;end
>     The Object class
>     The MapCollection class
>        ........................................... rexxtry.rex on WindowsNT
>     do i over .directory~superclasses;say i;end
>     The Object class
>     The MapCollection class
>        ........................................... rexxtry.rex on WindowsNT
>     say .local .local~class
>     The Local Directory The Directory class
>        ........................................... rexxtry.rex on WindowsNT
>
> It would be nice, if .local and .environment and other Directory 
> objects in existing code could get replaced by StringTable instances 
> to benefit from its better performance.
>
> In order to allow .StringTable as a drop-in replacement for .Directory 
> it would only be necessary to make .StringTable a subclass of 
> .Directory (the speciality of .StringTable would be to remove a 
> particular lookup feature, if I understood the explanations by Rick 
> correctly). This way existing code would be able to get gradually 
> enhanced by replacing .Directory objects by .StringTable objects (even 
> in native code that might test whether an object is a .Directory).
>
> Would that make sense?
>
> ---rony
A recent post by Ruurd about the "Decorator" design pattern got me to do 
some reading about OO design patterns and principles.  While I'm still 
working my way through it all, I did find an interesting principle that 
I believe applies here.  It is call the LSP (Liskov Substitution 
Principle) and it states that "subtypes must be substitutable for their 
base types".  The way I understand it, creating a subclass that removes 
functionality of its superclass is not good design practice.  So your 
suggestion to have .StringTable be a subclass of .Directory would 
violate the LSP.  However, reversing that relationship - .Directory as a 
subclass of .StringTable - would be OK.

Now, that does not allow for testing for isA(.Directory) to work with 
.StringTable objects w/o modification but the code needs to be changed 
to create the object as a .StringTable anyway so I don't see that as a 
big drawback.

On your other suggestion - to change .local and .environment to 
instances of .StringTable - I'm afraid I don't agree.  While most 
programs, I would guess, only use the methods of those .Directory 
objects that are also methods of .StringTable, there may be cases that 
depend on the "other" methods which would then break if this change were 
made.

> -- 
> Gil Barmwater