common code patterns

Sannyasin Brahmanathaswami brahma at hindu.org
Sat Aug 12 19:10:09 EDT 2017


Monte, you request is a bit opaque to me..

but FWIW 

-- to stay away from globals
-- to break up logical "areas of work/services" into separate scripts
-- to be able trace back to the original script  I find myself doing a lot more of this:


I find myself doing a lot of this;

behavior_Listen # parent of the stack "listen"
# which is serving as the controller/model for all things having to do with playlists etc.



on playlist_SetCurrent pList  
   put pList into sTargetPlayList
end playlist_SetCurrent

function playlist_GetCurrent
   return sCurrentPlayListA["playListTitle"]
end playlist_GetCurrent


# so then in this script:

behavior_ListenSelectPlay

# behavior attached to the card in this stack
# which is responsible for all things UI/UX related. i.e the "view manager" if you will

I can at anytime do a kind of "reset" with 

put playlist_GetCurrent() into tPlaylist

This architecture is all a bit new to me but turns out to be very functional and pretty transparent… 

so that "getter setter" thing… is that what you are looking for?

On 8/10/17, 3:50 PM, "use-livecode on behalf of Monte Goulding via use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of use-livecode at lists.runrev.com> wrote:

    Basically anything where you follow a common pattern to do a thing but you can’t abstract away so you don’t have to write the pattern any more.



More information about the Use-livecode mailing list