Opinion - change package name "gs" to "com.greensock"?

[GreenSock]

When I first created TweenLite, I was facing a challenge of making it easy for designers and newbie developers to use, so I chose to use the "gs" package name instead of "com.greensock". It seemed better because:

 

1) It made the class more usable without import statements (which confused some people). They could simply call gs.TweenLite.to()... which was more compact and intuitive than com.greensock.TweenLite.to()

 

2) Designers and newbie developers were confused by the nested folders required to use a package like "com.greensock".

 

I've received a few requests to switch the package from "gs" to "com.greensock" because it'd be more "standardized". I've hesitated thus far because I'm afraid it could really confused a large portion of the user base who have already built projects with the old package and then if they upgrade, it'd break their applications. Granted, a search and replace should fix it, but newbies might struggle with it. Also, there are a lot of forum posts, tutorials, etc. on the web that reference "gs.TweenLite" which would suddenly not work. So what do you think? Is it worth all that potential headache for users to switch to "com.greensock"? Or should I stay consistent and continue using "gs"? Frankly, I'm leaning towards keeping "gs" unless a huge majority of you vote for switching. Let me know what you think.

[Dave Stewart]

The other option might be to provide 2 packages. "gs" as the default as not to scare noobs, then a (obvious) link for us more seasoned scripters so we could download the TLD style of package.

 

I know it's a pain for you, but you could perhaps check the stats from the page after a month or so and see for yourself which has proved more popoular.

 

Cheers!

Dave

[fenixkim]

I disagree with this, since i started to use TweenMax, i used "gs" package; change it at this point would be a disaster for my projects.

 

Also the "gs" package is easier than use "com.greenSock";

[TronicVolta]

I vote to keep it gs, seems Tweener has managed just fine using caurina.

[mprzybylski]

stick with gs. more and more i see packages like that popping up and its kind of nice how short it is. you know me, im a stickler for long package names and standards, but even i have started to use short packages in my projects because its easier to traverse the flash explorer window in eclipse when you dont have 20 folders to go through (takes up less room too).

[sebo]

Hi,

i vote for changing the packet-name. I have to admit, i always changed the packet-structure to com.gs.TweenLite. I like to have one "classes" folder like 'com' in each project-folder, so a change to com.greensock would be appreciated.

 

having to replace the paths in older projects doesn't seem too bad to me, as I would only start using the new version on new projects and leave the older ones as they are. for all those who have a central location for all classes somewhere on their harddrive, you could still keep the gs.TweenLite for compiling older projects and add com.greensock.TweenLite for new projects.

 

just my 2 cents

 

Sebastian

[mprzybylski]

Sebastian,

Having only one classes folder (like com as you mentioned) in each project folder is not a good practice as a lot of other packages that are popular right now come in different packages like org (papervision) and others. It's a lot smarter to keep one centralized code bank that has all your class packages and just pathing your classpath to that folder in flash preferences. that way if you update your classes all projects will have the latest classes, not having to update each project separately.

[sebo]

you are right, i know, it is not "best practice". For example, i have to go to my older projects or collection of classes and manually copy the needed classes to the new project folder. This is error prone and can lead to different versions of classes. I do this mostly because i have to work on different machines, sometimes at a client's office, sometimes haveing to work together with other colleagues. So i find it handy to have all classes that i need in the project's folder as i can grab the folder and know that i'm done.

 

do you see a better way in this scenario? after all, i'm "just" a designer with several years of Flash/Actionscript background and recently switching to use classes.

 

Sebastian

[mprzybylski]

Sebastian,

That's hard to say, really. It depends on your development environments I guess. I use eclipse/FDT for flash development so all my paths to my code bank and stuff like that is saved in one preferences file which I can then load up on any machine. of course the problem with that is that the code bank has to sit in exactly the same spot on the new computer which isn't always the case, but luckily i develop on my laptop and have that with me when i go elsewhere so i don't have this issue. i guess for what you are doing that's the best way, its just a hassle to have to do it like that when you develop on one machine.

 

alternatively, you could set up an SVN repository on google code for instance and connect to it from whatever computer you are on and grab the latest versions of your code bank, but i'm not sure how familiar you are with SVN or how comfortable you would be doing that so it may not be a solution you could tackle.

[sebo]

Hi,

thanks for taking the time to write such an elaborate reply! I guess, being able to take your working machine with you (it being a laptop) must be the most comfortable solution. I hope to have this setup as soon as possible, but this will have to wait a little due to financial reasons.

Copying/Mirroring the code bank to the other computer sounds like a good idea, maybe this will be my next step.

I know about Version Control Systems and this might be the most professional way to do this. Until now, the technical stuff involved with that always scared me away. I thought that i had to install the svn repository on local machines which wouldn't have helped me much in my situation because i still would have had to keep two systems up to date. But i will definitely check out your suggestion with google code, which i wasn't aware of.

 

thanks again!

Sebastian

[mprzybylski]

glad i could help. good luck with your stuff.

[denete]

Is it worth all that potential headache for users to switch to "com.greensock"? Or should I stay consistent and continue using "gs"? Frankly, I'm leaning towards keeping "gs" unless a huge majority of you vote for switching. Let me know what you think.

 

Personally, I've always changed it to "com.gs", and just edited the other classes to accomodate.

 

Making the changeover to "com.greensock" would be much easier than most people might think...if you have fairly organized projects.

 

- David

[denete]

stick with gs. more and more i see packages like that popping up and its kind of nice how short it is.

 

That's great until the developers at Goldman-Sachs start publishing classes.

[mprzybylski]

stick with gs. more and more i see packages like that popping up and its kind of nice how short it is.

 

That's great until the developers at Goldman-Sachs start publishing classes.

 

i doubt goldman-sachs will be releasing code anytime soon. on top of that, if their developers were "in the know" they'd know there is already a pretty popular gs package flying around the earth