Naming convention suggestions

[JoeCreates]

The current style guide may be found here: http://haxeflixel.com/documentation/code-style/

While I know it would be difficult to change certain conventions, I want to put forward some arguments and suggestions for consideration.

As well as having intrinsic benefits, some style changes could help to make HaxeFlixel more appealing to prospective developers. On a couple of occasions I've spoken to developers who do not use Flixel, but did cite the strange prefix naming convention.

The "Flx" Prefix Regarding the Flx prefix, the existing code-style doc points out, "Even though this is widely regarded as bad style, it still makes sense to follow this convention since it is so deeply ingrained into the flixel workflow and doing otherwise would be very inconsistent and confusing."

Arguments for changing this convention include:-

• The prefix is unnecessary. Packages already provide this information and should be used to resolve name conflicts.
• Increase readability. Shorter lines, less fluff.
• Less to type.
• Better for auto-completion.
• Yes, it is considered bad style, and this might affect prospective developers' likelihood of trying HaxeFlixel.

Arguments for keeping the convention (with counter points):-

• "It's always been that way and I'm used to it."
  • Prospective developers are not, and it is in your interest that HaxeFlixel remain competitive with alternatives to ensure there is active interest in continuing development. The more people using HaxeFlixel, the more contributions it will recieve. Some developers might compare HaxeFlixel to an alternative and think "HaxeFlixel and X are both good, but HaxeFlixel has an ugly, impractical naming convention. I wonder what else in HaxeFlixel is ugly and unconventional. I'll go with X."
  • The "I'm used to it" argument can be applied to every bad design/convention ever.
  • It is easy to become used to a better, cleaner design.
• A lot of work to change?
  • The work is heavily reduced by automatic renaming, i.e. Refactor->Rename, or find and replace in files
• Changes the API, migration impact for users
  • Considering the next release will be a new major version, now would be as good a time to change it if ever.
  • Could provide migration script?
  • Could provide option to restore the old names with a flag in project xml, which uses typedefs?
• It lets you see which classes belong to the engine.
  • Why should this be useful? When using a class one needs to know its function, not where it came from. Far more information can be gained by hovering the cursor over a the text in FlashDevelop.

"_" prefix for private variables The underscore prefix is a remnant of AS3, which required underscores due to a deficiency that Haxe does not have. The underscore convention is generally useful in languages that allow you to define getters and setters of properties, but where a naming collision might occur between the getter/setter methods and the member variable. Haxe does not have this issue, thanks to the way properties are defined. Note that changing this convention would not affect the API.

Arguments for changing the convention:-

• The underscore is no longer required.
• It is more robust. When using an underscore, any decision to change the visibility of the property would require a complete rename, whereas without an underscore you simply need to change the property signature.

Arguments for keeping the convention:-

• It let's you easily see which variables are private.
  • This should not be useful. It is much better to consider the implementation of methods separately to the public interface.

Captitalized method parameters This is pretty unconventional. It makes local variables look like classes, especially when they share a name with a class. It is futile simply trying to avoid the "this" keyword, as there are places it simply cannot be avoided, such as when using abstract values. A find and replace in files with some simple regexs could probably make this less tricky to change. The API itself would not change.

[kevinresol]

I have already suggested using lower-cased method parameters, at least in newly-added methods... http://haxeflixel.com/forum/?place=msg%2Fhaxeflixel%2FRKp-0AncMR8%2FYY7bQr5Wp5kJ

[gamedevsam]

Using typedefs to maintain backwards compatibility is a pretty interesting idea, but users would still need to refactor their import statements, all of them (which sucks, big time). What about FlxG? Would you just name it G or Global? Neither of those is very appealing to me...

I also think capitalized parameters are odd.

[kevinresol]

To keep the import statement backward compatible, class Sprite has to be inside Sprite.hx and typedef FlxSprite remains in FlxSprite.hx. Then we are essentially doubling the number of files. (though it is not a big deal)

I think G isn't that bad, just like R in android

[JoeCreates]

Imports . . . yes, that makes the typedef method not quite so good.

FlxG need not necessarily change, as it's pretty much a static interface to flixel generally. The "Flx" would mean "this class is about flixel", rather than "this class is a part of flixel".

[mrcdk]

The "Flx" prefix I'm with you that the prefix is a bit... silly, but there are other problems that can't have a simple solution. For example, there is flixel.FlxSprite and flash.display.Sprite if we want to remove the Flx prefix it will convert to: flixel.Sprite and flash.display.Sprite The problem? If, for some reason, we need to import both of those we will have problems that have an easy fix but most people won't know how to do it.

import flixel.Sprite;
import flash.display.Sprite in FlashSprite;

Notice the in keyword. Also, it might change in the future: https://github.com/HaxeFoundation/haxe/issues/2361 There are a few more cases like that: FlxMath, FlxVector, etc

"_" prefix for private variables I'm ok with this.

Captitalized method parameters I'm with you in this. Problem is that, if I recall correctly, we tried this before without success. But, if you find a way, I don't think anyone will be against it :grinning:

[kevinresol]

@mrcdk Never aware of the import ... in thing :flushed: But one can do typedef FlashSprite = flash.display.Sprite; anyway

[JoeCreates]

Or, if one or the other is only used infrequently, just use the full path.

[mrcdk]

@kevinresol @JoeCreates Yes, both ways will also work, but we know about it because we have been using Haxe for some time, new people will flood the forums with questions about how to import this flash class and that flixel class that have the same name. I know we can add all these ways somewhere in the docs but... you know how people is... (also, it doesn't help that Haxe is not the best documented language in the planet :grin:) Again, I'm not against the change, I support it, we just need to find some way of telling people how to do it in a clear manner so we don't need to answer the same question again and again.

[Gama11]

Maintainig typedefs for compatibility is an interesting idea, but would turn out to be a big mess I think. An upgrade script would be a much better way to handle it.

I think the real issue here are the naming conflicts with the other APIs, FlxSprite, FlxMath, FlxVector, FlxPoint.

[impaler]

I think most of these points have been raised before and its just laked man hours to implement them. I cant read much I don't agree with but there is a lot to address here however so maybe if you have the time to implement these changes, take it one specific thing at a time with a new issue and get support for each thing individually.

@Gama11 I agree a script would be better as your game code would then actually be updated and easier to debug logic/default changes that have been made to the engine beside api names. I imagine the one I started is far behind the changes you have made on the engine since we wrote it?

Leaving the Flx prefix behind is something I don't oppose, it would be however the biggest breaking change to date. It makes any legacy docs and tutorials almost useless to newbies and I imagine as3 veterans will find it hard to call it Flixel anymore. Personally I agree that its redundant text, I suspect there maybe more complicated than a find and replace.

Due to breaking changes I suggest most of this is a candidate for version 5.x.

[Gama11]

@impaler Yes, the script hasn't been updated after the intial 2.x -> 3.x conversion.

Find and replace might be possible - if we use a regex that excludes FlxG, FlxMath and other classes where we can't remove the prefix.

Why do you suggest to wait until version 5.x? We are working on 4.0 currently.

[impaler]

@Gama11 ok well thats a big task for anyone from that time the commit log is huge. Whether its typedefs or this find and replace tool they are a very time consuming approach to get automatic compliance. At least the find and replace make the process quicker for minimal effort.

I suggest 5.x as removing the Flx prefix is the largest breaking change yet and I would still like to see more user support for it before brutally :rage4: pushing a change that significant breaking everyones games in their next haxelib update, +1 from me though.

[Gama11]

@impaler I think it'd be fine to only have a script for the 3.x -> 4.x conversion.

We're not in a rush to release 4.0, we can wait and get more opinions on this. I don't think waiting until 5.x will really improve the situation. Until then, the userbase will (hopefully) be bigger than now, so it's preferable to get huge changes like this out of the way - that way it affects less people?

But yeah, opinions please. So far I haven't seen anyone be against removing Flx?

@HaxeFlixel/owners @HaxeFlixel/contributors @HaxeFlixel/active-contributors

[sruloart]

As a regular user, using the dev branch and haxelibupgrades frequently, I'm all for this change (as long as you remember to update the templates). There's really no point in keep writing FlxThis and FlxThat, so I think this might actually save me some time. Also, Search and Replace is really not that overwhelming IMHO.

[volvis]

Cautiously +1 for dropping the prefix for 4.0.

[gamedevsam]

I think this needs to be in-development in a separate branch for some time, we need to have an upgrade script that works 90% of the time for everyone, and we'll need time to develop and test that.

[Gama11]

@gamedevsam I don't think this is something we can do on a separate branch. There would be merge conflicts for everything. Simply not worth the wasted time. Just look at the branches the engine has right now...

[gamedevsam]

Then I suggest we build the upgrade script first, and use that to convert both filenames, class names, and imports on both the demos and the engine, so we can make sure that when we roll out the update, everyone will have a simple and bullet proof way to upgrade their projects.

[Gama11]

@gamedevsam Sounds good to me.

[goshki]

As a regular user, I'm against dropping Flx prefix. I've been using AS3 Flixel since the first public version. HaxeFlixel grew out of Flixel and although many parts have changed or evolved into new concepts, it's still Flixel for me. Don't turn it in to another generic library with Sprite, Game, Point, Math, etc.

[JoeCreates]

@goshki Thanks for the input! Would you mind explaining what you think the Flx prefix adds? How would it have any affect on how "generic" it is other than making the naming more conventional? Do you have any counter arguments to the positive arguments presented?

Please be wary of the "I prefer it because I'm used to it" argument, and instead consider the practical implications of each option.

[PaulGene]

I would also be against dropping the Flx prefix. I like the separation it brings, i can instantly see what is HaxeFlixel and what isnt. Apart from anything though it's yet another massive breaking change that actually brings nothing to the table, what purpose will this really serve?

I have spent hours / days keeping up with breaking changes over the last year and its making updating to the dev branch a nightmare.

[goshki]

Sure, first of all, it's the case of imports. You'll have less letters to type but will have to be aware not to mix imports up with Flash classes. Secondly, even without IDE you know you're dealing with a HaxeFlixel class. Apart from that, I don't see the "shorter lines" as valid. Usually there's not more than one prefix in a line). Also, the prefix is extremely good for SEO.

Oh, and please don't underestimate the "used to it" argument. I remember one of the key points of HaxeFlixel was to make it as easy as possible for AS3 developers to migrate. :-)

[JoeCreates]

@PaulGene Did you read any of the points I made? Sorry if this sounds blunt, but I am genuinely interested in your reasoning, and I feel I already answered your question in the original post.

i can instantly see what is HaxeFlixel and what isnt.

I talked about this in the original post. Perhaps you could comment on my argument?

Apart from anything though it's yet another massive breaking change

I also touched on this. With an update script it would not really be an issue, and even the upgrade script would only be required if you wanted to port to the latest version. There's nothing stopping you from letter your finished games stay on an older version.

. . . that actually brings nothing to the table, what purpose will this really serve?

Please refer to the original post. If I didn't make my case well, perhaps you could address some of my arguments?

Thanks!

[larsiusprime]

I would just say, do not lightly underestimate the burden of keeping current with the latest dev version, no matter how many update scripts you write.. API stability IS a feature and valuable in and of itself.

Please be wary of the "I prefer it because I'm used to it" argument, and

instead consider the practical implications of each option.

In short, "I prefer it because I'm used to it" IS a practical consideration, quite a fundamental one in fact. Nothing is more practical than something that keeps working the way it used to. The points you bring up should not be dismissed, but neither should this be dismissed either.

On Fri, May 23, 2014 at 3:58 PM, Joe Williamson notifications@github.comwrote:

@PaulGene https://github.com/PaulGene Did you read any of the points I made? Sorry if this sounds blunt, but I am genuinely interested in your reasoning, and I feel I already answered your question in the original post.

i can instantly see what is HaxeFlixel and what isnt.

I talked about this in the original post. Perhaps you could comment on my argument?

Apart from anything though it's yet another massive breaking change

I also touched on this. With an update script it would not really be an issue, and even the upgrade script would only be required if you wanted to port to the latest version. There's nothing stopping you from letter your finished games stay on an older version.

. . . that actually brings nothing to the table, what purpose will this really serve?

Please refer to the original post. If I didn't make my case well, perhaps you could address some of my arguments?

Thanks!

— Reply to this email directly or view it on GitHubhttps://github.com/HaxeFlixel/flixel/issues/1108#issuecomment-44059636 .

www.fortressofdoors.com -- Games, Art, Design

[goshki]

I'm sorry @JoeCreates but I completely disagree with the "bad naming convention" argument. For a person choosing an engine (a library, to be precise) a much more important question is "how quickly and easily can I build something with this". One of the main reasons of Flixel's popularity in its early days (and many Ludum Dares later on) was the ease of development. The more rigid rules you enforce, the less people will approach HaxeFlixel. And yes, the esse of looking up snippets of code, tutorials and classes in Google is part of low entry barier. Not everything can be looked up in FlashDevelop. Up to this day it's easier to check out Flixel Power Tools classes on Photonstorm's website.

[JoeCreates]

@goshki If AS3 users wish to convert their old AS3 games into haxe, they could still do it to the version best reflecting the AS3 version they used. Would you prefer that we stop HaxeFlixel development to keep it in line with the dead/dying AS3 version? If we were to take the "used to it" argument seriously, HaxeFlixel would forever remain tied down by AS3 flixel. Sure, it would be possible to staple the odd feature onto the side here and there, but the impact of fundamental issues will grow and grow until there effort of making changes just becomes impractical.

. . . will have to be aware not to mix imports up with Flash classes.

The design of HaxeFlixel means that you will seldom need the Flash namesakes. In the very rare cases a developer might want to use them alongside HF classes, it's hardly difficult to decide to use the package path for the less common one.

Secondly, even without IDE you know you're dealing with a HaxeFlixel class.

The vast majority of the time, this will be completely obvious from the context, anyway.

Apart from that, I don't see the "shorter lines" as valid. Usually there's not more than one prefix in a line).

I'm not sure what flixel code you're looking at. Try looking in the source of the flixel demos, or in the flixel source itself.

[larsiusprime]

"If we were to take the "used to it" argument seriously, HaxeFlixel would forever remain tied down by AS3 flixel."

That's a bit of an exaggeration, no? We shouldn't dismiss anything here. "I'm used to it so it can never change" is not the argument, it's "I'm used to it and that's a valuable thing" so the benefits should outweigh the costs. And there are directly quantifiable costs I might add, updating to the latest version costs time and effort no matter how many fancy import scripts are written. All that said, I agree with the arguments for dropping the Flx prefix -- I believe they are valuable. But I am not quite yet convinced that this value is greater than the cost of the change. Please convince, don't dismiss.

[PaulGene]

@JoeCreates of course i read the points...

"The prefix is unnecessary. Packages already provide this information and should be used to resolve name conflicts."

You say it's unnecessary but a lot of people will disagree. @goshki has pretty much covered this above.

"Increase readability. Shorter lines, less fluff."

For me it increases readability because "i can instantly see what is HaxeFlixel and what isn't"

"Less to type."

Is this really an issue?! code completion?

"Better for auto-completion."

This might be a valid case, but i'm not sure how removing the prefix will improve this?

"I also touched on this. With an update script it would not really be an issue, and even the upgrade script would only be required if you wanted to port to the latest version. There's nothing stopping you from letter your finished games stay on an older version."

The issue here is this will be another breaking change after breaking change after breaking change after breaking change etc etc. Yes a lot of the breaking changes are easy to fix but with the cumulative nature of them all, and the fact that some of them have introduced bugs (tweening springs to mind) and the knock on effect they have with my extended parts of HaxeFlixel which also introduce bugs... its becoming very tiresome indeed.

[larsiusprime]

The core of the issue for me is what is the benefit vs. the cost.

Benefits: mostly syntactical, clarity, less messy. Ie, mostly subjective stuff. Costs: Breaking changes. These have real costs for developers, especially in production environments. I'm not against breaking changes but we really need to pick our battles. We also need to get the opinions of more (non-contributor) users and make concerted efforts to reach out to them as their needs are quite different from our own. In regular software development they would be our "customers."

To specifically address the points:

"The prefix is unnecessary. Packages already provide this information and should be used to resolve name conflicts." --> I'll grant you a slight win on this one. "Increase readability. Shorter lines, less fluff." --> Subjective, some find it more readable. "Less to type." --> Minimal, autocompletion exists. "Better for auto-completion." --> Sure, but marginally so.

Crucially: "Yes, it is considered bad style, and this might affect prospective developers' likelihood of trying HaxeFlixel." --> this is not at all clear. The above 3 are in the benefits column, but this last one is totally disputed. I'd argue it's more likely to affect prospective developers likelihood of trying HaxeFlixel, if the repo gets a reputation for breaking changes and API stability.

If I were writing Flixel from scratch I would totally agree with removing the Flx prefix, but I need to hear a stronger case for removing it now that it's out in the wild.

[gamedevsam]

I suggest we drop this issue. I wouldn't feel comfortable making such a drastic change unless the vast majority of users is on-board, and it doesn't seem like that's the case.

[JoeCreates]

@ PaulGene

You say it's unnecessary but a lot of people will disagree. @goshki has pretty much covered this above.

I pointed out that using package names can already do what the prefix does. In order to counter this point, you'd have to demonstrate some necessary use of the prefix that cannot already be done with packages. All of the arguments made for the necessity of the prefix (based on the fact that it allows you to see which package the class belongs to) all have a standard alternative that doesn't force everyone else to conform to your personal preference.

[NicoM1]

Honestly, I have to say I like the prefix, I think it's a nice separation, and makes me feel like I'm using a cohesive engine, not a bunch of utilities

[goshki]

Would you prefer that we stop HaxeFlixel development to keep it in line with the dead/dying AS3 version?

Now that sounds as a little exaggeration. If the prefix is the show-stopper for futher HaxeFlixel development then, by all means, please drop it.

The design of HaxeFlixel means that you will seldom need the Flash namesakes

The vast majority of the time, this will be completely obvious from the context, anyway

And what about the whole body of knowledge that's available online. How will you search for it? How will you know the context skimming some source code on Github?

I'm not sure what flixel code you're looking at. Try looking in the source of the flixel demos, or in the flixel source itself.

Well, I'm looking at my code. :-) But to be fair I looked at several HaxeFlixel core classes and I sustain: most of the times it's not more than one prefix per line, mostly declarations and static methods calls (FlxCamera, FlxDestroyUtil). The worst offender is the FlxG class but you can as well say that this god-class is an anti-pattern.

This whole argument seems pointless to me so I'll reiterate: if the prefix stopa you from improving and expanding HaxeFlixel's code and its features, then please drop it. But if it's mainly the aesthetic case of bad naming convention, then I'd love it to be left as it is.

Also, please notice that it's the only change I disagree with. Apart from that, I'm all for making HaxeFlixel a better and more accessible library for anyone, including you, the maintainers.

Peace!

[PaulGene]

Can I also say that I'm not against breaking changes at all when they are truly worth it. The restructuring of the engine that has been done with the guidance of Gama11 has been amazing.

HaxeFlixel is now much better for all the hard work, but in terms of the structure / organisation of the engine I think its got to the point where were making change for change's sake.

[undefinist]

"Better for auto-completion" Isn't having the prefix good for auto-completion, though? Just type Flx to filter out all the flixel classes.

[larsiusprime]

Whatever happens, I just want to say I'm really glad that Flixel has changed for the better of the past few years and I really value everybody's contributions.

[JoeCreates]

@madhoe

Isn't having the prefix good for auto-completion, though? Just type Flx to filter out all the flixel classes.

Consider what you do having filtered out the Flx classes. Do you import them all? Or do you continue to type a few characters to find the class you're after? Chances are the latter, and without the Flx prefix, in the rare cases there is a non-flixel namesake for the class you're after, it will usually be a case of tapping down once or twice. However, things you have already imported will be given preference, so even this will usually be unnecessary.

If your purpose is to use autocomplete to browse what flixel has available, it is more informative to type the package name ("flixel." etc.) because this will also show you what packages are available. Most ide's (including FD) will automatically remove the package prefixes if they are not necessary.

[PaulGene]

As for prospective developers' likelihood of trying HaxeFlixel, and more importantly those developers staying with HaxeFlixel, massive breaking changes like this one should be the last thing we do. How are developers supposed to get comfortable with the engine if we keep pulling the rug from under their feet. Not to mention the effect it has on things like online tutorials, which are also very important for gaining new developers.

Now HaxeFlixel has been restructured to an acceptable level we should be focusing on new features and engine / code stability, only making breaking changes when desperately needed.

[Tw1ddle]

@goshki @PaulGene Those are interesting points about SEO and online tutorials. Those have helped me when searching for Qt tutorials and code snippets, its classes are also prefixed for legacy reasons. It's also handy when searching for OpenGL documentation or tutorials. So maybe that is a good argument for keeping the Flx prefix for these reasons?

It lets you see which classes belong to the engine.

Hey @JoeCreates :smile: - what if someone isn't using an IDE to read the code? In a way it does help emphasize the "separation" of engine and user stuff that people have alluded to.

Just my $0.02, I'm new to HaxeFlixel.

[Ohmnivore]

I consider myself a regular user of HaxeFlixel. Like mostly everyone, I was familiar with the AS3 flixel before I discovered the Haxe port. I felt right at home with HaxeFlixel because it was a port - most classes had the same names, methods, and variables as the AS3 version. I was able to transpose my prior knowledge to this new engine I was learning. Also, I found that most AS3 Flixel tutorials could fit HaxeFlixel as well.

Since then, I find it a bit stressful to run "haxelib update flixel". You never know what and how much you'll have to re-write, or if the new version will compile at all. Oh and don't forget to update flixel-addons, too!

In the end the changes are worth it, and the re-writes are really short if I have to re-write code at all. But I think that changing class names is just too much. The amount of stuff to re-write after that isn't worth it. Also I really like the Flx prefix.

Most importantly I find that the Flx prefix helps quickly distinguish classes that belong to the game engine from other classes. To me this means a lot.

[JoeCreates]

(Leaving the prefix issue aside for the moment, I want to talk about breaking changes generally.)

@PaulGene HaxeFlixel has been restructured to an acceptable level? I'm afraid not. Doing bugfixes and adding features is made considerably harder by some fundamental deficiencies in flixel's design. As time goes on, features get tagged onto the side of a system that never preempted them, leading to fractured messy code with a lot of repetition. The impact of these changes gets bigger and bigger the more new features get added. With such deficiencies, more development effort is required to maintain it, more bugs occur, new features come slower (and often get lumped with the deficiencies they were built upon).

Sometimes doing things properly requires breaking changes. You have to damage your muscle before it can grow back stronger. You can be sure that we have not reached a point where we can say, "Now HaxeFlixel has been restructured to an acceptable level". It's easy to just want the new features without any hassle when you don't have to implement those features.

If you want to benefit from new features, fewer bugs and faster fixes, embracing breaking changes is absolutely in your interest. Ideally we should break as much as possible at once. Fix the most impeding issues and make the engine more flexible so that breaking changes are far less likely to be needed in the future.

If, on the other hand, you care more about sticking with the same, then stick with the same. Just be aware that adding features and fixing bugs in a pre-breaking-change version will likely require much more effort.

My desired approach for making games is primarily to pick a build on a per-game basis, and to only go through migration if the game actually demands the newer features/bugfixes. Do all the flixel games currently out there need all the new and future features? Not really. Want to port an old AS3 flixel game to HaxeFlixel? Well then there's no reason you need to port it to the latest version. Port it to the version that best reflects the version it was developed on, and only upgrade if you really want to make use of the new features. Make your next game in the most recent version, and get all the benefits of an improved engine that isn't held back by past deficiencies.

[Ohmnivore]

I agree that some breaking changes may be necessary, but I don't think renaming classes fixes any design flaws or issues. In fact, I've found that the "Flx" prefix has helped me faster understand code and quickly identify the flash parts and the Flixel parts of the code.

Also, I've been developing a game for the past two months, and, yes, I've seen enough change to want to upgrade to newer versions all the time. My motto is to not modify the Flixel base code -ever-, but to always extend the engine's classes so that I can use the newer versions which are faster, fix issues, and have features I never knew I needed but that I end up liking when I discover them.

[larsiusprime]

With DQ1, I stuck with a stable (as3) flixel codebase and never upgraded, and because I did so, I wasted TONS of time re-implementing what the community had since added themselves, and better.

With DQ2 I'm tracking the dev branch. Yes, this is more risky and means I need to have a certain toleration for breaking changes, but it's more than paid off for the same reasons Ohmnivore just described. There's so many new features and fixed bugs that I absolutely have good reason to keep upgrading whenever I can. Also, it's pretty much impossible to contribute back my own improvements (such as flixel-ui) without staying current.

Breaking changes are obviously necessary in principle, I agree with that whole-heartedly. The recent "great refactor" is a good example -- I was a bit grumpy about having to update my code, but it was ultimately worth the pain for a much more useable and cleaner flixel, and I support changes like this in the future when properly balanced against the costs.

[gamedevsam]

I'm making the executive decision to close this issue. There is good discussion here, but we're not removing the Flx prefix because we need to focus on bug fixing and providing a stable API.

[kevinresol]

what about the other two suggestions?

[gamedevsam]

I would suggest separate issues be opened for them. This issue was overwhelmingly focused on removing the Flx prefix.

[JoeCreates]

Yes, the Flx prefix change is in practical terms a relatively small improvement. The main arguments against specifically whether or not it is actually an improvement (i.e. disregarding migration impact), seem to come somewhat from an unfamiliarity of more common industry practices of using packages for the same purposes.

The point about SEO I am not sure about. I have never had issues researching libraries without a prefix. If you have found it easy to research a library with prefixes, to assert that such libraries are therefore easier to research would be confirmation bias. It would mean nothing unless you could also demonstrate consistently that libraries without prefixes are harder to research. Note that many more significant factors affect SEO, such as being generally well documented.

I believe the best argument against the Flx change does not pertain to whether or not the prefix itself is better, but to migration impact. This is a completely legitimate argument, and as @larsiusprime pointed out, this comes down to weighing up the benefits.

I want to make clear what I consider to be the greatest reason for the change -- and why I bothered to put so much effort into this argument: I have spoken to several non-flixel-using developers about flixel, at game jams, conventions, and meetings. In three cases I can recall, the other party brought up flixel's Flx prefix convention as a downside to the engine. Perhaps it's coincidence, and I can't honestly judge how much of an affect the prefix actually had on their judgement and subsequent non-use of flixel, but it does concern me. It was a factor when I was considering to use flixel, and it seems to have been a factor for others, too. I realise it is not likely to be a consideration for beginners, and beginners are a big market for flixel, but it might be for people familiar with the standard alternatives to the prefix. If you know anyone who considered flixel but decided to go with an alternative, perhaps consider asking for any points that influenced that decision?

Of course, my own opinions and experiences of other developers may not at all be representative of prospective users as a whole. I voice this concern only with the best interest in working toward the best possible engine and sustaining a healthy active community. It's not exactly doing badly, anyway. :P

[gamedevsam]

@JoeCreates you (and others) make a good argument for why removing the prefix could attract users that were previously on the fence about the engine, and perhaps even lead to a cleaner API in the long term. But I have weighted these arguments against the concerns of existing users (as well as my own) and decided it's not in the best interest of the community to make such a drastic API change.

I'm sure many users will be willing to live with small annoyances (such as typing Flx every time they invoke a flixel class) if we succeed on our mission to provide the most feature filled, easiest to use, and most stable cross platform 2D game engine available.

[JoeCreates]

I appreciate that, @gamedevsam, though I do consider the argument to be quite relevant to feature implementation and bug fixing. With more users, there is more investment in the engine, and with that, more potential contributors. It is especially relevant to consider the impact on the decisions of people wishing to develop for commercial projects, and people with experience of other languages and frameworks.

Regardless of any immediate decision, I do hope people will keep it as a consideration.