Well, I've partly answered my own question There are some serious issues
with having a method context return anything other than a string value, so
trying to name this .nil won't really work. Perhaps we should use an
unusual string name like "*UNNAMED*" that will highlight that something
unusual occurred. I really, really don't expect this is going to ever be a
problem, but the behavior still needs to be well defined.
Rick
On Sat, Oct 11, 2014 at 4:14 PM, Rick McGuire <[email protected]> wrote:
> I've been trying to improve the test coverage of some of the classes and
> am currently working on tests for Object. At the moment, I'm writing some
> tests for the RUN() method.
>
> The RUN method is a private method that allows a method object to be run
> dynamically on an object instance. Since this is a private method, it can
> only be issued from within another method of the target object, so you
> would usually see it issued as
>
> self~run("return somevalue")
>
> This is not much used, but as I was writing the unit tests for this the
> question arose as what this method's name is. The code itself is actually
> running this using a name of "NONE" as a placeholder. Which works, but
> there are a few places where this placeholder name shows through. For
> example, .context~name from within a run method will show "NONE". The
> stackframe object for that method will also show a name of NONE. And the
> part that I think bothers me the most, the FORWARD instruction will also
> use the NONE name if the method uses FORWARD.
>
> Is this an appropriate name? I'm thinking of trying to make this
> placeholder be .nil and have the FORWARD instruction raise an error if it
> tries to use that name. I think this is doable, but I hope I can root out
> all of the places where this special case might show through.
>
> Whatever we decide to do here, I think that decision needs to be both
> documented and included in the tests.
>
> Rick
>
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
