Paul Dupuis wrote:
> Mike,
>
> Even better.
>
> You solution illustrate more so than mine how easy it is to make
> handler and functions that use name/value pairs if someone prefers
> that model. The xtalk language really doesn't need any extensions
> or enhancements to enable this.
Fully agreed, as I wrote in my post introducing this arg format to the
discussion a couple days ago:
And as much as I like it in R, I'm not sure I would advocate it
in an xTalk as any sort of necessity. It might be ideal for
certain types of commands (oh how I'd love it with "export"),
but is so unusual compared to most other languages that it may
just increase the learning curve for most folks.
I bring it up here not as a recommendation, but just as a sort
of "think REALLY different" exercise as we consider alternative
syntax possibilities...
A third option is one I wrote back when I was experimenting with this,
getting just a bit closer to how those args are handled in R by using a
single string that doesn't require commas between name-value pairs:
DoSomething "name='my chart' width=100 label='This is a chart'"
Still imperfect, a bit cumbersome to have to be mindful of how strings
are handled with the single-quotes inside and double-quotes outside (see
below). But like anything else, you write it once, unit test it, and
you never have to think about it again.
Though it doesn't kill us to write parsers for things like that, it's
definitely not for newcomers. And while the engine is pretty efficient,
the additional overhead of parsing named args in script makes them
impractical for commonly-called routines where performance is critical.
More with-the-grain would be this fourth option, passing in an array as
we see with some existing LC commands and functions, but that requires a
LOT more typing:
put "my chart" into tA["name"]
put 100 into tA["width"]
put "This is a chart" into tA["label"]
DoSomething tA
I haven't spent much more time on named args because once I started down
the road of replicating R functionality in LC (seemed useful at the time
for some analytics tasks) I found there are a great many conveniences in
R that would need to be written from scratch to deliver a workflow as
productive. Ultimately I decided that rather than try to build R in LC
it was probably more productive to just learn R. :) Fun exercise,
though. While I rarely end up using such replication experiments in
production, I don't mind doing them as they help me learn the thing I'm
translating. I learned a lot about CSS writing a layout translator, the
only one likely to find its way into production. And while I could find
no practical use-case for a library that rapidly creates objects from
sparse readable strings I did learn a lot about REBOL Layout playing
around with the idea back in the day.
All this reminds me of something that actually might be worth
considering, a real sanity- and time-saver in JavaScript and other
languages:
The ability to use single-quotes and double-quotes interchangeably so
they can be nested.
E.g. to get this:
"Hello", he said. "How are you?"
...we could write:
put '"Hello", he said, "How are you?"'
...vs today's:
put quote& "Hello" & quote &", he said. " & quote \
& "How are you?" & quote
I find having only the "quote" constant with no means of nesting with
single-quotes often makes concatenated expressions much longer and more
complicated to type *and read* than their equivalents in JavaScript.
I imagine there are good reasons we don't have this, but I can dream....
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.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
