On Tue, 29 Jun 1999, DeRobertis wrote:
> At 9:54 PM -0600 on 6/28/99, Scott Raney wrote:
> >On Fri, 25 Jun 1999, Ruediger zu Dohna wrote:
> >
> >(snip)
> >
> >> I know this is very much to ask for, but i think it would make it a
> >> hell lot easier to parse xml et.al.
> >
> >I think that's a whole 'nother can of worms. Current thinking here is
> >that "parsing" html using scripts is probably the wrong way to go.
> >Instead we should consider a way to convert it directly into an object
> >architecture, and access (or edit) it using that, and then convert it
> >back to a text string if necessary.
> >
>
> Scott -- are -- you -- loosing -- it? Did you not now just ask us to write
> a NetScape into xTalk?
Not at all. Netscape doesn't do this. What I was proposing would be
less, but still considerable, work. 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. 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.
> >Actually passing things as pointers is pretty much obsolete in C++
> >where one usually uses references for this. And in that case, you
> >*can't* tell from the call that it's going to be changed or not
> >without looking at the function (or at least for a "const" parameter
> >in the prototype, which makes the problem somewhat easier than in
> >xTalk). Would it be sufficient to just add this as "syntactic sugar"
> >and have it stripped off, or must it actually generate an error if
> >they don't match?
>
> We'd have to then start explaining what happens with multiple references to
> the same variable, that variables don't belong to their creator, runtime
> effeciency, etc.
I think you missed the point: pass by reference is already supported
by MetaCard. For now, you only have to declare it in the called
handler declaration itself (just like C++ references). But it would
be more robust to require the @ in the calling statement, just like
you have to put an & before a variable in C (except with arrays, yada
yada). 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.
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.
Regards,
Scott
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
