World's internal linked lists (as well as Entities') should be made public

[AbelToy]

World's internal linked lists (_updateFirst, _renderFirst, _renderLast, _layerList, _layerCount, _layerSort, etc.) as well as Entities' (_updatePrev, _updateNext, _renderPrev, _renderNext, etc.) should be made public or accessible some way. It's much more efficient than using getType / getAll / etc. - and would allow for more flexibility (for example, I could use nearestToEntity with some conditions, so only the nearest blue entity would get called or whatever)...

Any ideas?

[bvance]

I would tend to agree. I'd suggest moving FlashPunk move from the use of 'internal' towards an AS3 namespace solution so that in cases where developers need to do something weird (for example, efficiently depth sorting all the entities on one layer by their Y value). This is what the AS3 port of Box2D does.

[AbelToy]

@bvance How would this work? Any code examples? I can try to implement this myself.

[bvance]

The basic idea is explained here: http://gskinner.com/blog/archives/2010/01/a_complete_guid.html

One could, in this case, declare a 'FlashPunk' namespace and scope all internal variables to it (ie: 'FlashPunk Entity _updateFirst' instead of 'internal Entity _updateFirst'); this prevents any other class from seeing those variables UNLESS that other class explicitly imports and uses the FlashPunk namespace (which you would only do if you were writing some low-level extension to the FlashPunk framework and needed to mess with its private parts for some reason).

It works essentially in exactly the same was as 'internal', except it doesn't have the weird restriction that only classes in the same package can see those members (thus allowing us to write classes in other packages with all the same permissions as the ones in FP packages).

[AbelToy]

Sounds perfect!

@Draknek - What do you think? Also, which name would be better for the internal namespace? FPInternal?

[Draknek]

I have a few concerns, but nothing major.

1. Does this make things more confusing for people? It's a weird feature that I've not seen in other languages. Yes, if you're not wanting to play around with internal variables it won't matter, but is it more confusing than just hacking FlashPunk if you do need access?

2. Does this break compatibility in any way? I can't immediately think how it might, but if it does then I don't think it's worth it.

3. How does this play with generated documentation? If namespaced variables show up in generated docs then we might as well just make them public?

For the namespace name, could just use "fp"? Don't have strong opinions.

[bvance]

"fp_internal" would make the most sense, as the use of the word 'internal' hints at the what the thing is for people who don't know about AS3 namespaces (and, for whatever reason, lowercase/underscore-separated is Adobe's convention here). It is certainly a bit more confusing, but it is a good feature for larger/more rigorously-structured projects that make use of the FlashPunk framework; for hackers it seems to me that you could simply change 'fp_internal' to public the same way you would with internal, so the only barrier this adds is having to realize what 'fp_internal' means so you know what to change it to.

There is one compatibility issue however: If people out there are making use of the 'internal' modifier themselves by adding their own classes into the FlashPunk directory/package structure and those 'internal' modifiers become 'fp_internal' then their code will not compile until they add a "use namespace fp_internal" call to those classes. I don't know whether that is the sort of thing about which you guys worry.

I also just checked the documentation thing; what FlashPunk does currently (using @Private to prevent members from showing up in generated ASDocs) will work just as well on a custom namespace as it does for 'internal' stuff.

[Draknek]

Hmm, I think the easiest thing is just to make everything public probably.

[AbelToy]

Mhm. Beginners could get confused on how to use the variables, though?

[jacobalbano]

There was an issue on the forums recently where somebody was using FP.point in his own calculations and it was screwing things up. I feel like making the list entities public might result in the same sort of confusion.

[Draknek]

Hm, not sure it would. Unless you're modifying the list (in which case
hopefully you know enough to be careful), being able to access the list
shouldn't be dangerous.

The problem with FP.point is that you never know when the flashpunk code
might modify it.
On 4 Sep 2013 09:48, "Jacob Albano" notifications@github.com wrote:

There was an issue on the forums recently where somebody was using
FP.point in his own calculations and it was screwing things up. I feel like
making the list entities public might result in the same sort of confusion.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/107#issuecomment-23805081
.

[rostok]

what about conditional configuration? flashdevelop supports this, don't know if other tools do. but this way you could easily get one config with public for advanced users and another with private for beginners. there's one more approach, but it is kind of fishy. leave the private vars and add an public object with properties pointing into those private vars. this would allow public access (however with one more level on the way) and would hide the private vars in code completion.

but all this is rather overcomplicating things. i would go for public vars.

[AbelToy]

if we add another layer, we're adding an additional layer of overhead.

I'd say internals myself, it's how Flex by Adobe works. I just think public vars would confuse beginners.