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.

[Gama11]

I had opened a thread redirecting to this in the forums, and two people sent me a private message, not realizing the thread is closed I guess:

From Tembac:

I read the full post on Github and I don't agree on the change. I think that most people are against it and the reason were expressed clearly on github.

I don't see the benefits of this big breaking change. I wold like better if the contributors keep working on improving flixel rather than fighting against something that finally is not very important.

Flx-prefix is part of the flixel culture I'm used to it more than anything.

From Ishan Das Sharma:

I suggest you go on and remove the Flx prefix. However, you should ease the transition by remapping the Flx-classes to the non-Flx classes

---

There've also been a few reactions on twitter:

From Tommy Elfving:

oooh, that's a tough one :)

From Kozie:

definately! They did not invent namespaces for christmas decoration ;)

From Dragomir Olenic:

It divides code in engine part and everything else. In my opinion, that prefix is very useful.

[PaulGene]

@JoeCreates Lars has already touched upon this but choosing a HaxeFlixel version per game and then sticking with it, is only really suited to small games.

I'm making a game that has been over a year in development and heavily extends HaxeFlixel, and from past experience I know its imperative that i keep up to date with the dev branch for bug fixes / patches to Haxe / OpenFl updates, and of course new features and performance improvements.

Because of all the breaking changes if i don't update every week or so it becomes a complete nightmare trying to keep everything working without introducing bugs.

HaxeFlixel has been restructured to an acceptable level? ABSOLUTELY in terms of code style and organisation, you have to have a cut off point. I dont need a lecture on code design, I've already stated that breaking changes are sometimes needed and worth the upheaval (For instance i would welcome a refactor to decouple and centralize the collision / physics system) ... but these breaking changes must be absolutely worth it, not silly little things like class name changes that are purely subjective.

[impaler]

I think that my previous :rage4: emoticon best describes the prefix change then. It is a subjective choice indeed. If I was to design an engine I just wouldnt use it so I wouldnt miss it personally. However @larsiusprime and others are right that the value vs cost isn't there so thanks for speaking up everyone.

in terms of code style and organisation, you have to have a cut off point

@PaulGene Yes I think the cost of changing the public api is huge for user adoption and confidence in the stability of the project. Internal code style maybe not so much as long as the main api stays the same. So comments about the case of the paramaters, underscores etc should be great to change without effecting anyone's games.

I think there is merit in seeing api stability almost as important as the actual code stability when someone is building for a release, a we know developing a game can take months/years. One reminder to the devs changing the public api aka @Gama11 ;) your not coding on a moving target if your working on the engine code, everyone else running from haxelib update wanting the latest bugfixes and improvements is(api changes cant always be called improvements). If Haxeflixel was a commercial product I doubt we would have any users left with the rate its being changed, show me a project that does this and is successful? Whether the changes being made are slightly semantically, structurally more intuitive etc the cost of changing it makes that work damaging in the long run.

@HaxeFlixel/owners @HaxeFlixel/contributors I would like to see public api changes slowed down and focus on stability, bug fixes, unit tests and features. I suggest we all maintain and enforce a policy for changing it, such as commits requiring a link to the discussion about the change or with the reasoning mentioned from at least two owners of the repository, this has been done ok to some degree but things pass through like https://github.com/HaxeFlixel/flixel/commit/2da339c33c11c894e25c9af6ddd3013574d6097a an average user getting this change wont know easily wtf or htf to update their code without comments on changes to the public api, there should be no rush in changing it. ( I like that change btw but thats besides the point )

[kevinresol]

What about a separate repo which contains only typedefs which map the prefixed and no-prefix classes? 2014/05/25 10:10 "Chris" notifications@github.com:

I think that my previous [image: :rage4:] emoticon best describes the prefix change then. It is a subjective choice indeed. If I was to design an engine I just wouldnt use it so I wouldnt miss it personally. However @larsiusprime https://github.com/larsiusprime and others are right that the value vs cost isn't there so thanks for speaking up everyone.

in terms of code style and organisation, you have to have a cut off point

@PaulGene https://github.com/PaulGene Yes I think the cost of changing the public api is huge for user adoption and confidence in the stability of the project. Internal code style maybe not so much as long as the main api stays the same. So comments about the case of the paramaters, underscores etc should be great to change without effecting anyone's games.

I there is merit in seeing api stability almost as important as the actual code stability when someone is building for a release, a we know developing a game can take months/years. One reminder to the devs changing the public api aka @Gama11 https://github.com/Gama11 ;) your not coding on a moving target if your working on the engine code, everyone else running from haxelib update wanting the latest bugfixes and improvements is(api changes cant always be called improvements). If Haxeflixel was a commercial product I doubt we would have any users left with the rate its being changed, show me a project that does this and is successful? Whether the changes being made are slightly semantically, structurally more intuitive etc the cost of changing it makes that work damaging in the long run.

@HaxeFlixel/owners https://github.com/orgs/HaxeFlixel/teams/owners @HaxeFlixel/contributorshttps://github.com/orgs/HaxeFlixel/teams/contributorsI would like to see public api changes slowed down and focus on stability, bug fixes, unit tests and features. I suggest we all maintain and enforce a policy for changing it, such as commits requiring a link to the discussion about the change or with the reasoning mentioned from at least two owners of the repository, this has been done ok to some degree but things pass through like 2da339chttps://github.com/HaxeFlixel/flixel/commit/2da339c33c11c894e25c9af6ddd3013574d6097aan average user getting this change wont know e asily wtf or htf to update their code without comments on changes to the public api, there should be no rush in changing it. ( I like that change btw but thats besides the point )

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

[impaler]

@kevinresol even if that worked without any problems, it seems like a band-aid job on something that doesn't have enough value or support to change. I think as @PaulGene said its really change for change's sake being so subjective. I have no problem in keeping with Flixel's roots in the prefix still.

[JoeCreates]

@impaler (Not regarding the prefix, but regarding your suggestion as to where flixel development effort should be)

My honest assessment is that HaxeFlixel needs some major changes to the core in order to be sustainable. New features can be stapled on to the side, as many have already, but given deficiencies in the original design, this has led to an overwhelming level of repeated and inconsistent code. With this, bugs are more likely to arise and be harder to fix, new features take more effort to implement and often inherit the same deficiencies. It's really not realistic to say "let's just fix bugs and add new features".

Also, commercial and popular APIs undergo massive changes on occasion. It tends to happen early in their lifecycles. Look at the early lives of PHP and Actionscript . . . Furthermore, HaxeFlixel was never designed with future-proofing in mind. It shows and it suffers because of this. Ignoring such problems will just make the problem grow, and actually doing something about it will become harder and harder.

[impaler]

@joecreates I totally agree with most of what your saying about some parts of the codebase but working on the underlying architecture and slowing down superficial changes to the public api are different subjects that need case by case consideration. Are you saying haxeflixel can't be improved if we talk seriously about changing the public api and setting a more strict process for that?

I didn't say other projects don't change their api, I am saying haxeflixel has been doing so maybe too quickly which will negatively effect its userbase.

[JoeCreates]

@impaler

Are you saying haxeflixel can't be improved if we talk seriously about changing the public api and setting a more strict process for that?

No and I have no idea where you got that impression. :P

I would like to really focus on fixing the core API in such a way that makes HF far more flexible and maintainable, greatly reducing the need for breaking changes in the future. It should be very carefully considered to be resilient to future changes by preempting future features or more creative ways in which users might wish to use HF. The breaking changes should occur all together with the aid of an upgrade script.

Minor-improvement changes, such as naming convention changes, would be clearly wasteful to do for the sake of those changes alone. However, if they are indeed improvements, there is no additional upgrade inconvenience by delivering such changes alongside more important core changes. If the important core changes come and go without the minor-improvement changes being addressed, then they likely never will be.

[impaler]

@JoeCreates that sounds good, however nobody is saying we cant change the api if there is good enough reason. Your points seem to repeat most of what has already been said. Upgrade scripts do help, thats why I started the existing one, but that is a band-aid solution that eases changes only. Correct me if I am wrong but Haxeflixel seems to have breaking changes every couple of weeks and knowbody has kept that script up to date.

[Gama11]

@impaler That's right, we have been making API changes for minor versions (3.1, 3.2, 3.3). I'm thinking that after the release of 4.0, we should avoid any breaking changes unless absolutely necessary until the next major version (5.0) - and actually follow semantic versioning.

[JoeCreates]

@impaler

however nobody is saying we cant change the api if there is good enough reason

"Good enough reason"? What does that mean?

The fact is you need to discuss the reasons before you can determine if they are good enough, and that's why the discussion needs to be had, and that is why I am saying certain things again, even if I and others have said them before. There is no use in pointing out that "breaking changes require sufficient reason" in a discussion about whether there is sufficient reason. If people say, "don't change the API without a good enough reason", then they aren't exactly saying much, unless they also make reference to specific changes, and also argue as to whether or not there is sufficient reason for them.

I don't think anyone wants to make breaking changes that don't have a good enough reason, so arguing it in such simple terms is not useful.

The fact that breaking changes have occurred is not a strategy. There is no plan to make frequent breaking changes. It is a symptom of the issues in the engine that needed to be fixed, and the strategy or lack thereof for implementing the the required changes efficiently.

Nothing I have argued here has in way way necessitated frequent breaking changes. The strategy by which breaking changes are generally implemented is a separate issue, and I am 100% for finding ways to reduce the need for and impact of breaking changes, while also making the engine easier to adopt, use, extend, and maintain. I don't think we disagree on this, so let's talk about how.

@Gama11 I agree. And when preparing for a major version we should really work to ensure any API breaking changes are flexible and resilient to future changes. I feel a lot of recent discussion has already been quite productive toward this end.

[impaler]

@JoeCreates if you see the commit I pointed to you will see that there is no reference to any discussion of the removal of setAll, callAll() https://github.com/HaxeFlixel/flixel/commit/2da339c33c11c894e25c9af6ddd3013574d6097a If my game was using this and haxelib upgrade broke it, I would be pretty annoyed its just removed without any help in the commit message to implement an alternative. If you dig the logs there are many other examples of things being removed renamed without links to discussions or alternatives.

However your right this is too generalised, and this whole issue is non specific lets wrap it up.

[Gama11]

@impaler Things like this are generally mentioned in the upgrade guide. Also I very much doubt that people upgrading via haxelib are looking at commit logs before having a look at the changelog or the upgrade guide.

You're missing the context of that particular commit. It was part of this pull request: #1119 which in turn "closes" issue #1086. And that does have an explanation.

[impaler]

@Gama11 I cant see any discussion on those links, just a merge from sam and your opinion on Reflection as bad programming. This is a must for any upgrade guide I imagine someone being frustrated working off dev having this break their game with no docs.

[Gama11]

@impaler I'm not sure what kind of discussion you are looking for, I thought you wanted an alternative to be mentioned for users that want to upgrade. #1086 does provide an alternative:

forEach()-functions should be used instead

[impaler]

Well a comment on your issue would be something. I guess having the minimum of Sam accepting the request makes this ok. What do you think we should have as the minimum process to change the public api?

On the point of the change I don't see what harm the original method had, imagine if the Haxe decided to remove Reflection because its slow and encouraging bad programming practices, which is your only argument. These method could still exist by using the new forEach api and then knowbody's code would have been broken.

[Gama11]

imagine if the Haxe decided to remove Reflection because its slow and encouraging bad programming practices

That's comparing apples and oranges in my opinion. There are some things that just cannot be done without Reflection. Setting a variable / calling a function on each member of a group is definitely not one of them! A good API should be hard to misuse - it is incredibly easy to fall into the trap of having a setAll() or callAll() call on large groups in some update() function, which can have a serious negative impact on performance - similar to FlxGroup#sort() that was using Reflection until recently.

It is not possible to use forEach() inside of setAll() or callAll() - those two functions required string-based access to member variables / functions, which is simply not possible without Reflection.

This discussion is getting a bit off-topic, and I don't really see the point if you agree with the change in the first place.

[impaler]

@Gama11 thats cool you don't need to explain Reflection to me. I just think that since this api was even in the as3 version :rage4: porting to forEach() might not make immediate sense to some as3 developers moving to HaxeFlixel. Please don't forget to write an example of porting setAll in the upgrade guide ;)

[cwkx]

I strongly upvote the changes proposed by @JoeCreates, for the next major release. When I first came to HaxeFlixel in Novemeber, the emulated namespaces and overall level of abstraction made me despair and look to another framework, but thankfully I returned thanks to curiosity with the haxe language; this certainly is not a minor-issue for non-as3 newcomers who aren't used to as3's damn-right weird conventions (when compared to modern practices, e.g. in C++ http://games.greggman.com/game/lets-debate-coding-style/ ) - I think the majority of future HaxeFlixel users will come from non-as3 backgrounds given the rising popularity of haxe itself. If a language offers namespaces, there should be no excuse to continue to emulate namespaces; these are not the days of C programming any more, and there's nothing wrong with typing flixel.Sprite and flash.display.Sprite to distinguish rare cases where both are needed in the same .hx file.

[Gama11]

Thanks for your insight, @cwkx - I agree. Sadly it looks like getting rid of the Flx-prefix is gonna happen...

I don't think any of these are even conventions in AS3 - except for maybe the underscore for private variables. These things are just plain weird.

[goshki]

That's sad, indeed.

So while we're at it, I propose we drop "Haxe" out of HaxeFlixel's name. Users will know it's Haxe version of Flixel either way, thanks to the .hx in filenames.

[JoeCreates]

Using a bad analogy is like riding a snake into a supermarket and shouting "Hey!"

[goshki]

Ridiculous, isn't it? Seriously though, I'd love to hear an argument against such change that would not be similar to those provided by opponents of dropping prefix. Because I can use any argument provided by proponents.

Another ridiculous thing is how it came as "naming conventions suggestions" and boiled down to taking all or nothing, even though owners and contributors seem not to reach consensus over it, let alone users.

[JoeCreates]

@goshki

Seriously though, I'd love to hear an argument against such change that would not be similar to those provided by opponents of dropping prefix.

Oh, you were serious?

HaxeFlixel and Flixel are brands. The purpose of a brand is very different to the purposes of a class prefix as proponents give, here. If you think brands belong in code, then I guess you'd also prefer HxFlx to be the class prefix as well? Perhaps all openfl classes should be prefixed with OpenFL?

The HaxeFlixel brand has no package system. No such system can exist in, or would ever be appropriate for branding. In coding, it can exist. It does exist. It is more powerful and flexible than using string prefixes. It is an industry standard.

Comparing packages to file extensions is a bad analogy because packages are designed to provide a way to identify classes in a tree structure. Packages/namespaces are designed to let you distinguish between classes of the same name. Can the .hx file extension do that? No. It's purpose and scope are completely different.

Another ridiculous thing is how it came as "naming conventions suggestions" and boiled down to taking all or nothing, even though owners and contributors seem not to reach consensus over it, let alone users.

I haven't a clue what you mean by this. "All or nothing"? The change will either be made, or it won't, right? There is no in the middle as to whether a change is made or not. Do you think the word "suggestion" actually means "thing that won't ever happen"? Also, you seem to have thrown a point about consensus in there, but I see no relation to your comment about the use of the word "suggestions". :P

Somebody makes a suggestion, and there is not consensus as to whether to apply it. What is "ridiculous" about that?

[kevinresol]

I am for the prefix removal. I suggest to have a separate repo to contain the typedefs, in which the file structure is same as current. e.g. flixel/FlxBasic.hx but it has simply one line typedef FlxBasic = flixel.Basic which points back to the renamed classes. For users who opt not to change the import statements, they can simply add one line in the project xml <haxelib name='flixel-compatibility'/> . Then the users are happy and the framework is happy.

[goshki]

Oh, you were serious?

Oh christ, of course I was not being serious. But I understand that sarcasm may be hard to spot in writing.

I haven't a clue what you mean by this. "All or nothing"? The change will either be made, or it won't, right? There is no in the middle as to whether a change is made or not. Do you think the word "suggestion" actually means "thing that won't ever happen"? Also, you seem to have thrown a point about consensus in there, but I see no relation to your comment about the use of the word "suggestions". :P

Well, maybe that's the whole point, that you are so focused on defending your position that you can't see the whole context of this issue (Github issue, I'm being specific to avoid further confusion). This issue is titled "Naming convention suggestions" and you've proposed three changes. By the lack of consensus I meant the issue as a whole.

I suggest to have a separate repo to contain the typedefs, in which the file structure is same as current. e.g. flixel/FlxBasic.hx but it has simply one line typedef FlxBasic = flixel.Basic which points back to the renamed classes. For users who opt not to change the import statements, they can simply add one line in the project xml . Then the users are happy and the framework is happy.

@kevinresol, this seems reasonable, I'm OK with such solution. Thank you. :-) Although I'm afraid it won't solve the problem of loosing connection to all the articles containing HaxeFlixel's code snippets that can bo found on Google (because, for example, people will search for Sprite and not FlxSprite) but at that stage it's not worth further polemic.

Cheers!

[JoeCreates]

Oh christ, of course I was not being serious. But I understand that sarcasm may be hard to spot in writing.

The sarcasm was clear, but you used it in a fashion of reductio ad absurdum, analogizing the absurd argument--which you delivered sarcastically--with the arguments for removing the prefix. When I said "you were serious", I meant with regard to the underlying reductio argument of your sarcasm (i.e. you believed the analogy to be effective at illustrating the absurdity of arguments for removing the prefix).

I'm still unclear about what you are talking about with the "all or nothing". Do you mean you got the impression that either all three changes would be made, or none? If so, then I don't think anyone is arguing for or expecting such a dichotomy.

I also like @kevinresol's solution for the compatibility problem. It could actually also be used for backward compatibility where package structure has changed.

[Gama11]

A flixel-compatibility repo is not the prettiest solution and would take some time to maintain, but I guess it's workable. If it gets us enough users to be ok with the change so we can make it in the first place, I'm all for it.

[kevinresol]

We don't need to maintain it forever, I suppose. Maybe we just keep it there for 1 or 2 major versions' time then we should trash it altogether. It is just for transition purpose and not meant to be a permanent solution.

[Tiago-Ling]

I think the major part of owners / contributors agree that dropping the prefix would be great, and that's also my opinion. Also it is a no-brainer that this change, if ever done, should be made in the next major version.

The remaining question is how to do it: the compatibility repo (i actually think a class inside the main lib with typedefs to be turned on and off through a haxedef in project.xml might be better in this case), while not 100% seamless is currently the best solution, provided that all templates and demos are updated to use the typedefs as default (this will keep things as they are for the average user, while allowing them to inspect the typedef class and the new nomenclature and use them if/when they like).

While i agree that this change should be made, it will certainly affect existing users, and it might be very troublesome for people working in big projects / production code. So, a script should be provided to convert projects using current nomenclature to the new system. Without this tool it becomes very difficult to defend this change. As someone has mentioned before, without it we are essentially pulling the rug from under the feet of old and loyal users (specially since these people are spreading the word about flixel, proving that it is a good engine capable of doing great projects with).

Having said all that, i think it's gonna be a lot of work, requiring a coordinated effort from all of us. We must change the focus of this thread from "to do or not to do" to planning the appropriate steps to doing it with the lowest possible pain for the users.

Tiago Ling Alexandre Tel: +55 41 8819-3191

2014-05-27 6:22 GMT-03:00 kevinresol notifications@github.com:

We don't need to maintain it forever, I suppose. Maybe we just keep it there for 1 or 2 major versions' time then we should trash it altogether. It is just for transition purpose and not meant to be a permanent solution.

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

[gamedevsam]

The only way the Flx prefix removal will be approved is if a flixel-tools upgrade script is developed and then used to convert the engine and demos to the new convention. That way we can ensure the upgrade script covers 99% of the leg work necessary to convert HaxeFlixel projects to the new convention.

I'm not a fan of making new branches, or forking the repo to accomplish this task. Providing an upgrade script is critical to minimal disruption for existing users, and using said upgrade script to convert the engine and all the demos is the best way to ensure it would work on almost any project.

[Gama11]

@gamedevsam I don't think anybody ever questioned that there has to be an upgrade script. The question is if we additionally need a flixel-compatibility lib - I don't really think so, that seems redundant.

There are a couple of edge cases:

• FlxG - I suggest we don't change that
• FlxMath - Math is toplevel / part of the haxe std lib. -> Should also stay the same.
• FlxUI - similar to FlxG, don't think we need to change this one
• FlxPoint -> Point - conflict with flash, resolvable via import in or by using the full path in the few cases where it's necessary
• FlxRect -> Rect / Rectangle not sure what we should do with this one, Rect doesn't sound good to me. Of course by naming it Rectangle we create a conflict with flash again, but I don't think that's a huge issue?

[Beeblerox]

i'm totally not a fan of this possible change. How it will help to improve engine? Does these three letters prevent us from moving forward with updates and improvements? It will only discourage some old users. We are making enough breaking changes all the time (i'm guilty too), but this change seems totally pointless to me. Sorry, if i offended anyone, but it is my opinion about this so-called "issue"

[JoeCreates]

@Beeblerox

How it will help to improve engine?

I take it you don't think any of the reasons discussed help?

Does these three letters prevent us from moving forward with updates and improvements?

Nope, but the same could be said of the vast majority of improvements. The argument is that this is an improvement in and of itself for several reasons. Were we to only ever accept a change if not doing so would prevent improvements generally, then I daresay we'd seldom accept any changes at all.

It will only discourage some old users.

It certainly will discourage some old users. It will also encourage some old users, and encourage some new users, as well as having an overall practical effect (even if relatively small).

We are making enough breaking changes all the time

And previously such changes have been made sparsely, between major versions, and without the aid of a script to assist in updating. The consensus seems to be that we can depart from all of these practices.

[kevinresol]

@gamedevsam I don't think anybody ever questioned that there has to be an upgrade script. The question is if we additionally need a flixel-compatibility lib - I don't really think so, that seems redundant.

I think the compatibility repo is almost a must-do...

Action	Why it is needed
Drop the Flx prefix	Emulated namespace is not good, fundamentally
Upgrade script	For converting the framework itself and user codes
Compatibility repo	Some users simply do not want to change their existing code, even there is a 100% perfect upgrade script. Yeah it is kind of marketing, you want your users to be happy.

[impaler]

What is the point of leaving this issue open in the first place? Too many ideas are listed in the opening of the issue in the first place. This would have been better suited for the mailing list. I suggest that those who want to continue the discussion on the prefix open a new issue and title it correctly.

Although I don't particularly like the Prefix for obvious reasons the cost versus value argument says to me this shouldn't happen anytime soon(although it seems the value part of these two values isn't in consensus).

This brings up a wider issue that the project doesn't even have a standard for making a decision like this when there is no consensus. My personal preference on that is to consider @Beeblerox's leadership first as he is the reason we are all talking, being the creator of the project. Seems someone took that line @gamedevsam wtf https://github.com/HaxeFlixel/flixel-docs/commit/554d433b7634a80cfca633b07032b69ba2de69dc we need to figure that out for cases like this.

[gamedevsam]

Beeblerox is indeed the creator of the project, but we now have a team structure with several individuals with push access. I'm not opposed to beeblerox having the final say in matters of this nature, but the way I see it, every member of the owners team has equal powers to manage the direction of the repo.

I closed this issue previously for similar reasons as yourself (and beeblerox).

[impaler]

@gamedevsam yes I think we have agreed with that reasoning before but I was pretty specific in what you removed "hard to get consensus" which may happen again. Maybe we can re-add similar to what you just said and add something about a situation like this, where the creator of the project is respected so the issue can move on.

[gamedevsam]

I don't think it was hard to get consensus on this issue, the majority of the owners are in agreement, this should be closed. But this is a topic that people are passionate about, which could have a significant impact on the future of the API, it's understandable that it got a lot of attention.

[Beeblerox]

i don't want to have final word. I have no right for this, since my contributions went almost to zero for the last year (i think that @Gama11 have more rights to do this, since he's main contributor atm).

[impaler]

@Beeblerox lol LOC and commits do not determine value, but your humble humility never ceases to amaze me. I think we all know that if it was only up to @Gama11 this change would have already been done ;)