> 3. (or, in deference to or addition to #2) Support for
> "compiling" templates. We know that they already do this
> in memory (something akin to a p-code or bytecode type
> thing), but what I'd like to see is the ability to take
> that compiled chunk of memory and save it to a file.
> Python has this, as does Perl (in a limited sense). This
> would do two things for me: (a) It would mean that even
> though people could still "decompile" it, they'd still
> have to figure out var names, etc. (b) It would save the
> overhead of parsing the file every time.
A couple of points:
Moving to Java as the underlying platform should allow this; after all
that's how servlets and JSP work. As far as saving the overhead of parsing,
the existing memory storage scheme does that now.
> 5. Better locking system.
I agree, as far as memory variables are concerned. I think the way the whole
CFLOCK issue has unfolded is really unfortunate and unpleasant. I'd like to
see that go away.
> 6. Binary data support for variables. (Unicode?) Right now I can't
> (reliably) mess around with binary files. :(
Have you played with the binary functions under CF 4.5.x? You can do a
little with them, although not as much as I'd like.
> 7. Fix CFHTTP!
I agree that it's not as good as it could (or should) be. I'd generally
recommend a third-party product for serious HTTP client needs.
This brings up an interesting point. As CF developers, we're used to getting
lots of functionality in the base CF product, without having to rely on
third-party addins. Is this what we should expect?
For example, I'd much rather have the CF developers fix other problems
within CF, such as memory management and stability issues, or the COM
interface, than fixing CFHTTP, CFMAIL, and the rest, because those I can
replace on my own. I can't do a whole lot about how CF manages memory,
though.
Maybe our expectations are a bit high, after all. I suspect you wouldn't
hear ASP developers complaining about the lack of HTTP client functionality
built into ASP; they expect to have to use third-party products to fill
functionality gaps. Why should CF developers be different in that regard?
> 9. Fix the standard structures (Form, Client, etc) to
> actually work like structures, so that I can enumerate
> them, delete from them, etc. Having to GetClientVariables()
> or get Form.FieldNames is just annoying (and doesn't let
> my code be nice and transparent.) Did they fix this in
> 4.5? I think they are getting closer, but I think it is
> still broken?
For the most part, this works the way you'd want it to in 4.5.x. Most scopes
are exposed as structures, so you don't have to use Form.Fieldnames, for
example. Client variables are not exposed as structures - I suspect there's
too much overhead in doing that.
> . Passing arrays (even scalars) by reference instead of value.
I agree that arrays should be passed by reference. I actually thought they
were passed by reference, but they're not. I don't know that I'd want scalar
variables passed by reference instead of value; after all, CFML isn't
object-oriented, and we can differentiate between complex data objects
(arrays, structures, queries, etc) and simple variables.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
