Guessing game

[David Bovill]

Actually the use case was different. More of a generic way with nice syntax
to call remote functions. This is easier now with dispatch but still not
quite as elegant IMO as using virtual properties of models.

Let’s take an example that I currently use. Note that the rational here is
to avoid where possible using libraries with potential name clashes in a
global space, while retaining elegant syntax and a clear mental (visual)
model.

Requirements: to be able to get and set data on an arbitrary number if
project specific user contributed models.

Second requirement:  to also be able to filter and search the data with
minimal syntax.

Solution: rather than calling / evaluating functions in the context of
their particular project which is hard syntax to remember and not easy to
read - define the following:

getprop project_Data
  -- fetch some data drom a suitable data source linked to the current
context
  return projectArray
end getprop

setprop project_Data someArray
  -- fetch some data drom a suitable data source linked to the current
context
  return projectJson
end getprop


That works fine, and you can make it more useable by defining a single
generic library to access stored arrays in a suitably defined place in the
project.

However you want to be able to filter and search the data, returning for
instance only particular fields. Rather than defining lots of separate
handlers it is useful an elegant to extend the virtual properties as
follows:

getprop project_Data [someKey]]
  -- fetch some data drom a suitable data source linked to the current
context
  return projectArray
end getprop


What would be nice is to be able to use the full power of native arrays in
this syntax, as you could then use it to not only return top level keyed
arrays but nested structures and other types of query. For a function you
would just add another parameter for that. you can;t do that with virtual
props - so you need to leverage the power of arrays.

That's one example of why i'd like to enable that functionality - and make
arrays a bit more complete :)


On Tue, 3 Apr 2018 at 11:07, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2018-04-03 11:35, David Bovill via use-livecode wrote:
> > True - I’d rather be first-class than complete anyway.
>
> To use a more concrete analogy - all British citizens are (since
> suffrage!) 'first-class' in the sense they can vote, but are not
> 'complete' in the sense that there exist things which some citizens are
> allowed to do, which others are not.
>
> > And yes thanks for suggested way around incompleteness. I still
> > suffered
> > culture shock. The use-case I had was to replace send syntax with the
> > more
> > elegant set the ... of object to syntax. I found myself wanting a bit
> > more
> > power ...
>
> That's a slightly different thing - I'd suggest that even your proposed
> 'more elegant' solution is actually probably much less readable than
> using 'send' in the long run as, if I read that line it isn't entirely
> clear what it is intending to do...
>
> So, I'm guessing what you really want to be able to do is:
>
>    set the textColor of chunk tChunk of tMyObject to light-grey for each
> tChunk in spellingArray
>
> Or (with slightly less use of non-existant syntax):
>
>    set the textColor of each element of spellingArray to light-grey
>
> Where 'spellingArray' is a numeric list of chunk references. Which would
> be the same as:
>
>    repeat for each element tMisspeltWordsChunk in spellingArray
>      set the textColor of tMisspeltWordChunk to "light gray"
>    end repeat
>
> Which does actually work now - as you can have things like "char 1 to 20
> of field 1" in a variable, which will be parsed at runtime when its the
> target of a set command.
>
> > Power is not always a good thing. I’m glad that the dignity of arrays
> > has
> > been restored.
>
> Power and syntax are intimately related - in the sense that how we
> encode what we want to do as syntax will give us power in some ways,
> whilst removing it in others (the only way for that to not be the case
> is to make the syntax more verbose and more difficult to write - think
> machine code vs. LiveCode Script).
>
> The above is actually a very good example of this as you *can* actually
> use an array as an index outside of setProps, it just means something
> perhaps much more useful...
>
> i.e.
>    put "foo" into tPath[1]
>    put "bar" into tPath[2]
>    put tArray[tPath] into tBarOfFooOfArray
>
> Numerically keyed arrays starting from 1 can be used as an array index,
> in which case they are considered to be a sequence of keys to follow.
> The above is the same as:
>
>    put tArray["foo"]["bar"] into tBarOfFooOfArray
>
> To put it another way, as it stands, the use of arrays as indexes in
> arrays has been chosen to mean something which is (to be fair) a *great
> deal* more useful than array-valued keys - as it makes array paths (i.e.
> sequence of keys) first-class in the language.
>
> (Also, all uses of array-valued keys anywhere can be transformed to code
> which derives a canonical name from an array before being used as a key
> - which is probably something you should be doing anyway directly were
> you to ever think you have a need for such, otherwise it masks what the
> code is *actually* doing, as well as probably causing you horrendous
> performance problems for cases you have not foreseen and will occur!).
>
> Of course, what you wanted (I presume) is a more succinct way to set a
> property of a collection of chunks to a single value - i.e. one which
> takes one line, rather than 3 - which isn't really anything to do with
> array-valued array keys at all - and more syntactic sugar for what other
> languages would call 'list comprehension' I guess.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode