Let the flames begin: remove the 'package' keyword from TS

#1 Only use I can think of is for modders who don't have access to engine source and want to expand upon or cut out engine functions. Kinda hacky. Also removing them should make integration of other scripting languages easier such as Lua or .net.

Prepare for flames. /me gets the water ready to extinguish

#2 My argument has always been that there are better ways to achieve the same goal. Like, instead of having a global onStart function that has to be hooked into by packages, have a GameState object with an onStart signal that mods can subscribe to.

#3 Against - it works.
For - it's like the appendix, you only really notice it when it's not working....

#4 I don't understand the whole "lets force my ideals on everybody else" philosophy. If you don't like the feature don't use it. It doesn't hurt anything. It's always been useful for modding to override base functions with your own as documented on TDN and official T3D documentation. Also to Torque all functions are global, there is no such thing a modules in Torque. Once a script is executed the file's contents are globally scoped. Hence why package keyword works to serve its purpose.

Keep in mind TorqueScript solely exists to be the game logic glue and nothing else. Making it more complicated to work with is just going to hurt us in the long run. So please keep in mind to keep it simple and not overly complicated just for the sake of change.

#5 Against - Because it just prolongs the death of a dying language. It obviously exists to solve a problem related to the lack of TS being a fully featured scripting language. It is not a bad language, but the T3D could be served better with a more full fledged language. Removing packages would most likely require additional changes to the language to accommodate the loss. It seems like a waste of effort to keep developing TS. There are numerous better options out there with 20 and 30 years of active development behind the language.

#6 In my game The Master's Eye I am depending heavily on packages! I am using them for every single mission, when using functions that operate different in these missions, think about saving and loading a game where you need to store different kind of things but still using one function, or other actions like Rest which is active in one mission and not in the next and might be acting different in following missions.

If you think about it they can be very useful imho, in my case I have a small set of functions that act different in various missions, but the overall game logic can still be the same.

#7 Instead of removal, why not make it function properly? Perhaps make "packages" into this "GameState" object of which you speak? Or some other mechanism that performs the task "better."

#8 Richard M, thank you, that's the first time someone's suggested to me a case where packages actually are used for replacement rather than addition. Nathan and I had a big argument about this. I've only ever seen packages used for adding functionality, like mods, rather than replacing it as you're suggesting.

The equivalent in a non-package system would be to fire a 'save' event and have some object, probably the LevelInfo, subscribe to it in each mission and respond differently.

Richard R, why would we have to make packages into something better when we already have something better?

Demo: thanks for pointing that out. Effort probably better expended on making other languages possible. Advice taken.

#9 Well, that's kind of my point - why futz with it at all?

I've always been under the impression that packages were meant to be used as Rich M is using them. See gameDM.cs in the Full template - this is meant to "override" a base set of game funcitonality and is the example for a deathmatch game. It would be replaced with (for instance) gameCTF.cs for capture the flag, or gameAssault.cs for capture and control. I guess it wasn't clear in all the clutter that Full contains.

As for "rip Torquescript out and use a 'real' scripting language," that's just a huge waste of forum space. Let me tell a story....

My wife bought a dog for my oldest daughter (of two). She was a cute little Shi-Tzu that the breeder had named "Carrot," and we all thought the name was ludicrous. The dog was only six weeks old, so we figured that if we wanted to change it we should do so sooner than later.

My wife wanted to name the dog "Nana," my youngest daughter had her heart set on "Sparkles," and my oldest didn't know what she wanted to name the dog but knew she absolutely did not want to name her "Nana" or "Sparkles." The "discussion" went on for almost an hour before I finally stopped it. The dog is now nine years old and her name is still Carrot.

You can always add any scripting language you want. Torquescript is really no harder or easier to learn than any other language. It's already there, saving you hours and hours of work - and leaving it there saves the community more hours in adding a new language, porting all of the scripts to the new language, fixing all of the bugs in the bindings, fixing all of the bugs in the new scripts, fixing object serialization, fixing who knows what else. We already have a severe manpower shortage without throwing this on the list.

#10 I think this is wrong path to remove the functional packages they substitute function overloading, language, and without have that many is not enough such as the creation of new types of data, I had plans to use in the frequent use of this features of the language, and I think it is very useful.

#11 Here's my $.05.

Personally I have never used the package keyword inside a torque game. I also have no idea why anyone would equate it with an event subscription system - internally it's just a fancy way of linking together namespaces which is piled into a neat mess on top of the other class linkage code.

I would advise against posting stuff here regarding improving, cleaning up, or replacing TS as to be quite honest nobody left can agree to anything regarding scripting. It's about as useful as beating a dead horse. IMO If you want to improve torque in this manner I would highly recommend forking the engine and going your own way.

#12 Haha, @Danny, you knew it's going to be heated! Sure it's about time to poke around to see if anybody is still awake on the forums ;-)

For what's it's worth; whatever you do, make it backwards compatible (at least for a version or two) And in this case... mmmm.. well... not so sure :-P

IMO; this should be tip number 1 "Encapsulating useful stuff on objects: don't do this!!!", if we're going to get tips in T3D... ever... (maybe with an animated paperclip and all)

#13 The crux of the problem is that Packages do not translate to any other language.

The ideal solution would be to take all the TorqueScript logic and put it in it's own C++ project.

Define an interface for the project, i.e. the dll must implement these extern's or such.

Then anyone who wanted to implement there own language (Whatever it was) would just need to make sure there language DLL exposed the same interface.

But to even start down this path, you need to remove packages because that type of mechanism doesn't exist in any other language, Javascript, PHP, perl, C#, Lua, and the list goes on.

Now personally, I do not believe from my experience that it would be difficult to put TorqueScript in it's own C++ project. We would have to revisit the trampoline macro's, making the externs it generates more friendly.

But that process can't even begin until you decide that packages have no future.

Vince

#14 http://www.lua.org/pil/15.html - not the same, but not that far off....

#15 "It encourages you to use global functions instead of encapsulating useful stuff on objects, it doesn't have a direct analogy in other languages, making it a quirk new users must learn, and it doesn't provide any functionality we could get in another (IMO better) way."

Are you sure ?
Packages implement polymorphism in TS.

#16 Naww this is like the highest number of unique posters I've seen in a thread for a while.

Richard R: the GameCore stuff isn't a great example since it uses class-based inheritance, not packages. The functionality looks similar because it is. Packages are like namespace inheritance for global functions.

James: I equate it with events because it's used that way in the stock templates, and that's the only way I've ever seen it used.

Vince: I think you're overstating the problem a little. TS having packages doesn't have to affect what other scripting languages do. It just makes it more difficult to directly translate logic.

Ivan: what do you mean by polymorphism? I understand the word in one way. Not sure if it's the way you understand it.

#17 @DB

you will have to read Torque 3D Game Development Cookbook page 63.

Quote:TorqueScript packages allow us to encapsulate functions and SimObject methods into
chunks that may be turned on and off. Packages are often used to modify the behavior of
standard code, such as for a particular game play type. In this recipe, we will learn how to
create a package and then how to activate and deactivate it.

and page 65

Quote:Any function or method that is defined within the curly braces of the package will override
the same regular function or method when the package is activated. When a package is
deactivated, the overridden functions and methods go back to their regular versions.

And to slam the definition of polymorphism:

Quote:In programming languages, polymorphism means that some code or operations or objects behave differently in different contexts.

with source https://www.cs.bu.edu/teaching/cpp/polymorphism/intro/ for people who love the academic way of presenting stuff.:O)

Indeed what @Ivan states is correct.