I am very excited about the "include" feature!
What do you guys think about "use" instead?
I know we mentioned "using" which implied a stop at
some point to some people. I really like:
use the script of file "filename"
use the script of <object_reference>
These lines would be anywhere in the script outside of
a messageHandler. This syntax solves the CGI
programmers needs, as well as creates some semblence
of Object Orientation during GUI development.
And rather than have it be textual include it becomes a
backscript of this script.
I say backscript so that you can override any of the
implemented library features. Being that it is no longer
a textual include into the current script the "used" script
will be compiled whenever a normal backscript is
compiled.
-- Michael --
PS While I am happy about the new regex feature, is it
worth the cost of the new library size? Like I said I
have needed, but I have been able to make do without
it and if it costs me significantly in some area, I might
just prefer to do without it.
Scott Raney wrote:
> > >Scott Raney and I have discussed include several times, but
> > >besides being unable to come up with a comprehensible name ("include"
> > >really says nothing, does it?),
> >
> > I don't see why not. It's an imperitive... It tells the compiler: "Include
> > whatever [into my source]"
>
> But *when*? When the application starts up? When the stack opens?
> When that object opens? When it gets its first message? What happens
> when the user edits the script with the #include? Or edits the file
> (or the script of the other object) that gets included?
>
> > >it'd be an implementation nightmare.
> >
> > #include is fine; it's preprocessed. I'd just read the file before passing
> > the script to the frontend. Call that layer the preprocessor.
>
> So it's when the stack gets loaded? Compiling every script in the
> stack at that time could get expensive...
>
> > >And
> > >people will have problems understanding it.
> >
> > How about "using script file <file>". No, never mind. That sounds like it
> > establishes that there is a point at which you un-use it.
>
> The big problem is distinguishing "compile-time" operations from
> "run-time" options. xTalk is different from almost all other
> languages, including most other scripting languages, because there is
> no "main" routine.
>
> > Another thing, though. With the HT compiler, one could make semi-protected
> > libraries for distribution.
>
> You can do this now with MetaCard, which encrypts scripts in password
> protected stacks. Decrypting them takes time compared with just
> reading in a tokenized representation, though. On the other hand,
> it's probably more secure: Ever seen a Java byte-code decompiler?
> They're amazingly effective at recovering the original source...
> Regards,
> Scott
>
> ********************************************************
> Scott Raney [EMAIL PROTECTED] http://www.metacard.com
> MetaCard: You know, there's an easier way to do that...
