Scott wrote:
>To use the dreaded dot notation, you might end up with something like:
>parse "some XML string" into somevar
>put somevar[somekey].name into field "name"
>
>To open the can a little further, it would have to allow iterating
>over all elements in these "structures", and then all of the fields
>within each. Being able to search and sort them would be useful as
>would being able to dump them directly into a tree view.
Shure we need this... and we need access to the attributes of a tag.
>We may be able to do it by just expanding chunk expressions to allow this, but
>it may get unwieldy for this kind of thing because there are
>insufficient constraints on what the field names are and so some new
>syntax (like a . notation) may be the better way to go.
Scott, you know very well why you call the dot notation "dreaded"!!!
I don't think it is very intuitive to read; expanded chunk
expressions are better. The examples I gave where:
get the header of the fifth fontBlock of ...
get word 1 of the body of fontBlock 3 of ...
repeat for each headerAttribute a in fontBlock 3 of ...
switch the name of a
case ...
Compared to something along the (dotted) line of:
parse fld "foo" as xml into x -- could be something other than xml
get x["font",5].header
get word 1 of x["font",3].body
repeat for each header.attribute a in x["font",3]
switch a.name
case "size"
get a.value
Now, which one is the can of worms? Even if defining your own
delimiter expressions is not added now, the chunk expressions are
much more xTalkish. In a first step you could add the chunk types
"block" and "attribute" (or "xmlBlock" and "xmlAttribute"?). In the
suggested syntax to define delimiters that would be:
define delimiter block as "<" & a word type && a string header &">"\
& a string body & "</"& the type &">"
define delimiter attribute as a token name &"="& a token value
In version 4.0 you might add the syntax to define custom delimiters.
Oh... and we only talked about parsing. We also need the ability to
write to those chunks:
put 14 into the value of attribute 3 of the header of block 5 of ...
Maybe it is even possible to use named chunk expressions (they are
objects then, aren't they) and to have "value" as the default
"contents":
put 14 into attribute "size" of the header of block 5 of ...
I don't know how slow this would get, but it is "only" string
manipulation... and in the age of 500 MHz Processors, this should be
acceptable.
About call-by-reference, Scott wrote:
>I was proposing that it allow it in *anywhere* in the calling
>statement to serve as a sort of comment on what was going on. If
>the engine had to enforce it, there's a backward compatibility
>problem and the need to write more code to actually check the
>"types" of the passed parameters.
Backward compatibility is problem that comes up again and again.
Maybe it could be solved by adding two stack properties:
the compatibleVersion
The version of metacard that this script has proved to be compatible
with, i.e. the engine has been able to parse all scripts without
error or doubt against this version (e.g. all calls-by-reference have
the @, or "ms" is not used as a variable name anywhere; the engine
can not decide if lineOffset needs the wholeMatches to be set to
true, so this is a doubtful expression). If there are incompatible or
doubtful statements then the compatibleVersion stays what it was and
all additional features are disabled for this stack. This test has
not to be done every time the stack opens, if there is a property:
the lastVersion
For doubtful stacks you'll have to be able to set the compatibleVersion.
Well... this is still another can of worms, because the engine has to
know which features where in which version, but it would make it so
much easier to add to xTalk in a sensible way and to get rid of
deprecated stuff.
Back to call-by-reference:
>Perhaps a better way to deal with this kind of software engineering
>issue would be to add a way for the script editor to show the
>handler declaration for the handlers that match the call. This
>would be useful for this type of parameter matching, but also to try
>to determine where in the hierarchy the handler is.
This sounds like a nice feature if you are writing your code, but it
does not help when you read it.
Regards
R�diger
--------------------------------------------------------------------
| Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
| PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
--------------------------------------------------------------------
