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