On Wed, May 2, 2018 at 10:31 AM, Rony G. Flatscher <rony.flatsc...@wu.ac.at>
wrote:
> On 02.05.2018 15:27, Rick McGuire wrote:
>
> No, not really. a ::attribute is just a method that allows access to an
> object variable....which is just a variable like any other, just in a
> different home. You still need the expose instruction to make the magic
> happen.
>
> Thank you! Extended the test example a bit and was able to change the
> variable reference to an attribute from a routine while a guarded method on
> a different thread was sleeping and blocking access to that referenced
> attribute for other methods of its class.
>
> Here the test example's code, highlighting the changes in green:
>
> -- purpose: test whether attributes can be used via variable references as
> well
> -- check concurrent access
>
> o=.test~new("eins", "zwei") -- German
> say "1, o:" o -- show current settings of attributes
> say
> say .dateTime~new "main: before invoking change o~getOneRef..."
> call change o~getOneRef, "un" -- Frenchsay .dateTime~new "main: after
> invoking change o~getOneRef..."
> say "2a, o:" o -- show current settings of attributes
> say
>
> call change o~getTwoRef, "deux" -- French
> say "2b, o:" o -- show current settings of attributes
>
> ::routine change -- use variable reference to change value to point to
> use arg >ref, value
> say .dateTime~new " - change(), a: before sysSleep..."
> call sysSleep .5
> say .dateTime~new " - change(), b: after sleeping, 'ref'=["ref"], before
> assigning supplied value to attribute..."
> ref=value
> say .dateTime~new " - change(), c: after assigning, 'ref'=["ref"]"
> ::class test -- class that defines two attributes
> ::attribute one -- attribute
> ::attribute two -- atribute
>
> ::method init -- initialize attribute values
> expose one two
> use arg one, two
>
> ::method getOneRef -- return reference to attribute
> expose one
> reply >one
> self~delayGuardedAccessAwhile -- continue on another thread that runs a
> guarded method
>
> ::method getTwoRef -- return reference to attribute
> expose two
> return >two
> ::method delayGuardedAccessAwhile -- guarded method
> expose one -- access attribute "one"
> sleepTime=1.567 -- seconds
> say .dateTime~new " a) method 'delayGuardedAccessAwhile': before sleeping,
> exposing 'one'=["one"] sleeping for:" sleeptime
> call sysSleep sleepTime
> say .dateTime~new " b) method 'delayGuardedAccessAwhile': after sleeping,
> exposing 'one'=["one"], about to return..."
>
> ::method string
> expose one two
> return "a" self~class~id"["one","two"]"
>
>
> Here the output, highlighting the sequence where the routine could change
> the attribute's value while a guarded method blocks access for other
> guarded methods of its class:
>
> E:\DropBox\Dropbox\xfer\orx\beta\sandbox_ooRexx\reference\test2>testAttributeAccess2.rex
> 1, o: a TEST[eins,zwei]
>
> 2018-05-02T16:23:13.618000 main: before invoking change
> o~getOneRef...2018-05-02T16:23:13.634000 - change(), a: before
> sysSleep...2018-05-02T16:23:13.634000 a) method 'delayGuardedAccessAwhile':
> before sleeping, exposing 'one'=[eins] sleeping for: 1.567
> 2018-05-02T16:23:14.149000 - change(), b: after sleeping, 'ref'=[eins],
> before assigning supplied value to attribute...
> 2018-05-02T16:23:14.149000 - change(), c: after assigning, 'ref'=[un]
> 2018-05-02T16:23:14.149000 main: after invoking change o~getOneRef...
> 2018-05-02T16:23:15.210000 b) method 'delayGuardedAccessAwhile': after
> sleeping, exposing 'one'=[un], about to return...
> 2a, o: a TEST[un,zwei]
>
> 2018-05-02T16:23:15.210000 - change(), a: before sysSleep...
> 2018-05-02T16:23:15.724000 - change(), b: after sleeping, 'ref'=[zwei],
> before assigning supplied value to attribute...
> 2018-05-02T16:23:15.724000 - change(), c: after assigning, 'ref'=[deux]
> 2b, o: a TEST[un,deux]
>
> The question would be whether this should be just documented or whether
> access via variable reference to attributes should be blocked if a
> concurrently executing method of that class is in guard mode (maybe only if
> the attribute in question is exposed by it).
>
That is not how guards work, your statement about blocking access doesn't
really make much sense. What is really going on here is more akin to what
procedure expose does, but it works across external (and even native) calls
and can also reach across threads.
Rick
>
>
> ---rony
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
