Getting the Last Modified Date of a file

[Richard Gaskin]

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