The product of engine development is both the engine and a reference. Indeed, the value of the engine is mostly in the knowledge of it, that is in the reference. It is from the reference information that the dictionary, tutorials, books and engine help will come. (And where the reference is weak, from experience.) By engine, I mean as seen by those who use it LiveCode.
Much of the engine reference can indeed be embedded in the engine. But, in general, that need not be so. The dictionary summary can even be part of the engine, developers might be required to add a short description of each command and property. But, it is the whole kit, the engine plus reference that matters. In the other direction, the reference might be the dictionary. Perhaps pro forma entries can be made to the dictionary, maybe online, before engine changes are made. People can review that. If information about the engine is shifted from an external reference to the engine, that should be considered in a broad and general sense. It should not, I think at this time, be piecemeal here and there but under some philosophy the minimizes the concepts involved in LiveCode, somehow rich and powerful. This might be an indication that some low level raw view of the engine and of stacks is important. That can be provided by the IDE or plugins. It can be provided by an enhancement of the dictionary. That need not be an engine thing. I like the idea of keeping the pair, engine and reference, very simple. But, simple and rich, I'm not against additions. And I don't mind that some engine information is provided by the engine. However, after thinking about it, I lean toward information being in the reference. A little. I can be swayed. (However, I am fully against a caveat in the reference explaining some corner missing in capability, when it would be as easy to fill in the corner in the engine.) Dar On Jun 14, 2013, at 10:33 PM, Peter Haworth wrote: > I'm sorry to have to post this somewhat angry post. There's a thread on > the engine contributors forum regarding whether it's necessary to return > synonyms from the proposed changes to the propertynames function. SInce > not everyone reads that forum, I'm posting it here. You can read the prior > posts on the forum. > ========================== > OK guys, well I guess I'm disappointed at the closemindedness you're > exhibiting, seems in direct contradiction of "open source". Just because > you can't figure out why someone would want to do something doesn't mean > that someone out there DOES want to do it. Why would you build a brick > wall around something that prevents someone from getting hold of a specific > piece of information that is an inherent part of Livecode? SYnonyms exist, > there should be a way of finding out about them. > > Mark - you're misquoting what I suggested. The key word you omitted is > "optional". I did not insist that synonyms be returned, just that there be > an OPTION to get them. Why does that cause you such a problem? You don't > want them? Then don't request them, simple as that. > > Think about SQL - the entire structure of an SQL database is available to > anyone who wants to discover it. Do you think the implementors thought > "oh, nobody would ever want THAT piece of information?" No, they made > everything available so that anyone who had a need for it could have access > to it. > > So go ahead, implement what YOU think is best, I don't have any more time > to waste on this. > > Pete > lcSQL Software <http://www.lcsql.com> > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
