Marek wrote:
How could I find stdlib?
stdLib was originally an experiment to answer a question Andre raised at
the first LiveCode conference: Why don't we make one standard library
that contains the most commonly-used commands and functions we need for
most of our apps?
So Ken Ray and I set about combining some of the handlers from our
common libraries into a new one called stdlb.rev, and posted it at the
Rev Interoperability Group site:
<http://tech.groups.yahoo.com/group/revInterop/>
I've found many initiatives worked on in RIP well worth the cat herding,
esp. the ECMI spec, and I'm about to launch a new discussion there next
week to define a common format for a "project" (the collection of stack
files, externals, etc. that comprise a given app) so all of can make
tools related to project management that work well together.
stdLib, however, was kind of an odd bird, ironically because of its very
usefulness: so much current code depends on such a library that in
practice Ken and I just continue to use our own respective libraries
because they already exist and we already have code that uses them, and
the process of deciding what should not should not be included in this
sort of standard library took a back seat to other priorities.
Moreover, for a library to be truly useful we began to move in a
direction that was less a library than a framework:
A library should ideally contain commands and functions that can be used
independently, so you if something you need is in there you just learn
the params for that one call and use it, and can safely ignore
everything else - almost zero learning curve.
In contrast, a framework consists of a set of related commands and
functions that can provide greater utility than discrete ones, but at
the cost of learning how the parts fit together.
For a few basic things like the file info function posted earlier, a
library can be good.
But once you start moving into areas like functions for handling prefs
files, there's an opportunity to keep the API simple only if you first
set up a few basics.
With prefs, for example, such files need to go into a folder named for
the resevse-domain of the publisher, and have a file name that reflects
the app's name, e.g.:
.../Preferences/com.fourthwold/myapp.prefs
As discrete functions, a setPref and getPref call would require the
developer to pass the reverse-domain and app name as arguments each time
they're used. Messy, and kinda silly since they won't change within a
given app for the duration of the runtime session.
A much smarter approach would be to require the developer to make one
intialization call in their startup sequence, pointing the library to
the stack file in which the rest of the routines in the library could
obtain information for things like that from a common set of properties,
as extensions to the RIP properties (outlined in the ECMI spec at the
RIP site).
With such a setup, it then becomes possible to provide all sorts of
supporting services from a generalized library, but unlike the original
mandate for stdLib it would require the developer to have some
foreknowledge of what the library expects and to add a few properties to
their stacks to support it.
It turns out that Ken and I generally use almost parallel structures for
our apps anyway, so after realizing the limitations of a discrete
library we've turned our attention to defining a new lightweight
framework-like approach with a new project we call "CORE"
(Component-Oriented Runtime Environment).
Parts of CORE date back to my old SuperCard days, and there was a time
when the publishers of SC were considering acquiring it as a way to
facilitate even more rapid development with that tool.
The new CORE is being rewritten for use exclusively in LiveCode,
evolving slowly but steadily into something that may be quite useful in
a few months. It's already included in some of the apps I build, with
new functionality being folded in as needed over time. Once it gets
ironed out into a state that's likely to be stable enough for others to
work with we'll post it to the RIP site; when we'll have time to
document it is a whole other question <g>.
In the meantime, if anyone has time and interest for maintaining a
general-purpose library of discrete commands and functions, stdLib may
still be valuable and could use a steward.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
Follow me on Twitter: http://twitter.com/FourthWorldSys
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
