Agree on your "usefulness" statement. Making a class non-extendable breaks all recommended development practices. For example TDD. I won't be able to mock this class for testing purposes and will be forced to test with your class only (Granted Cache is not strong typed so in theory I have ways to bypass this limitation but still). 

Another recommended principal is to use composition instead of inheritance so in theory I could do exactly the same I wanted to do with your class (after you "lock it down") by making it part of another class without extending it. If a developer wants to get around your class ( don't know the reasons why) he/she can by other means unless you plague your code with a bunch of type checks (making Cache strong typed). 

Even if a developer get to extending your class, the fact you can't overload methods in Cache gives you a level of restriction when combined with deployed code and final as there's "no way" a developer can change your implementation so your code will still call your methods' implementation on a subclass.

All and all it seems you're going to extremes for no real benefit but since we don't know the whole picture maybe this effort is worth it. 

Is ClassDefinition available even if you deploy without the source code e.g. OBJ version?

Code placement depends on what you're trying to do and when: if processing the event from javascript (ajax call) then your code must be separate from OnPreHTTP(); if processing on the server (after page submit) then your code should be in OnPreHTTP() or called from it (this last part depends on your coding style - jam everything in a single method or separate things in multiple smaller methods)

In simple terms (as Robert pointed out) , OnPreHTTP needs to handle any processing the server must perform prior to "displaying"/"printing" the page on the browser.

Correct. The alternative using TextReader was to "avoid" increasing memory but if you have that option then the answers provided by Timothy are the way to go.

Understand. I haven't tried this myself yet but in theory you should be able to initialize the Reader with an XML.Document object. This Document can be initialized (%OnNew) with a global of your choice in the same manner that TextReader can. 

For large files I use %XML.TextReader.ParseFile(). It allows me to pass a "concrete" global instead of using Cache defaults. Usually CacheTemp which is more limited than a concrete global. With this I'm able to process larger files. Granted, it's a little bit of more work (code) as you have to traverse the results (element by element) but it gets the job done.

There's certainly a performance gap. The significance depends on what you're trying to do. For most jobs it'll be very very insignificant.  In general SQL is a little bit faster than Object access, however Object access provides other benefits in terms of code clarity and reusability. In the case of interacting with Cache from other languages (e.g Java/Spring) then SQL will be preferred for lots of reasons. The main one being that SQL, as Robert Cemper said, it's a well supported and known language. 

Do you mind sharing what are you trying to accomplish that you need a dynamic table creating mechanism?

These are compiler instructions. Not sure if the instructions change based on the cache installation language (e.g. English vs. Portuguese). You can change the language for Studio based on your locale but that's only for menus and such.

If you want to check on the result of a LOCK command for example 


IF $T {do something}

So I wouldn't call it bad practice just yet.